이 책을 읽으니
왜인지 좋은 객체지향적인 프로그램을 설계할 수 있을 것 같다는 근거없는 자신감이 솟아 오른다.
‘유일하게 변하지 않는 것은 모든 것이 변한다는 사실 뿐이다’ - 헤라클레이토스
소프트웨어 분야에서 예외가 없는 유일한 규칙은 요구사항이 항상 변경된다는 것이다.
지금까지 객체지향적으로 설계하는 것에 어려움이 있었던 이유는 이 책에서 찾아볼 수 있었다.
나는 어떠한 협력 관계에서 필요한 행동을 정의하고 객체를 생성하는 것이 아닌
객체가 필요한 상태와 객체를 먼저 정의하고 그 상태에 필요한 행동을 결정했었다.
항상 개발하다보면 캡슐화가 깨지는 거 같은 느낌이 드는 이유가 여기에 있었다.
책에서는 이렇게 말한다.
객체의 상태를 먼저 결정할 경우 캡슐화가 저해된다.
상태에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되어버릴 확률이 높아진다.
객체에서 중요한 것은 행동이다.
상태는 행동의 결과로 초래된 부수효과를 쉽게 표현하기 위해 도입된 추상적인 개념일 뿐이다.
객체를 창조할 때 가장 중요하게 고려해야 하는 것은 객체가 이웃하는 객체와 협력하기 위해 어떤 행동을 해야할 지 결정하는 것이다.
객체는 섬이 아니다. 객체를 고립적으로 보지 말아야 한다.
객체는 자신의 상태를 자율적으로 관리한다. (자신의 상태를 변경하는 주체는 자신이어야 한다.)
책임의 자율성이 협력의 품질을 결정한다.
손님은 직원이 메뉴판을 어떻게 가져오든 상관없다.
자신이 보낸 메시지(메뉴판 요청)에 맥도날드 직원의 책임(메뉴판 응답)을 믿고 기다릴 뿐이다.
맥도날드 직원은 책임에 대한 자율성이 보장된다.
추상화가 잘 되어 있다면 이는 객체의 자율성은 자연스럽게 보장되어 있을 것이다.
잘못된 예시를 보자
손님이라는 객체가 맥도날드 직원의 책임에 자율성을 억제했다.
이러한 설계는 객체간의 결합도를 높일 수 있으므로 지양하는 것이 바람직 하다.
책임의 자율성이 협력의 품질을 결정한다.
- 자율적인 책임은 세부적인 사항들을 무시하고 의도를 명확하게 표현함으로써 협력을 단순하고 이해하기 쉽게 만든다.
- 자율적인 책임은 객체의 외부와 내부를 명확하게 분리한다.
직원이 메시지를 수신하면 ‘메뉴판을 준다’라는 책임만 완수하면 된다.
어떤 방법으로 메뉴판을 선택할지는 직원의 권한이다. 본인이 가지고 있는 상태에 따라 선택할 수 있다. - 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
손님은 메뉴판을 받으면될 뿐, 직원이 뛰어가든, 걸어가든, 공중제비를 돌든 상관할 필요가 없다.
직원이 메뉴판을 가져오는 것은 손님의 메시지에 의한 책임을 수행하는 내부적인 방법이다. - 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
자율적인 책임을 통해 당신은 메뉴판을 드론으로 전달해주는 특이한 직원과도 협력할 수 있는 것이다.
자율적인 책임이 있다면 위의 협력에서 손님은 특정 직원이 아닌, 메뉴판을 어떤 방식으로든 가져올 수 있는 아무 직원과 협력할 수 있다. - 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.
도메인 관점에서 객체가 은유하는 개념을
명세 관점에서 객체의 공용 인터페이스를
구현 관점에서 객체의 속성과 메서드를
적절하게 파악하여 설계하는 것을 목표로 공부하도록 하자
'일기' 카테고리의 다른 글
부트캠프에서의 첫 협업, 느낀점과 고쳐야할 점 (0) | 2023.07.06 |
---|---|
[Git] Smart checkout, pull 하다가 작업 내용 날아감 (0) | 2023.07.03 |
나는 개발을 좋아하는가 (0) | 2023.04.07 |
[BaekjoonHub] BOJ, 프로그래머스 문제 GitHub에 자동으로 push 하기 (0) | 2023.04.03 |
[우아한 테크코스 5기] 백엔드 프리코스과정 회고 (1) | 2022.11.24 |