캡슐화

hyuckhoon.ko·2020년 11월 21일
0

What I learned in first year

목록 보기
129/146
post-thumbnail



캡슐화: 기능의 구현을 외부에 감추는 것.

캡슐화로 기능을 사용하는 코드의 변경비용을 감소시켜준다. -> 비즈니스 요구에 기민하게 변화/적용이 용이하게 함.






1. 캡슐화 미적용

if (account.getMembership() == REGULAR && account.getExpDate().isAfter(now()) {
}





비즈니스가 성장해서 개발자에게 아래와 같은 추가 요구사항이 요청됨.

"5년 이상 사용자이거나 정회원인 경우 일부 기능 1개월 무상 제공"

if (account.getMembership() == REGULAR && 
 (
	(account.getServiceDate().isAfter(fiveYearAge) && 
		account.getExpDate().isAfter(now()) ||
	(account.getServiceDate().isBefore(fiveYearAgo) &&
		addMonth(account.getExpDate()).isAfter(now())
 )
) {
 ~ 정회원 기능
}







즉, 요구사항 -> "데이터 사용 방식을 바꿔야 함" -> 해당 코드가 사용된 부분을 전부 수정해야 하는 상황이 발생.






2. 캡슐화 적용

if (acc.hasRegularPermission()) {
	정회원 기능
}


public class Account {
    private Membership membership;
    private Date expDate;
    
    public boolean has ReularPermission() {
    	return membership == REGULAR && 
        	expDate.isAfter(now())
}

추가 요구사항 증가 발생!
아래의 클래스 정의 부분만 수정하면 됨.
즉, 캡슐화는 연쇄적인 변경 전파를 최소화시킨다.


public class Account {
    private Membership membership;
    private Date expDate;
    
    public boolean has ReularPermission() {
    	return membership == REGULAR && 
            (
             expDate.isAfter(now()) ||
             (
               serviceDate.isBefore(fiveYearAgo()) &&
               addMonth(expDate).isAfter(now())
             )
         );
}



캡슐화는 가독성 및 개발자의 의도를 파악하기 쉽게 한다.




3. 캡슐화 규칙

1. 데이터 달라고 하지 말기!!!!



2. Demeter's Law

데미테르의 법칙




0개의 댓글