객체로 추상화하기
•
비공개 필드(데이터), 비공개 로직(코드)
•
공개 메서드 선언부를 통해 외부 세계와 소통
→ 각 메서드의 기능은 객체의 책임을 드러내는 창구
•
객체의 책임이 나뉨에 따라 객체 간 협력 발생
객체가 제공하는 것
•
절차 지향에서 잘 보이지 않았던 개념을 가시화
•
관심사가 한 군데로 모이기 때문에, 유지보수성 ↑
ex) 객체 내부에서 객체가 가진 데이터의 유효성 검증 책임을 가질 수 있음
•
여러 객체를 사용하는 입장에서는 구체적인 구현에 신경 쓰지 않고 보다 높은 추상화 레벨에서 도메인 로직을 다룰 수 있음
새로운 객체를 만들 때 주의할 점
•
1개의 관심사로 명확하게 책임이 정의되었는지 확인
→ 메서드를 추상화할 때와 비슷
→ 객체를 만듦으로써 외부 세계와 어떤 소통을 하려고 하는지 생각해보기
•
생성자, 정적 팩토리 메서드에서 유효성 검증이 가능
→ 도메인에 특화된 검증 로직이 들어갈 수 있음
•
setter 사용 자제
◦
데이터는 불변이 최고. 변하는 데이터라도 객체가 핸들링할 수 있어야 한다.
◦
객체 내부에서 외부 세계의 개입 없이 자체적인 변경/가공으로 처리할 수 있는지 확인
◦
만약 외부에서 가지고 잇는 데이터로 데이터 변경 요청을 해야 하는 경우, ‘set~’ 이라는 단순한 이름 보다는 ‘update~’ 같이 의도를 드러내는 네이밍을 고려
•
getter도 처음에는 사용 자제. 반드시 필요한 경우에 추가하기
→ 외부에서 객체 내 데이터가 필요하다고 getter를 남발하는 것은 무례한 행동
•
객체에 메시지를 보내라
•
필드의 수는 적을수록 좋다.
◦
불필요한 데이터가 많을수록 복잡도가 높아지고 대응할 변화가 많아진다.
◦
필드 A를 가지고 계산할 수 있는 A’ 필드가 있다면, 메서드 기능으로 제공
◦
단, 미리 가공하는 것이 성능 상 이점이 있다면, 필드로 가지고 있는 것이 좋을 수도 있다.
SOLID
•
SRP : Single Responsibility Principle (단일 책임 원칙)
◦
하나의 클래스는 단 한가지의 변경 이유만을 가져야 한다. (변경이유 = 책임)
◦
객체가 가진 공개 메서드, 필드, 상수 등은 해당 객체의 단일 책임에 의해서만 변경 되는가?
◦
관심사의 분리
◦
높은 응집도, 낮은 결합
