엘레강트 오브젝트 2장 - 1회차

midas·2022년 6월 8일

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

세계 안의 객체를 바라보는 우리의 사고방식으로 4개 이상의 요소로 구성된 좌표를 이해하는 것은 너무나도 어렵습니다.
라고 이야기 하면서 4개 또는 그 이하의 객체를 캡슐화할 것을 권장합니다.

추가로 객체로 관리를 한다면 ==연산자를 사용하지 말고, 항상 equals() 메서드를 오버라이드하라!

🐶 후기

필드가 많아지는 걸 막고... 캡슐화 해서 관리 해라!라는 정도로만 이해를 했습니다.
회원 정보를 관리 할때, 주소 부분은 Address라는 객체로 캡슐화해서 사용을 하게 되는데...
저희는 수많은 회원가입들을 통해서 주소안에 어떤 값들이 있을지 이제는 알 수 있습니다.
이와 같다고 이해했습니다.

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

객체가 무(nothing)와 아주 비슷한 어떤 것이 아니라면 무언가를 캡슐화해야합니다.
오직 하나만 존재하고 생존이나 자신의 좌표를 표현하기 위해 다른 엔티티를 필요없는 아이들만 캡슐화가 필요없다라고 합니다.

🐶 후기

before 후에 after를 통해서 더 낫다 라고 이해할 수 있어야 하는데... 이게 나아진건가? 🤔 라는 의구심을 들게 만드는 예제였습니다.
예제로 인해서 더더욱 이해가 멀어진 챕터 였습니다.

👾 추가(2022.06.10 금)

😁 적용 전

⚰️ 적용 후

public class Percented {
    private final long percent;

    public Percented(final long percent) {
        this.percent = percent;
    }

    public long value(final long value) {
        return (value * (percent / 100));
    }
}

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

역할과 책임을 나누고 소통하는 객체들은 서로를 필요할수 밖에 없는데 이는 곳 결합(coupled)된다는 것입니다.
강한 결합도(tight coupling)
분리(decoupling)

인터페이스(inteface)

계약(contract)
느슨한 결합도(loose coupling)
이 키워드들이 나오는 챕터...

🐶 후기

스프링 공부하면서 항상 나오는 부분이라 제일 공감되는 파트였습니다.

👾 추가(2022.06.10 금)

인터페이스 뿐만 아니라 추상 클래스도 해당 된다...?
하지만 인터페이스가 더 확실한 계약관계...? 이걸 어떻게 표현하면 좋지?

👺 2.4 메서드 이름은 신중하게 선택하세요.

빌더는 명사다.
O - 커피 주세요.
X - 가서 이러이러케 커피를 끓여오십셔
조정자는 동사다.
반환 값이 있을 때는 뭘 주세요! 가 되어야 한다.
add(int a, int b) → sum(int a, int b) => 합쳐진 값을 내놔라!
빌더와 조정자 혼합하기.
Boolean 값을 결과로 반환하는 경우

🐶 후기

Boolean의 경우에는 prefix를 빼고 형용사로 해야 된다. 라는건 너무 이상적인 것 같고..
생각을 조금이라도 덜할 수 있도록 is를 붙이는게 더 낫다고 생각 됩니다.
(안 그래도 영어인데.. 형용사 뭐 이런것도 생각해야 돼...? 😓)
그 외의 부분은 이해 됬습니다.