객체지향과 캡슐화

객체의 핵심은 기능 제공이다.

객체는 제공하는 기능으로 정의한다. 내부적으로 가진 필드(데이터)로 정의하지 않는다.

예를 들면 회원 객체, 암호 변경기능, 차단 여부 확인 기능

 

기능 명세는 이름, 파라미터, 결과로 구성한다.

객체와 객체는 기능을 사용해서 연결한다.

기능을 사용하는 것은 메서드 호출하는 것이다.

 

메시지

객체와 객체 상호 작용:메시지를 주고 받는다고 표현

종류는 메서드를 호출하는 메시지, 리턴하는 메시지, 익셉션 메시지 등등이 있다.

 

그 다음 객체지향에서 중요한 캡슐화는 데이터와 관련 기능을 묶는 것이다.

구현에 사용된 데이터의 상세 내용을 감추는 것이기도 하다.

정보 은닉의 의미를 포함하기도 한다.

외부에 영향없이 객체 내부를 구현하고 변경 가능하다.

 

위의 코드는 특정 회원에게 부가 기능을 제공하기 위한 부분이다. 캡슐화를 하지 않아서 코드가 가독성이 떨어지고, 여러부분의 코드를 수정해야하는 상황이 발생하여 유지보수에 어려움이 생긴다.

즉, 요구사항의 변화가 데이터의 구조와 사용에 변화를 발생시키는 경우이다.

예로는 장기 사용자에게 특정 기능 실행 권한을 연장(단 유효 일자는 그대로 유지), 계정을 차단하면 모든 실행 권한 없음, date를 localdatetime으로 변경 등이 있다.

 

캡슐화를 하면  연쇄적인 변경 전파를 최소화 할 수 있다.

요구사항의 변화가 내부 구현을 변경하여 캡슐화된 기능을 사용하는 코드에는 영향 최소화한다.

 

또한 캡슐화를 하면 기능에 대한 (의도)이해를 높일 수 있다.

예를 들어 아래의 코드처럼 작성하면, 멤버십이 REGULAR와 같은지 검사하는 이유를 알 수 없다.

if(acc.getMembership()==REGULAR){
	...
}

따라서 이 코드를 수정하여서 왜 REGULAR와 같은지 검사하는 이유를 부여한다.

if(acc.hasRegularPermission()){
	...
}

public class Account{
	public boolean hasRegularPermission(){
    	...
    }
}

 

그럼 이제 캡슐화를 위한 규칙을 알아보자.

1. Tell don't Ask 데이터를 받아오지 말고, 요청하기

데이터를 직접 받아와서 처리하는게 아닌 객체 내부에서 처리할 수 있게 만든다.

 

2. Demter’s Law

메서드에서 생성한 객체의 메서드만 호출하기

파라미터로 받은 객체의 메서드만 호출하기

필드로 참조하는 객체의 메서드만 호출하기

 

그럼 이제 예제를 살펴보자.

아래의 코드는 권한 유효 여부에 관련된 코드이다.

위의 코드에서 2가지 캡슐화 규칙을 활용해서 수정할 수 있을까?

첫번째 규칙인 tell don't ask를 적용하여 값을 가져와서 처리하는 것이 아니라 객체 내부에서 처리하게 만들 수 있다.

그 다음은 movie rental관련 코드이다. 여기서는 어떤 부분을 수정할 수 있을까?

이런 코드의 경우 if-else문 전체를 묶어서 객체의 내부 메서드로 처리하는 것이 좋다.

나중에 renterPoint의 연산 방식이 바뀔때도 처리하기 좋은 유지보수성과 가독성도 가진다. 

즉, 객체의 기능을 추가하면서 필요한 데이터는 파라미터로 만들어준 것이다.

다음은 타이머를 구현한 코드이다.

이 코드에서는 시작시간과 종료시간을 기록하고 직접 소요된 시간을 계산하고 있다.

그럼 이 코드는 바꾸면 어떻게 바꿀 수 있을까?

tell don't ask의 규칙으로 데이터를 받아오는 것 대신에 요청하고, 직접 계산하는 것 대신에 메서드로 만들어 객체에 기능을 추가하고, 필요한 데이터는 파라미터로 만든다.

위의 예를 보면 코드의 확장성을 볼 수 있는데, 만약 MILLISECOND로 계산하던 시간을 NANOSECOND로 바꾸고 싶다면, 위의 코드에서 Timer의 메서드에 start부분과 stop부분에 NANOSECOND의 경우를 추가하고 파라미터로 필요한 데이터를 넘겨준다면,

elapsedTime에는 case를 하나 추가해주는 것으로 NANOSECOND의 타이머를 만들 수 있다.

즉, 기능을 추가하는 코드의 확장성을 볼 수 있다.

마지막으로 이메일의 유효성과 관련된 코드를 보겠다.

여기서는 어떤식으로 캡슐화를 진행 할 수 있을까?

위의 경우들을 보면서 조금은 감이 잡혔을 것이다. 아마 if문 안에 값을 가져오는 것을 요청문으로 바꾸는 것은 생각 해냈을 것이다.

위의 코드같은 경우 if-else문으로 연결되어 email의 상태에 따라 처리방식이 있는 이런 경우에는 if-else문 자체를 묶어서 객체 내부의 메서드로 만든다. 추가적으로 if문의 코드도 tell don't ask의 방식으로 바꾸어준다. 이렇게되면 코드의 가독성도 올라간다.