2장 - 학습

객체는 작아야 한다!

2.1 가능하면 적게 캡슐화하세요

캡슐화 하기에 적합한 객체의 수는 최대 4개가 합리적이다.

• 객체 내부에 캡슐화된 객체들은 객체를 식별하기 위한 식별자다. 그러므로 상태없는 객체는 존재해서는 안된다.
  그 식별자가 너무 많아지면 직관에 위배된다.

== 연산을 사용하지말고 Equals()를 오버라이드 하자

느낀점

적게 캡슐화 하라고 하지만 무작정 잘게 쪼개서는 안될 것 같다. 적절한 책임 분배가 중요하지 않을까? SOLID 원칙을 얘기하지 않고 클래스 분리를 논할 수 있을까?

2.2 최소한 뭔가는 캡슐화하세요

프로퍼티가 없는 클래스는 정적 메서드와 유사하다.
세계 안에서 좌표가 없는 존재가 아니라면 무언가를 캡슐화해야한다. 객체가 어떤것도 캡슐화 하지 않는다면 객체 자신이 세계 전체가 되어야 한다. like Universe..

느낀점

프로퍼티가 없는 클래스는 앞장에서 말한 연결장치, 절차의 집합이라고 느껴진다. 가능한 모든 메서드에서 필드를 사용하면 사용 할수록 응집도가 높은 클래스라고 말하는 것도 어느정도 연관성이 있지 않을까?

2.3 항상 인터페이스를 사용하세요

애플리케이션이 성장하기 시작하고 객체들의 수가 수십 개를 넘어가면서부터 객체 사이의 강한 결합도가 심각한 문제로 떠오른다. 유지보수를 위해서는 최선을 다해 객체를 분리해야한다. 그러기 위해서는 인터페이스를 사용한다.
인터페이스를 사용한다해서 결합이 끊어지는 것은 아니다. 느슨한 결합도를 유지할 수 있다.

느낀점

결합이 무조건 나쁘다라고 머릿속에 입력값처럼 박혀있었던 것 같다. 결합은 시스템을 안정적인 상태로 유지할 수 있는 힘을 가지고 있지만 변경에 유연하게 대처하려면 느슨한 결합도를 유지하는것이 핵심인듯 하다.
하지만 과연 1:1로 매핑되는 인터페이스와 클래스라면 인터페이스를 적용해야할까? 이러한 경우에 대해서 많은 사람들이 안티패턴이라고들 말하지만 과연 구현체가 절대로 여러개로 확장되지 않는다고 단정지을 수 있을까? 변경에 대한 유연한 대처를 위해서는 인터페이스 사용을 베이스를 깔고 가는것이 좋지 않을까?

2.4 메서드 이름을 신중하게 선택하세요

빌더(새로운 객체를 반환하는 메서드)는 void여선 안된다, 명사 네이밍
조정자(객체로 추상화한 실세계 엔티티를 수정하는 메서드)는 void여야하고 동사 네이밍을 가져야한다.
Boolean에서는 형용사를 사용해야한다.

느낀점

여지껏 가지고 있었던 메서드 이름은 동사여야한다는 생각을 파괴하는 주제였다. 그리고 save 같은 함수도 저장한 객체를 반환해야한다고 생각했고 JPA에서도 저장된 Entity를 반환해야지만 ID값을 이용해 다음 사용을 유연하게 가져갈 수 있었는데 이렇게 까지 해야하는가? 라는 생각이 들기도 했다. 과연 이러한 것들이 실용적인가? 라고 생각해봤을 때에 아직까지 내 식견으로는 저자가 말하는 실용적인 객체지향과는 거리가 멀지 않은가? 라는 생각이 들기도 했다.

2.5 퍼블릭 상수를 사용하지 마세요

퍼블릭 상수를 사용하면 퍼블릭 상수를 사용한 모든 곳에서 결합이 일어나고 유지보수가 힘들어진다.
퍼블릭 상수 입장에서 또한 이 상수가 어디에서 사용됐는지 파악하기 힘들어지므로 사용하지 않는 것이 좋다.

2.6 불변 객체로 만드세요

모든 것을 불변객체로 만들어라고 한다. 불변 객체를 사용하면 시간적 결합 제거, 부수효과 제거, final을 사용하므로 NULL이 없으므로 애초에 NULL을 사용할 수 없고 데이터가 변하지 않으니 NULL 동시성 문제도 없으니 스레드 안정성이 증가한다.
불변객체라는 특성 때문에 객체를 크게 만들 수 없으니 단순성이 증가한다.

느낀점

불변 객체로 만들려고 노력해봤는데 도저히 내 상식선에서는 될 수가 없다. 불변객체를 만들고자 한다면 조정자는 쓰지말라는건데
앞에서 말한 조정자가 무슨 의미가 있지...?