진정한 객체지향으로 코딩하는 것은 무엇인가에 관한 가이드를 담은 글이나 저자에 생각이 매우 강경하기에 모든 내용에 공감할 수는 없었다. 하여 개인적인 생각을 첨부하여 담고자 한다

1. er로 시작하는 클래스 이름을 사용하지 마세요
   1. 클래스는 객체의 팩토리임으로 관리자의 역할을 하기 위해 new 연산자 보다는 팩토리 패턴을 사용하자
   2. handler, reader, converter, validator 와 같은 이름은 연결( connector ) 의 의미를 지니기 때문에 자립적인 객체의 입장을 존중받을 수 없다
   3. 무엇을 하는지 가 아닌 무엇인지 에 의미를 두어 클래스 이름을 작성해야 한다
   4. 개인적인 생각: 무엇을 하는가에 따라 무엇인지 정의 할 수 있는거 아닐까?
2. 생성자 하나를 주 생성자로 만드세요
   1. 적은 수의 메서드와 다양한 생성자를 이용하여 응집도가 높은 클래스를 작성 할 수 있다
   2. 부 생성자들이 주 생성자를 호출하는 형태로 작성하여 유지보수성을 향상시킬 수 있다
   3. 개인적인 생각: 다양한 생성자를 가진다는 건 다양한 일을 처리하므로 SRP가 깨진건 아닐까?
3. 주 생성자에 처리 코드를 넣지 마세요
   1. 진정한 객체 지향은 더 작은 객체를 조합하여 큰 객체를 만드는것이다
   2. 생성자에 처리 코드를 넣는것은 좋지 않다 → 객체로 감싸 나중에 처리한다면 처리를 지연시켜 더 좋은 성능을 얻을 수 있다
   3. 생성자에서는 저 수준의 객체를 이용하여 처리지연에 도움을 줄 수 있다
4. 가능한 적게 캡슐화 하세요
   1. 하나의 객체에 4개 이하의 프로퍼티를 담도록 노력하세요 → 적은 복잡도의 유지가 됩니다
   2. 항상 equals 과 hashcode 메서드를 오버라이드 하세요
   3. 개인적인 생각: 동의하나 현실적으로는 어렵다
5. 최소한 뭔가는 캡슐화 하세요
   1. 캡슐화가 없는 객체가 과연 존재할 수 있는가에 대한 의문
   2. 유틸리티 클래스, 정적 메서드를 사용하지 마세요
   3. 개인적인 생각: 그럼 모두가 공용으로 쓰는 함수는 어디에 위치해야 하는가?
6. 항상 인터페이스를 사용하세요
   1. 인터페이스는 계약이고 실제 구현체는 계약을 구현한 각각의 경쟁자들로써 쉽게 대체 가능해야 한다
   2. 개인적인 생각: 경쟁자가 없는 경우가 존재한다면 이것은 인터페이스로 만들어야 하는가? → 미래는 알 수 없다
7. 메서드 이름을 신중하게 선택하세요
   1. 빌더 ( 새로운 객체를 반환 ) 의 이름은 명사로, 조정자 ( 엔티티를 수정 ) 의 이름은 동사로 지어야 한다
   2. 객체 자체에서 해결 가능하다는 뜻을 가진 이름을 지으려고 노력하세요 → SRP 원칙을 지키기 쉬워 집니다
   3. Boolean 값을 반환하는 메서드는 형용사로 지어야 합니다 → ex: empty, readable, negative 등등
   4. 개인적인 생각: 동의
8. 퍼블릭 상수를 사용하지 마세요 → enumeration class로 대체하라
   1. 어디서나 접근 가능한 상수를 통해 결합도가 높아지고 응집도가 낮아진다
   2. 상수를 사용하는 곳의 파악이 쉽지 않고, 객체의 사용 용도를 알 수 없게 된다
   3. 퍼블릭 상수마다 해당하는 의미를 지닌 클래스를 생성해서 사용해야 한다
   4. 개인적인 생각: 엄청난 챌린지…
