객체지향의 사실과 오해

객체지향의 사실과 오해....

그동안 내가 객체지향 설계를 해본 적 이 있을까..? 나는 그냥 기능 만들기에만 급급했던 것 같다.
그런데 요즘 MicroSerivce를 회사에서 시행 하면서 Python/Django에 있는 기능을 Java/Spring Boot로 하나하나 옮기게 되었고 확장 가능한 설계에 대한 관심이 많아지게 되었다.

그러 던 중 해당책에 대해 추천을 많이 받게 되어 읽기 시작했다.

책에서 여러장에 걸쳐하고 싶은 말은 결국 다음과 같다.

확장 가능한 설계를 하려면 도메인 중심으로 객체지향 설계를 해야 한다.

그렇다면 객체지향 설계를 해야하면 어떻게 해야 할까.

해당 기능에 대한 협력을 파악하고 협력에 따른 메시지들로 책임을 분리해야 한다.

좀 더 자세히 말해보자면..

우선 유스 케이스를 명확히 정해 시스템이 가지는 책임을 파악해야 한다.
그리고 그 책임에 대해 협력 관계를 파악한다. 협력 관계를 통해 메시지를 정하고 그 메시지를 수행할 책임이 있는 객체들을 정한다. 특정 책임은 해당 속성(데이터 값)을 가지고 있는 객체가 담당한다.
각각의 객체는 다른 객체와 협력하며 스스로 행동 방법을 정할 수 있는 자율성을 가진다. 그리고 그 객체가 하는 행동은 캡슐화를 통해 해당 객체와 협력하는 객체는 그 객체가 내부에서 무슨 일을 하는지 알 필요 없이 협력할 수 있도록 도와주어야 한다. 이래서 인터페이스가 필요하다.

이렇게 안정적인 구조의 객체지향 설계 구조를 기반으로 설계를 하면 전체적인 구조가 바뀌지 않는 이상 기능 변동 이 있을 때 관련 객체의 구현 방법을 수정하면 되므로 안정적이게 설계할 수 있다.

쓰다 보니 말이 길어졌는데 결국 앞서 말했듯이 해당 기능에 대한 협력관계를 파악하고 그걸 담당하는 각각의 책임을 가지는 객체들로 분리하는 인사이트가 중요하다는 말 같았다.

사실 이 책을 읽었다고 내가 이제 객체지향 설계를 완벽하게 이해했다고 말하지는 못 하겠다. 그렇지만 먼 나라의 이야기 같았던 개념을 조금이나마 이해할 수 있었던 것에 의의를 두고 싶다.

앞으로는 코드를 작성하기 전에 책에서 말하는 것처럼 "협력관계를 통한 책임을 분리하는" 연습을 먼저 시작해보아야겠다.