[독서] 객체지향의 사실과 오해 2장~7장

5월에 읽고 뒤늦게 올리는 후기
기차타고 온 날 적느라 나열만 한 수준이다.
저장되어있던 거 나라도 알아볼 수 있게 조금 수정하고 올림

---

기억에 남는 것

1. (어떤) 메시지를 누구에게 보낼 것인지 기억해라

전달해야 할 메시지를 먼저 정한 후, 그걸 수행할 객체를 정하자


2. 구조에 기능을 맞추는 것이 객체지향과 일맥상통한다.

단, 사용자의 요구사항을 중요시하여 기능을 먼저 정하고 이후에 어떤 구조를 쓸지 정할 때는 다른 경우이다.


3. 인터페이스와 구현부를 분리하면 구현부의 메커니즘이 변해도 인터페이스를 사용하는 것에는 문제가 없다.

자동차 수리를 한다해도 운전자는 그대로 자동차(=인터페이스)를 이전과 같이 운전할 수 있다.
수행해야할 책임=역할이 변하지 않는다면 그 내부 구현이 변하더라도 똑같이 인터페이스가 동작한다.

그리고 실제 엔진구조를 몰라도 운전이 가능하듯이 내부기능은 드러나지 않아도 된다.

또한 한 대의 자동차를 운전할 줄 안다면 다른 자동차도 운전할 수 있다.


4. 도메인 모델을 파악하면 사용자, 개발자, 디자이너의 종합적인 관점을 알 수 있다.


5. 클래스를 객체의 단위로 보는 건 매우 제한적인 관점으로 보는 것이다.

클래스는 객체를 다루는 도구로 쓰는 틀이지 객체 전체를 아우를 수 없다. 각각 존재하는 인스턴스들, 객체 그 도메인들을 파악해야 한다.


6. 드러나도 되는 부분은 공용인터페이스화를 하지만 이 때 인터페이스의 수는 너무 많지 않아야 한다.

추상화는 보다 포괄적인 단위어야 하기에 세세하게 인터페이스를 쪼개면 그 의의에 맞지 않다.

7. 메시지 송신자는 수신자가 해당 책임에 맞게 메서드를 실제 수행하는지를 중요시 해야지, 그 내부 동작이 세세하게 어떤 식으로 돌아가는지까지 알 필요없다.

수신자 객체가 돌아가는 메커니즘은 캡슐화되어있고 자율적인 영역이기 때문이다.


8. 밖에서 그 자율적인 영역에 대해 알려하고 그 내부 동작에 변형을 가할 수 있다면 더이상 객체의 자율성을 보장할 수도, 은닉이라 할 수도 없다.

9. 어떤 '행위'가 이루어져야 하는지 먼저 파악해야 이후 어떤 객체에게 역할을 할당할지 적절하게 분배할 수 있다.

각 객체만을 먼저 파악하려하면 그 객체의 성질에 맞게 배정을 하려할 수도 있는데 실제로는 모든 행위가 객체의 특성과 밀접한 관련이 없을 수도 있으며 행해져야 할 행위에 비해 쓸 데 없이 객체를 할당하게 되어 복잡하다.

게시판을 만든다고 했을 때,
제목, 내용, 목록, 글쓰기 버튼이 있어야 해! (△)
↓
글을 조회할 수 있어야 해. 그걸 목록으로 볼 수 있어야 해.
글을 등록하고 수정하고 삭제할 수 있어야 해.
그 행위는 버튼으로써 수행할 수 있어야 해.


투두리스트를 만들 때
날짜, 항목, 완료여부 등이 있어야 해(△)
↓
할일 목록을 불러오고 추가, 수정, 삭제할 수 있어야 해
할일 목록을 추가할 때 항목명, 날짜 등이 포함되어야 해.
등록된 할일 목록을 보고 체크를 하면 완료 상태가 변경되어야 해.