코드의 구린내 - 3

.

<구린 게 있으면 그 부분을 바로 잡으세요>

16. 과잉 중개 메소드(Middle Man)

- 내부의 세부적인 처리를 외부에서 볼 수 없게 은폐하는 캡슐화는 객체지향의 주요 특징 중 하나다.

- 어떤 작업을 중개(위임)해서 처리하는 메소드는 변경에 강하고 유지보수에 도움이 된다.

- 그러나 이것도 지나치면 문제가 된다고 하니, 어느정도는 직접 접근하자.

- 실제 구현 코드가 너무 가려져 있으면 오히려 가독성을 떨어트리게 되는 건가보다.

.

.

17. 지나친 관여(Inappropriate Intimacy)

- 클래스끼리 지나치게 깊게 연결된 경우를 말한다.

- 공통 필요 부분을 클래스로 빼거나 중개 메소드를 만드는 등으로 의존성을 줄인다.

.

.

18. 인터페이스가 다른 대용 클래스(Alternative Classes with Different Interfaces)

- 기능은 같은데 시그니처가 다른 메소드(클래스)를 말한다.

- 즉 어느걸 써도 무방한(대체 가능한) 놈인 것 같다.

- 상위클래스로 추출하기도 한다.

.

.

19. 미흡한 라이브러리 클래스(Incomplete Library Class)

- 라이브러리 제작자는 고달프다.

- 제작자라도 모든 걸 아는 것은 어렵기 때문에 라이브러리의 기능을 바라는대로 수정하는 것이 보통은 불가능하다.

- 라이브러리 클래스에 넣어야 할 메소드가 두 개뿐이라면 외래 클래스에 메소드추가 기법을

- 부가 기능이 많을 때는 국소적 상속확장 클래스 사용기법을 실시하자.

- ??? 잘 모르겠습니다.

.

.

20. 데이터 클래스(Data Class)

- getter, setter만 있는 모델 혹은 빈 객체를 말한다.

- setter 메소드가 필요없다면 제거하고 필드는 캡슐화한다.

- getter, setter가 다른 클래스에 의해 사용되는 부분을 찾아, 그 기능을 데이터 클래스로 옮겨야 한다.

- 모델 객체는 단순히 데이터만 담고 있는 녀석이라고 생각했는데 꼭 그렇지만도 않은 것 같다.

- 데이터 클래스는 어린애 같아서 처음엔 괜찮지만, 성숙한 객체로서의 역할을 하려면 어느 정도의 책임을 감당해야 한다.

.

.

21. 방치된 상속물(Refused Bequest)

- 상속받은 메소드나 데이터가 하위클래스에서 더 이상 쓰이지 않거나 필요 없는 경우이다.

- 이럴 땐 메소드 하향, 필드 하향을 실시해서 사용되지 않는 녀석들을 아래쪽으로 몰고, 상위클래스에는 공통 코드만 들어 있게 한다.

- 하지만, 이 문제는 심각하지 않은 경우가 대부분이기 때문에 리팩토링이 별로 필요하지 않다.

.

.

22. 불필요한 주석(Comments)

- 구린내의 끝판왕이다.

- 개인마다 의견차이는 있지만, 나는 주석이 불필요하다고 생각한 뒤 감옥에서 해방된 느낌이었다.

- 학교에서 유일하게 배운 것 중 하나가, 주석을 다는 것이 중요하다는 것이었다.

- 그러나 꼭 필요할 때만 주석을 쓰자.

- 무슨 작업을 해야 좋을지 모를 때 (To do List)

- 알고리즘의 원리나 확실치 않은 부분을 표시할 때

- 코드의 의도 그리고 잊기 쉬운 사항에 대해서 주석으로 남긴다.

- 가장 중요한 건 주석은 유지보수가 잘 되지 않는 다는 점이다! 

.

.

.