[객(체지향의)사(실과)오(해)] 4. 역할, 책임, 협력 (부제 : 그래 팩토리를 더 써먹어보자)

이번에는 책에서 실제로 디자인 패턴이라는 이야기도 나왔었다. 

어떻게 보면 3장에서 추상화를 시키는데, 이를 통해 얻을 이점이 무엇인가를 생각할 수 있었다. 

 

예시를 보자면, 앨리스의 법정 경험(?)이 있을 것 같다. 

법정에서 재판장, 관리자, 증인의 역할을 하는 사람들이 존재한다. 

이를 역할로 구분해보면

• 재판장은 관리자에게 다음 증인을 부러오라고 한다. 
• 증인은 증인들중 다음 사람을 골라 불러온다. 
• 증인은 재판장에게 증언을 한다. 
• 재판장은 증인의 증언을 듣고 판단한다. 

의 구조를 가진다. 

 

나는 역할을 생각해서 이렇게 각자 하는 일들을 정했다면, 역할명의 인터페이스로 해당 메서드들을 만든다. 

지금의 메서드는 void타입으로, 파라미터 없이 만들어둔 후에 객체간의 협력관계를 바탕으로 파라미터를 입력시키거나, 반환타입을 정해준다. 

 

그렇게 만들어진 인터페이스의 최종적인 구조를

이렇게 만들었다. 

이를 실제 객체에 맞게 구현해주는 방식으로 했다. 

인터페이스를 만듦으로써, 1장에서 이야기했던 '역할은 다른 객체가 대체할 수 있다'를 충족시킬 수 있다. 

다른 객체가 해당 역할을 수행할 수 있게 하려면, 인터페이스를 implement해주는 방식으로 진행했다.

 

이를 통해, Judge는 앨리스가 오건, 주방장이 오건, 모자장수가 오건 모두 Witness라는 역할로써 오기 때문에 다 수용할 수 있게 된다. 

 

이런 방식의 장점이 무엇일까?

• 디자인 패턴 : 이렇게 역할별로 구현할 때 더 효율적인 객체 생성이 가능해질 것 같다. 
• 테스트 주도 설계 : 만약 역할로써 묶여있지 않고 모두 다른 클래스로만 구현되어있다면, 모든 객체들은 각자 테스트 코드를 가지게 된다. 하지만 인터페이스라는 역할들을 가지게 도는 객체로만 되어있다면, 해당 역할들에 대한 테스트를 통해 객체가 가지는 테스트들을 전부 할 수 있지 않을까 라는 생각이 든다. 

책에서는 책임 주도 설계또한 이야기가 되었는데, 장점이라고 생각하기에는 뭔가 괴리감이 들었다. 

책에서 알려주는 개발의 방식은 역할을 중심으로 이루어지는 느낌이 들었다. 

역할에는 해당 역할을 수행해야 하는 책임이 따른다.

그렇다면, 역할을 위주로 개발하는 것 자체가 책임 주도 설계가 아닐까?

장점이라기 보단, 책임 주도 설계에 대한 '패턴'이 역할 중심의 개발이 아닐까 라는 생각도 든다. 

 

개인적인 생각이기 때문에, 시간이 지나면서 달라질 수 있지만, 지금까지의 공부로는 그렇게 느껴진다고 생각이 든다. 

책을 읽으면서 java에 대해서, 디자인 패턴에 대해서 공부하는게 서로 이익이 되는 방식이라는 것이 너무 좋았다. 

더 열심히 살아봐야지

 

그럼...twenty thousand...🔥