👶 Birth
이 여정의 전제는 객체를 살아있는 유기체라고 생각하기라고 합니다.
객체를 먼저 의인화 합니다. (여기서는 그(he)라고 표현합니다.)
가시성 범위(scope of visibility)는 그의 세상입니다. 아래의 코드가 예시입니다.
public void theWorld() {
Sting he = "I'm alive.";
}위의 코드의 he는 theWorld라는 세상속의 사람입니다.
theWorld가 만들어질 때 생겨나고 끝날때 사라지는 존재라고 볼 수 있습니다.
이 책에서는 이렇게 의인화 함으로써...
객체의 책임과 역할을 잘 나눠서 설계하는 것이 코드의 유지보수성을 높이는 것이라고 이야기 하는것 같습니다.
이와 함께 다른 사람이 저의 코드를 이해할 수 있다면 저의 잘못이라고 하네요.
참 많은 의미를 내포하고 있는것 같은데, 그냥 잘~ 만들어라. 라는 것으로 넘어가겠습니다.
🤥 -er로 끝나는 이름을 사용하지 마세요.
클래스는 객체의 팩토리(factory)이다.
클래스가 객체를 생성한다. === 인스턴스화한다(instanicate).
무엇을 하는지(what he does)가 아닌 무엇인지(what he is)를 생각하여 클래스 이름을 결정해야 됩니다.
- 💩 클래스 객체들이 무엇을 하고 있는(doing)지를 살펴본 후에 기능(funtionality)에 기반해서 이름을 지으면 안된다!
- 클래스 == 객체의 팩토리 == 객체의 어머니
- '-er'이라는 악마의 속삭임에 넘어가면 안된다.
- ✨ 클래스는 연결장치(connector)가 아닌 대표자(representative)이다.
라고 하는데 말입니다...? 🤔
예제가 너무 빈약해서 공감이 1도 안됩니다.
MVC를 그러면 어떤식으로 풀어냈는지 정도의 예제를 보여준다면? 이해가 확실히 될텐데 말이죠.
그래서 이 챕터에서 볼만한 점은?
클래스 이름은 명사이다! 최대한 동사를 배제해야 됩니다.
간단하게 주의만 하고 넘어가는걸로... 🏃
🚀 생성자 하나를 주 생성자로 만드세요.
| 하나의 주 ctor과 다수의 부 ctor(one primary, many secondary)
ctor이 많아질수록 더 유연하게 사용가능하지만...
사용하기 어려워지며 클래스의 초점이 흐려지고 단일 책임 원칙을 위반하게 됩니다.
장점은 주 ctor에 유효성검사 로직을 모두 넣어서 사용할 수가 있습니다.
이는 코드의 중복및 복잡성을 줄이고 유지보수성을 높인다고 합니다.
확실히 공감's.. 👍
이 부분은 확실히 코드리뷰 스터디를 통해서 느낄수 있었습니다.
일단 this()메서드를 이용한다는 점에서 코드를 줄일 수 있었고, 유효성 검사 로직을 모두 하나의 생성자에서 관리한다는 것이 좋았습니다.
Entity 클래스를 봤을 때, 유효성검사를 한곳에서만 보면 된다는 점에서 확실히 보기도 좋았고 말이죠.
🫥 생성자에 코드를 넣지 마세요.
경험 법칙: 인자에 손대지 말라(don't touch the arguments)
class Cash {
private int dollars;
Cash(String dlr) {
this.dollars = Integer.parseInt(dlr); // ✨ 이렇게 하지 말라고 함.
}
}대신에 다른 타입의 객체로 감싸거나 가공하지 않은 형식(row form)?으로 캡슐화는 OK라고 말합니다.
위의 말이 사실 이해가 되지 않는데... 캡슐화가 왜 OK지? 🤔
일단은... 🐶
예제 처럼 숫자로 변환하는 로직이 들어가서는 안된다라는 말에는 매우 공감합니다.
저러한 로직을 없애면서 생성자라는 의미에 걸맞게 객체를 만드는(build)것만 함으로써...
투명한 객체를 만들 수 있고, 재사용하기도 쉬워진다! 라는 말에 저도 동감합니다.
저런 로직이 필요하다면 해당 매개변수에 대해서만 비지니스 로직으로 따로 분리를 시켜서 만들어야 된다고 생각합니다.
| 객체는 요청을 받을 때만 행동하고 그 전에는 어떤 일도 하지 않습니다. 이 객체들은 좋은 방식으로 매우 '게으릅니다(lazy)'
이 말이 사실 좀 이해가 안되긴하지만...? 🤔
숫자로 변환하는 로직을 언제 어디에서 할지 마음대로 할 수 있으니까 이 부분을 말하는것 같습니다.
