내용
59pg,
객체는 식별자를 가지고 있고 값은 가지고 있지 않지만, 프로그래밍 언어의 관점에서 숫자도 Interger 클래스로부터 생성된 객체이다. 이런 오해의 소지를 줄이기 위해 값 객체(value object)라는 식별자를 가지지 않는 값을 가리키는 별도의 용어를 사용하기도 한다.
60pg,
일반적으로 객체의 상태를 조회하는 작업을 쿼리(query)라고 하고 객체의 상태를 변경하는 작업을 명령(command)이라고 한다. 객체가 외부에 제공하는 행동의 대부분은 쿼리와 명령으로 구성된다.
62pg,
버튼 이외의 다른 방법으로는 기계를 사용할 수 없다. 기계를 직접 열어 내부의 상태에 접근하려고 하지 않는다.
이것은 객체에 접근할 수 있는 유일한 방법은 객체가 제공하는 행동뿐이라는 점을 강조한다.
즉, 사용자는 객체가 제공하는 명령 버튼과 쿼리 버튼으로 구성된 인터페이스를 통해서만 객체에 접근할 수 있다.
객체 기계가 제공하는 버튼을 통해서만 상태에 접근할 수 있다는 점은 객체의 캡슐화를 강조한다.
64pg, 65pg
행동이 상태를 결정한다.
상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.
첫째, 캡슐화가 저해된다.
둘째, 협력에 적합하지 못한 객체를 창조하게 된다.
셋째, 다양한 협력에 참여하기 어려우므로 객체의 재사용성이 저하된다.
따라서 협력에 참여하는 훌륭한 객체를 양성하기 위한 가장 중요한 덕목은 상태가 아니라 행동에 초점을 맞추는 것이다.
객체의 행동은 객체가 협력에 참여하는 유일한 방법이다.
객체지향 설계는 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행된다.
책임-주도 설계는 협력이라는 문맥 안에서 객체의 행동을 생각하도록 도움으로써 응집도 높고 재사용 가능한 객체를 만들 수 있게 한다.
66pg,
객체지향 세계는 현실 세계의 단순한 모방이 아니다.
소프트웨어 상품은 실제 세계의 상품이 하지 못하는 행동을 스스로 수행할 수 있다.
현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다.
67pg,
레베카 워프스브록은 현실의 객체보다 더 많은 일을 할 수 있는 소프트웨어 객체의 특징을 의인화라고 부른다.
모든 생물처럼 소프트웨어는 태어나고, 삶을 영위하고, 그리고 죽는다.
69pg,
현실 세계와 객체지향 세계 사이의 관계를 좀 더 정확하게 설명할 수 있는 단어는 은유다.
은유란 실제로는 적용되지 않는 한 가지 개념을 이용해 다른 개념을 서술하는 대화의 한 형태다.
"그 여자 양 같아요."
프로그램 내의 객체는 현실 속의 객체에 대한 은유다.
은유 관계에 있는 실제 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어의 구조를 쉽게 예측할 수 있다. 이해하기 쉽고 유지보수가 용이한 소프트웨어를 만들 수 있다.
바로 이러한 이유로 모든 객체지향 지침서에서는 현실 세계인 도메인에서 사용되는 이름을 객체에게 부여하라고 가이드하는 것이다.
71pg,
객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 단지 이상한 나라를 창조하기만 하면 된다. 현실을 닮아야 한다는 어떤 제약이나 구속도 없다. 여러분이 창조한 객체의 특성을 상기시킬 수 있다면 현실 속의 객체의 이름을 이용해 객체를 묘사하라. 그렇지 않다면 깔끔하게 현실을 무시하고 자유롭게 여러분만의 새로운 세계를 창조하기 바란다. 앨리스를 매혹시킨 이상한 나라가 그런 것처럼 말이다.
느낀점
'모방'이라는 단어는 과하니 '은유'라고 단계를 낮춘 느낌이다.
이렇게 엄밀하게 따질 필요까지 있나 싶긴 하지만 정확한 표현이라고 생각한다.
챕터 마지막 페이지에 적혀있는 말이 결국 이 책에서 처음 말하고자 했던 것들에 대한 요약이자 멋진 서술이라 한 글자도 빠트리지 않고 다 적었다. 이 책에서 이렇게 감성적인 글귀를 보게될 줄이야. 인상 깊어서 사진도 찍었다.
'독서 > 객체지향의 사실과 오해' 카테고리의 다른 글
객체지향의 사실과 오해(~59pg) (0) | 2023.03.15 |
---|---|
객체지향의 사실과 오해(~38pg) (0) | 2023.03.13 |