「엘레강트 오브젝트」: 단호한 어조에 비해 설득력은 영 별로다.

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=258374007 

엘레강트 오브젝트

 

책은 전반적으로 건조하고 딱딱하다.

 

내용뿐만 아니라 저자의 어조도 굉장히 단호하다. 원칙주의자의 강변을 듣는 느낌.

 

'객체지향적 관점에서 이렇게 바라볼 수도 있겠구나.' 라는 생각은 든다.

 

다만 실제 프로젝트에 적용하기엔 무리가 있는 요구가 많다.

 

'유지보수성' 을 지키기 위한 OOP가 아니라 예술을 위한 OOP의 느낌을 받는 내용도 있었다. 

 

OOP의 극단, 매운맛을 보고싶다면 한번쯤 읽어볼 수는 있겠지만 실제 프로젝트에 OOP를 당장 적용하려는 사람은 많이 실망스러울 수 있는 책이다.

 

평점은 3점/5점

 

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

 

1. Eucation -

 

2.9 인터페이스를 짧게 유지하고 스마트(smart)를 사용하세요

• 인터페이스에 너무 많은 메쏘드가 선언되어있으면 그 구현체도 엄청 많이 구현해야한다. 보통 이러면 응집성을 떨어뜨리고 SRP를 위반하게된다.
• 스마트 클래스는 아주 명확하고 공통적인 작업을 수행하는 많은 메서드들을 포함할 수 있다.

 

3장 취업

3.1 5개 이하의 Public 메서드만 노출하세요

• Public 메서드의 크기는 5개가 한계다. 과학적인 건 아니고, 대강 적게 유지하라는 뜻이다.

3.2 선언형 스타일 대 명령형 스타일

• 선언형 스타일은 class Between implements Number 를 따로 구현해서 실제 between 연산을 필요할 때까지 미룬다.
• 반면 명령형 스타일은 between 연산값이 필요하지않을 때도 어쩔 수 없이 between 값을 연산하도록 한다.
• 요점은 실행 관점에서 선언형 방식이 더 최적화되어있다는 점이다. 우리가 소스코드레벨에서 최적화를 관리할 수 있다.
• 또한, 객체 사이의 결합도를 낮출 수 있다. (객체 사이의 분리가 가능하기 때문이다)
• 선언형 방식은 결과를 이야기하지만, 명령형 방식은 수행가능한 한가지 방법을 얘기하기 때문에 선언형 방식이 더 표현력이 좋다.
• 응집도도 선언형 방식이 더 좋다. 선언형 방식은 코드가 뭉쳐져 있기 때문에 실수로라도 분리할 수 없지만, 절차형코드는 코드가 어떻게 묶이는지 알 수 없다.
• 내의견 : 그래서 공통적인 목적을 향하는 코드는 메쏘드로 추출해내는거 아닐까?

3.2.5 함수형 프로그래밍

• FP와 OOP는 취사선택이 아니라, OOP의 강력함 안에서 메소드를 작성할 떄 FP 를 따르면 된다.
•  

3.2.6 조합가능한 데코레이터

• 프로그래머는 데코레이터를 조합하는 일을 제외한 다른 일은 하지 말아야 합니다.
• 데코레이터를 조합한 후 어떤 시점에 app.run()을 호출하면 데코레이터로 구성된 전체 피라미드가 반응하기 시작할 것입니다
• if, for, swtich, while과 같은 절차적인 문장이 포함되어서는 안됩니다.
• 객체지향은 작은 클래스를 조합해서 큰 클래스를 만들어가지만 정적 메서드는 합성이 안된다. OOP에서 정적 메서드를 사용해서는 안되는 또다른 이유이다.

3.3 인자의 값으로 NULL을 사용하지 마세요

• if(mask==null)이 아니라 if(mask.empty()) 이게 올바른 방식이다. 객체가 본인의 상태를 책임지도록 하라.
• 그럼에도 불구하고 클라이언트가 null을 던진다면, NPE가 터지도록 냅둬라. 부정확하게 null 처리를 하는게 더 안좋다.

3.4 충성스러우면서 불변이거나, 아니면 상수이거나

• 객체란 디스크에 있는 파일, 웹 페이지, 바이트배열, 해시맵, 달력의 월과 같은 실제 엔티티의 대표자입니다.
• 모든 객체는 식별자, 상태, 행동을 포함합니다
• 가변객체는 상태 변경이 가능하기 때문에 상태에 독립적인 식별자를 별도로 포함해야합니다.
• 상수 객체는 불변 객체의 특별한 경우일 뿐입니다.  불변객체는 실제 객체의 좌표를 저장한다.
• 불변 객체보다는 상수객체가 더 좋다.

4.1.1 빠르게 실패하기 vs 안전하게 실패하기

• 빠르게 실패하면 테스트에서 해당 문제를 잡아낼 수도 있고, 디버깅에 많은 수고를 들이지않아도 장애포인트를 곧바로 포착할 수 있다.

4.2.3 단 한번만 복구하세요.

• 최상위, 혹은 진입점에서 예외를 복구하세요. 예외는 잡아서 다시 던지거나 아예 잡지않는게 낫다.

4.2.4 AOP를 사용하세요

• 중요한 코드와 곁다리 코드를 분리할 수 있고, 코드 자체도 재활용할 수 있습니다.

4.4 RAII를 사용하세요

• 자바는 GC를 통해 메모리 할당 해제하기 때문에 내가 원할 때 메모리할당해제를 하기 힘듭니다. 하지만 Java 7 부터 try-with-resources를 활용해서 RAII와 유사한 처리를 할 수 있습니다. Closeable 인터페이스만 구현하면 됩니다. Java에서는 AutoCloseable을 사용하길 권장합니다.