Vertical Formatting
1. 공란을 함부로 사용하지마라.
공란은 비어있는 라인을 말하는데 이것도 일련의 규칙을 가지고 하는 것이 좋다고 한다. 아래와 같은 경우에 공란을 주자!
- 메소드 사이
- private 변수들과 public 변수들 사이
- 변수선언과 메소드 실행의 나머지 부분 사이
- if / while 블록과 다른 코드 사이
2. 서로 관련된 것들은 Vertical하게 근접해야한다.
Vertical한 거리가 그들간의 관련성을 나타낸다!
Class
1. Class란 무엇인가?
private 변수와 그 변수들에 대해서 동작하는 public 함수들의 집합이다.(private함수일 수 도..)
private변수들을 작성함으로써 클래스를 작성한다. 그리고 private변수들을 public 함수들로 조작한다. 그렇기 때문에 외부에서는 클래스 내의 private변수들이 존재하지 않는 것처럼 보인다.
하지만,
너무 잘 보인다.
왜냐하면 Getter/Setter 때문에 짐작할 수 있게된다. 왜 변수는 private로 선언하고, Getter/Setter를 제공하나?
필요하지도 않는 Getter/Setter들을 만드는 것은 정말 좋지않은 습관이다.
또한, 객체의 상태를 외부에서 사용할 수 있도록 하는 Getter/Setter/property 등을 제공하는 것은 잘못 된 설계다.
여기서, 또다시 Tell, Don’t Ask Rule이 나온다.
객체가 관찰할 수 있는 상태를 가지지 않는다면, Tell 하기 쉽고, ask할 가치가 없어진다. 이 규칙을 따르게 되면 Getter가 많지않고, Getter가 많지않으므로 Setter도 적다.
Max cohesive(응집도 최대)를 생각했을 때 Getter/Setter는 cohesive 하지않다.
왜냐하면 하나의 변수만 사용하기 때문에 응집도가 높을 수 없다. 그렇다고 해서 Getter/Setter가 없을 수는 없다..
그래서 최소화하고 본래변수를 그대로 노출하지않고, 추상화를 통해 제공해야한다.
위의 사진처럼 getter를 추상화를 통해서 제공하고, 추상화하기 때문에 getter 이름을 잘 정해야한다.
이렇게 했을 때 다형성이 자연스럽게 따라오게 된다.
다형성은 클라이언트 코드를 서버코드의 구현 변경으로부터 보호하고,
IoC를 통해 High Level Policy(클라이언트, 비즈니스 로직)를 Low Level Detail로부터 보호하는 것.