캡슐화

캡슐화란 ? 데이터 + 관련 기능 묶기

객체가 기능을 어떻게 구현했는지 외부에 감추는 것, 정보 은닉 의미도 포함

캡슐화를 하는 가장 큰 이유 ? 캡슐화를 하게 되면 외부에 영향 없이 객체 내부 구현 변경이 가능하다.

캡슐화 하지 않으면 ?

Account의 멤버쉽을 체크하는 로직의 변경이 있을 때,

ex ) 5년 이상 사용자들에게 일부 기능 정회원 혜택 1개월 무상 제공 !

진짜 이런 코드를 작성해야 한다면 마음이 아플 것 같다. 그 이유는 변경해야할 곳이 여러군데일 가능성이 높다.

• 요구사항의 변화가 데이터 구조/사용에 변화를 발생시킨다.
• 그 결과 데이터를 사용하는 코드의 수정이 발생하게 된다.

요구 사항 변경 예

• 정기 사용자에게 특정 기능 실행 권한 연장
• 계정을 차단하면 모든 실행 권한 없음
• Date를 LocalDateTime으로 변경 (Java8이 나오면서...)

이런식으로 변경되어야 하는 코드가 연쇄적으로 발생하게 된다

캡슐화 하면

• 기능을 제공하고 구현 상세를 감춘다.

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

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

이 상황에서 요구사항이 변경된다면 ?

public boolean hasRegularPermission(){
    return membership == REGULAR && 
      (expDate.isAfter(now()) ||
       (serviceDate.isBefore(fiveYearAgo()) && 
       addMonth(expDate).isAfter(now())
       )
      );
  }

• 내부 구현만 변경해주면 된다.
• 기능을 사용하는 다른 코드는 바뀌지 않은 것

캡슐화는 연쇄적인 변경 전파를 최소화 한다.

캡슐화와 기능

• 캡슐화 시도 -> 기능에 대한 (의도) 이해를 높이게 된다.

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

// 멤버십이 REGULAR와 같은지 검사하는 이유는 실제로 무엇 때문인가 ? 
// 검사하는 이유 : 계정이 REGULAR 권한을 가졌는지 확인하기 위함

• 이해를 바탕으로 기능을 캡슐화하여 제공하는 식으로 변경할 수 있게 된다.

캡슐화를 위한 규칙

• Tell, Don't Ask
  • 데이터 달라 하지 말고 해달라고 하기
    • 멤버쉽 데이터를 가져와서 레귤러인지 확인 ? (XXX)
    • 멤버쉽 데이트가 validate한지 판단해줘라고 부탁 ! (OOO)

• Demeter's Law

  • 메서드에서 생성한 객체의 메서드만 호출
  • 파라미터로 받은 객체의 메서드만 호출
  • 필드로 참조하는 객체의 메서드만 호출

• 메소드 하나만 호출하게끔 바꾸는 방식
• 이 방식을 하려다 보면 캡슐화가 저절로 자연스럽게 된다.

정리

• 캡슐화 : 기능의 구현을 외부에 감춤
• 캡슐화를 통해 기능을 사용하는 코드에 영향을 주지 않고 (또는 최소화) 내부 구현을 변경할 수 있는 유연함