개발자도 비즈니스 참여를

(번역) 루비에서 상속을 피하는 방법 을 읽고. (링크 유실)

요즘 '객체 지향 이란 무엇일까?' 라는 원론적인 질문에 꽂혀 있어서 그런지, 굉장히 흥미를 일으키는 제목의 글이었습니다. 저는 2년간 자바만 해서 루비를 전혀 모릅니다. 그래서 읽으면서 어림짐작으로 루비 소스를 자바 소스로 뇌컴파일 해가며 읽었는데 역시나 재밌었습니다.

상속이 아닌 위임으로

이 글은 제목 그대로 '상속을 피하기 위한'에 대한 솔루션을 제공하고 있습니다. 상속(확장)이 아닌 위임을 통해서 말이지요. 템플릿 메서드 패턴이냐 스트래티지 패턴이냐로 구분지어 볼 수도 있을 것 같아요.

물론 절대적으로 상속보다는 위임이 좋다는 건 아닙니다. 상황에 따라 충분히 선택의 여지가 있습니다. 이 글의 예에서는 스트래티지 패턴이 더 적합하다고 판단되어진 것이구요.

결국엔 클린코드

사실 제가 더 감명 깊었던 점은 결국 클린코드의 중요성을 또 한번 느낀 것입니다. 만약 이 기능들이 확장을 이용한 방법(첫번째 방법)으로 설계가 되었고, 이대로 서비스가 운영되는 도중에 추가 변경 사항이 들어 온다면? 그제서야 Car / Truck 이라는 객체를 더 세분화된 모듈로 쪼개고(Body, Engine 등) 위임을 통한 구현 형태로 변경하려 한다면? 그 변경에 대한 파급력은 굉장히 클 것 이기 때문에 서비스 관점에서는 부담스러울 수 밖에 없습니다. 결국 첫번째 방법에서 제시한 추가 상속(확장)을 통한 (불필요한 중복)클래스를 계속 생성해 나가려 하겠지요 ?

(하지만 누군가, 언젠가 반드시 바꾸어야 한다면 빨리 바꾸는게 좋습니다. 바꾸세요 ! )

개발자도 비즈니스 단계부터 참여를

물론 처음 설계한 사람만의 잘못은 아닙니다. 왜냐하면 변경은 예측할 수 없기 때문입니다. 처음 설계자 역시 이러한 변경이 있을 거라 예상했다면 저렇게 설계를 하지 않았겠지요 ?

개발자 A : 우리회사가 전기차를 판매할 줄 어떻게 예측해 ?!

변경을 잘 예측하고, 그에 대응할 수 있는 코드를 잘 짜려면 비즈니스 담당자와도 꾸준히 커뮤니케이션을 해야합니다. 개발자도 비즈니스 단계에서 부터 같이 관심을 가지고 참여하면 더 좋겠네요 ! 메이커 레벨에서 예측할 수 없는 변경을 그들은 이미 논의중 일수도 있으니까요 !