[엘레강트 오브젝트] 2회 완독 후 느낀점

엘레강트 오브젝트 - 교보문고

엘레강트 오브젝트 새로운 관점에서 바라본 객체지향 (Yegor Bugayenko 지음 | 조영호 옮김)

 

 

 

 

책의 내용을 100% 공감하고 받아들이려고 하기 보다는 왜 이런 방식을 쓰지 말라고 하는걸까,

이런 방법을 업무에 적용하기엔 어떤 어려움이 있을까 고민해 보면서

나만의 기준을 찾아 나가보라는 팀장님의 조언에 다시 한번 읽게 됐다.

 

책에서는

'객체의 내부를 노출시키는 Getter Setter을 사용하지 말아라, 테스트 코드를 만들어라'는 기본이 되는 원칙부터

메서드 네이밍, 주생성자 부생성자, 예외처리 등 알아두면 좋을법한 원칙들과

'퍼블릭 상수나 열거타입, 싱글톤, 유틸클래스, Java Optional을 사용하지 말라'는

내가 흔하게 사용하던 방법들을 뒤엎는 개념까지 다양한 관점에서의 객체지향 프로그래밍 방법을 제시하고 있다.

 

특히 나는 열거타입, 유틸을 거의 매일 쓰고 있는 상황이라 이걸 쓰면 안된다는 부분을 보고 매우 당황 스러웠는데,

퍼블릭 상수나 열거형, 유틸, 싱글톤 모두 전역변수 그 이상 이하도 아니며,

전역 변수는 캡슐화를 위반하며 의존성을 증가시킨다는 이유에서였다.

 

머리로는 이해가 됐지만 업무 적용에 쉽지 않은 이유는 널리 알려진 일반적인 방법인 만큼

이미 수많은 레거시 프로젝트에서 열거형와 유틸 클래스를 사용 중이고

이것들을 한번에 확 바꾸는것이 어렵기 때문이지 않을까 싶다.

 

하나씩 바꿔보자니 다른 사람들은 다 Enum을 사용하는데 나 혼자 다른 형태(?)의 클래스 객체를 만들어 사용한다면

암묵적으로 지켜지고 있던 코드 컨벤션을 어기는 이기적인 개발자가 되는 기분도 들테고,

또한 내가 만든 다양한 작은 단위의 클래스들의 역할을 동료가 잘 이해하고 적절히 가져다 사용한다는 것이 보장되지 않기 때문이다.

 

나 역시도 기하급수적으로 늘어나는 클래스들 속에서

사용하려는 기능이 어떤 객체에 있는지 정확히 판단하기 어려울 때가 많았다.

심지어 다른 객체에 이미 존재하는 기능을 다시 만들 때도 있었다... ㅜㅜ

패키지 구조상의 문제라던지 객체의 역할에 대한 이해도 부족, 와닿지 않는 메소드명도 한 몫 하고 있는 거겠지만

어쨌거나 중복 기능을 가진 객체가 증가한다는 것은 장기적으로 코드의 유지보수성을 더 어렵게 만든다는 것은 부정할 수 없다.

 

여기저기 퍼져있는 잘못된 일반적인 개념들이 객체지향적 사고를 방해하고, 선입견을 만들어 지금의 사태(?)에 이르렀다.

엘레강트 오브젝트를 읽고나니 이런 흔하지만 잘못된 개념들의 문제점과 생각의 전환을 시도해볼 수 있었다.

 

소개하는 원칙들에 대한 근거로 제시하는 내용들이 꽤 공감되는 부분이 많았고,

예제도 단순하고 이해하기 쉬워 개념을 적용해 생각하는데에 많은 도움이 되었다.

 

거대한 레거시 프로젝트에서 모두 적용해보려 한다면  나에게도 동료들에게도 혼란을 줄 수 있을것 같지만,

규모가 작거나 혹은 신규로 진행하는 프로젝트에서는 하나씩 적용해 본다면

'객체지향'에 대해 더 깊이 이해할 수 있지 않을까 하는 생각이다.

 

다음 글에서는 오브젝트를 읽고 나름대로 정리한 내용을 포스팅 해봐야겠다.