조영호님과 객체지향에 대해서 이야기하기

  트레바리에서 (전) CTO님 덕분에 오브젝트 저자 조영호님과 티타임을 가질 수 있는 기회가 생겼습니다. 티타임 자리에서 물었던 질문에 대해서 기록을 남깁니다.

아쉽게도 사진은 찍지 못했지만, 관련해 이야기 나눈 부분에 대해서 공유하기 위해 기록합니다.

대화했던 내용을 녹음했던 것은 아니였기 때문에, 정확하지 않을 수 있습니다.

Q. 추상화란 무엇인가?
A. 추상화는 필요없는 것을 없애는 것이다. 동시에 추상화는 용도와 의도가 명확해야 한다.
처음부터 추상화를 발견할 수는 없다. 절차지향으로 코드를 작성하고 난 뒤에 중복이 발견될 때, 추상화 될 가능성이 농후하다.
그러므로, 리팩토링을 통해 추상화를 만들어내자. 추상화는 어쩔 수 없이 탑-다운 방식이 아닌 바텀-업 방식에서 나타날 수 밖에 없다.

Q. 추상화의 정도는 어떻게 가져가야 하는가?
A. 이미 우리가 가진 요구사항이 있고, 그 요구사항을 정제해서 만든 문장에서 출발한다면 적절하다.

Q. 리팩토링을 하기 좋은 코드를 작성하는 방법은 무엇인가?
A. 나중에 다시 살펴보더라도 이해가 가능하도록 최대한 심플하게 작성해야 한다.

Q. 메서드 이름은 어떻게 지어야 할까?
A. Client 관점에서 전달받고자 하는 메세지가 무엇인지 고민해야 한다. 그래야 좋은 이름이 나온다.

Q. 객체지향과 절차지향은 사용될 수 있는 영역이 다르다. 어떻게?
A. 데이터 관점으로 다뤄야 하는 영역은 Controller, Repository 이다. 이 영역은 절차지향으로 작성해도 무관하다. 
객체로 다루는 영역은 자주 변경될 수 있는 도메인 영역이다. 여기에 우리가 아는 객체지향프로그래밍을 해야 한다.
객체 지향 프로그래밍은 명사로 설명 가능하다. 그러나 절차지향프로그래밍은 동사로 이야기해야만 한다.

Q. 핵사고날 아키텍쳐를 사용하면 이점이 있는 것이 맞을까? 레이어드 아키텍처와 크게 다르지 않는 것 같다.
A. 핵사고나이던, 레이어드 아키텍쳐이던 우리가 이런 아키텍쳐를 활용하는 이유는 관심사를 분리하여 인지 부조화를 줄이기 위해서 사용되는 것이다.  

Q. 사내에 학습한 내용을 적용하고 싶다면 어떻게 해야될까?
A. 사내에서 뭔가 하고싶다면, 자신이 관리할 수 있는 선을 긋고 그 선에서 마음껏 한다.

Q. 좋은 설계를 하기 위한 팁? (이 부분은 질문은 기억나지 않지만 설계할 때 고려해야될 부분 이라 판단했습니다)
A.
- 수직/수평적 사고에 대해서 고민해야한다. (ex, 레이어별로, 도메인 별로, 그 외 다른 N 축으로)
- 데이터를 쓰는 영역과 객체를 쓰는 영역을 분리해보기
- 자주 바뀌는 곳이 핵심 도메인이다.

Q. ValueObject 가 잘 사용되려면?
A.
- 이름의 위치를 명시적으로 타입으로서 노출합니다.
- 타입에 따른 유연성을 피할 수 있게 됩니다.
- 행위가 있어야 합니다.(메서드가 없으면 의미가 없다)

Q. 도메인 서비스 Tip (코드 리뷰 중 도메인 서비스가 또다른 도메인 서비스를 호출하는 코드를 보고 했던 이야기)
A. 도메인 서비스를 사용하는 이유는 여러 도메인 사시에서 애매한 것을 메꾸기 위한 용도로 사용된다. 그러므로, 도메인 서비스에서 도메인 서비스를 사용하는 것은 어색하다. 가급적이면 도메인 서비스에 Repository가 들어가면 안된다. 애그리거트와 도메인 서비스는 Set 이다.

 

그 외 동료분들이 남긴 내용