클린 코더스 강의 6. Form

2. comments should be rare. → comment는 특별한 경우에만(special cases) 드물게 작성되어야 한다.

3. comments are failures. → 작성자의 의도가 잘 나타나게 프로그램을 작성한다면 커맨트의 작성이 불필요해진다.

→ 코드에 의도를 나타내는 것의 난이도는 언어 플랫폼에 따라 달라진다.

Ruby, Java, C# 등은 표현력이 매우 뛰어나기 때문에 커맨트 없이 개발자의 의도를 코드에 나타낼 수 있다.

Java를 사용하면서 comment가 많다는 것은 코드가 expressive 하지 못하다는 것을 나타내는 실패의 상징이다.

 

단, comment를 작성해야 할 경우도 있다.

good comments의(꼭 comment를 작성해야만 하는) 경우, 

- 법적 정보(Legal Comments)

- 정보전달성 주석(Informative Comments)

- 경고성 주석(Warning of Consequences) → ex. don't run unless you have some time to kill 

- TODO 주석(TODO Comments)

- Public API Documentation

 

bad comments 중 closing brace comments 가 있음.

예를 들면 if문의 끝 부분에 // end of if 이렇게 작성하는 것, 이런 주석이 bad comment에 속한다.

attribution comments 또한 지양해야할 주석이다. 예를 들면 이 메서드를 누가 만들었는지에 대한 정보를 작성하는 것이다.

ex. // add by baek

4. vertical formatting: 공란을 함부로 사용하지 말 것.

공란을 처리하는 경우

- 메서드 사이

- public 변수들과 private변수들 사이

- 메서드 내에서 변수들과 메서드 실행의 나머지 부분 사이, if/while 블록과 다른 코드들 사이

 서로 관련된 것들은 vertical하게 근접해야 한다. vertical한 거리가 그들간의 관련성을 나타낸다.

 

클래스란 무엇인가? private 변수와 그 변수들을 동작시키는 public 메서드로 구성되어 있다.

물론 private 메서드가 존재할 수 있다.

그리고 private 변수를 조작하는 메서드, private 변수들의 상태를 확인하는 메서드가 존재한다.

외부에서는 private 변수들이 없는 것처럼 보인다.

 

속성의 접근제어자를 private으로 설정, 그리고 getter, setter 메서드를 작성하여 외부에서 해당 속성의 상태를 확인하고,

→ getter/setter 메서드를 포함해서 property라고 부른다.

상태를 조작할 수 있도록 디자인하는 것은 bad design이다. 기능을 갖는 객체의 내부가 예측 불가해야하는데 메서드명만 보고

해당 객체의 내부에 어떤 속성이 있겠구나 예측할 수 있다면 좋지 않은 것이다. encapsulation(캡슐화)가 안된 것이다.

 

어떤 객체의 내부에 어떤 속성에 직접 접근해서 외부에서 컨트롤 한다면 해당 객체의 내부에 어떤 변화가 생겼을 때,

외부에서 작성한 로직들에도 많은 변화가 발생한다. 그래서 속성에 직접 접근하기보다는

접근제어자가 public인 메서드를 이용하는 것을 권장하고,

외부에서 기능(메서드)을 이용하도록 설계한다면, tell don't ask 원칙을 지키게 된다.

객체가 관찰할 수 있는 상태를 갖지 않는다면(no observable state),

무엇을 하라고(tell) 하기 쉽고, ask할 가치가 없어진다.

 

coupling은 다른 것들에 의한 의존도,  cohesive는 관련된 기능이 모아져있어야 하는 응집도를 의미한다.

어떤 객체의 응집도가 높다는 것은 해당 객체에 선언된 메서드가 해당 객체에 선언된 변수들을 모두 사용한다는 것을 의미한다.

max cohesive와 max cohesive class의 차이

 

getter/setter 함수는 cohesive하지 않다. 변수 하나만 사용하기 때문에

클래스가 getter/setter를 많이 가질수록 클래스는 응집도가 낮아진다 → 덜 cohesive한 클래스

getter를 안 쓸수는 없다. 최소화로 작성하고, 추상화를 통해 인스턴스의 상태를 조회할 수 있도록 하기

→ 상세 구현을 덜 노출하는 추상화를 사용하기(polymorphism)

다형성은 내부 변수를 숨겼을 때(private) 이점이 될 수 있다

→ DieselCar, ElectricCar, NuclearCar 클래스가 모두 Car 클래스를 상속했을 때,

Car 클래스에 작성한 동일한 메서드를 각 클래스에서 해당 객체에 선언한 변수들의 상태를 조작할 수 있도록

내부 로직을 변경할 수 있는 이점이 있다. 하나의 메서드호출로 해당 인스턴스에 맞게 상태를 조작할 수 있다는 것.

상세구현을 덜 할수록 polymorphic한 클래스를 구현할 수 있다.

 

객체지향의 핵심은 IoC를 통해서 High Level Policy를(클라이언트 비즈니스 로직)

Low Level Detail로부터 보호하는 것이다.

 

- class와 반대되는 개념, data structure

 메서드는 없고, public variable만 있다. 변수들의 집합, 일종의 자료구조라고 이해하면 된다.

클래스는 private 변수와 해당 변수들을 다루는[조작하는] 메서드의 집합,

data structure는 public 변수들만 존재하거나 public 변수들 + getter/setter 메서드들의 집합이다.

data structure는 변수를 하나만 조작하기 때문에 cohesive가 낮은 단점이 있다.

클래스는 일련의 변수들에 대해 동작하는 메서드들의 집합이기 때문에 cohesive가 높다.

클래스는 구현을 감추고 추상화할 수 있지만

data structure는 getter/setter 메서드에 변수명이 노출됨으로써 구현이 노출된다는 단점이 있다.

그래서 클래스는 tell이 가능하지만, data structure는 tell이 불가능하게 된다. ask만 가능하다.

 

객체지향에서 인터페이스 및 추상 클래스에 기능을 추가한 경우, 해당 인터페이스를 구현하거나

추상클래스를 상속한 서브 클래스들에서 새로운 기능을 반드시 구현해야하는 의무가 발생한다.

따라서 객체지향에서는 기능 추가에 대한 변경이 기존 코드에 영향을 주는 문제점이 발생할 수 있다.

그래서 객체지향에서는 "기능 추가"에 대한 변경에 약하다.

 

클린 코더스 강의 6.Form 39분부터: boundaries 부분 이해 안됨, 재청강 필요 ----------------

영역은 app과 main으로 나누어진다. app 파티션과 main 파티션을 나누는 것은 boundary의 일이다.

main이 app 파티션의 플러그인이다. 

boundary 사용시 항상 concrete(main)에서 abstract(app)로 소스 코드의 의존성이 있어야 한다.

 

application partition은 변경이 가능한 비즈니스 로직이다.

예를 들면 인터페이스, 추상 클래스를 호출하는 곳이고,

인터페이스 및 추상클래스를 구현한 클래스들이 존재하는 곳이 main partition이다.

 

DB table은 data structure다.

data를 노출하고, 메서드는 없기 때문이다.

DB table은 너무 concrete해서 polymorphic할 수 없다.

hibernate도 진정한 object-relational mapper는 아니다.

왜냐하면 db row와 객체간의 직접적인 매핑이 없기 때문이다.

-------------------------------------------------------------------------------------