9. 불변 객체로 만드세요
   1. 저자는 불변 객체가 언어 차원의 지연 로딩을 지원해야 한다고 생각한다 → 불변 객체의 단점 해결
   2. 불변 객체에는 식별자 가변성의 문제가 없다
   3. 실패하는 원자성 목표의 달성이 쉽다
   4. 시간적 결합이 제거 된다
   5. 개인적인 생각: 동의한다
10. 문서를 작성하는 대신 테스트를 만드세요
    1. 메인 코드만큼 테스트에도 관심을 기울여야 한다
    2. 단위 테스트는 클래스의 일부이다
    3. 개인적인 생각: 동의한다
11. 목 객체 대신 페이크 객체를 사용하세요
    1. 테스트를 더 짧고 간결하게 만든다 → 다만 페이크 객체가 테스트를 올바르게 지원하도록 작성해야 한다
    2. 목킹은 세부구현에 의존하여 내부 구현을 노출해야하는 필연적인 단점이 있다
    3. 인터페이스 설계를 더 고민하도록 하여 더 좋은 설계를 만든다
    4. 개인적인 생각: 테스트 종류마다 목과 페이크를 적절히 써야한다고 생각한다
12. 인터페이스를 짧게 유지하고 스마트를 사용하세요
    1. 인터페이스 안에 스마트 클래스(인터페이스를 지원하는)를 생성해라 → 유틸리티 성격은 이를 통해 지원하자
    2. 개인적인 생각: 헬퍼, 유틸리티 클래스의 대안이지만 불필요한 인터페이스 양산의 가능성도 있다
13. 5개 이하의 퍼블릭 메서드만 노출하세요
    1. public + protected 메서드의 총 수를 5개 이하로 유지하세요
    2. private 메서드 수는 관계가 없다
    3. 개인적인 생각: 이건 말도 안된다. 차라리 총 메서드의 수가 10개라면 모를까, 하나의 클래스에서 5개의 메서드로 수십가지 기능 지원이 가능해 진다
14. 정적 메서드를 사용하지 마세요
    1. 선언형 방식을 이용할 수 없어 직접 성능 최적화를 할 수 없다
    2. 선언형 방식을 이용하면 결합도가 더 낮은 프로그램을 작성할 수 있다
    3. 객체지향은 선언형 언어이며 알고리즘과 실행 대신 객체와 행동의 관점에서 사고 해야 한다
    4. 정적 메서드는 합성이라는 아이디어와 대치되는 개념이라 별로다
    5. 개인적인 생각: 어떤 객체의 특성에 적합한지 확인하는 경우 그럼 인터페이스의 스마트 클래스를 사용하라는 건가…
15. 유틸리티 클래스, 싱글턴 클래스를 생성하지 마세요
    1. 싱글톤과 유틸리티 클래스는 분리 가능성,의존성을 가진다는 차이점 외에는 둘 다 안티 패턴이다
    2. 개인적인 생각: 유틸리티 클래스만 동의한다. 객체는 라이프 사이클을 가져야 한다
16. 인자의 값에서 NULL을 절대 허용하지 마세요
    1. 자바에는 포인터가 없기 때문에 역 참조가 필요 없다
    2. NULL 값은 상대 객체에게 객체를 체크해야 하는 로직을 강요하므로 좋지 않다
    3. 개인적인 생각: 동의
17. 변수는 불변이거나 상수여야 한다
    1. 객체 세상에서는 동일한 객체가 생긴다는 것은 말이 안된다
    2. 그러므로 팩토리에서 생성하는 같은 객체는 모두 동일하다고 판단해야 한다
    3. 상태(state)와 데이터(data)를 구분해라
    4. 개인적인 생각: 같은 크기의 돈은 동일한 객체가 맞는가? 아닌건가?
18. 절대 getter 와 setter를 사용하지 마세요
    1. 자료구조는 투명하지만 객체는 불투명하다. → get,set은 이를 모두 위반한다
    2. 개인적인 생각: 동의한다. 그러나 Dto 변환에서는 어떻게 해야하나..