[도서] 객체지향의 사실과 오해 : "행동이 상태를 결정한다"

 

객체지향의 사실과 오해 (조영호)

 

65p

결과적으로 우리가 애플리케이션 안에서 어떤 행동을 원하느냐가 어떤 객체가 적합한지를 결정한다. 객체의 적합성을 결정하는 것은 상태가 아니라 행동이다. 

 

 

66p

"행동이 상태를 결정한다".

 

 

126p

역할은 객체지향 설계의 단순성(simplicity), 유연성(flexibility), 재사용성(reusability)을 뒷받침 하는 핵심 개념이다. 

 

 

128p

많은 사람들은 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다는 선입견을 가지고 있다. 물론 객체가 상태의 일부로 데이터를 포함하는 것은 사실이지만 데이터는 단지 객체가 행위를 수행하는 데 필요한 재료일 뿐이다. 객체가 존재하는 이유는 행위를 수행하며 협력에 참여하기 위해서다. 따라서 실제로 중요한 것은 객체의 행동, 즉 책임이다. 

 

 

129p

일단 객체에게 책임을 할당하고 나면 책임은 객체가 외부에 제공하게 될 행동이 된다. 협력이라는 문맥에서 객체가 수행하게 될 적절한 책임, 즉 행동을 결정한 후에 그 행동을 수행하는 데 필요한 데이터를 고미해야 한다. 그리고 객체가 협력에 참여하기 위해 필요한 데이터와 행동이 어느 정도 결정된 후에 클래스의 구현 방법을 결정해야 한다. 결과적으로 클래스와 데이터는 협력과 책임의 집합이 결정된 후에야 무대 위에 등장할 수 있다. 

 

 

136p

테스트-주도 개발은 테스트를 작성하는 것이 아니라 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성하는 것이다. 

 

 

149p

메시지를 수신한 객체가 실행 시간에 메서드를 선택할 수 있다는 사실은 다르프로그래밍 언어와 객체지향 프로그래밍 언어를 구분 짓는 핵심적인 특징 중 하나다. 이것은 프로시저 호출에 대한 실행 코드를 컴파일 시간에 결정하는 절차적인 언어와 확연히 구분되는 특징이다. 

 

 

155p

클래스가 코드를 구현하기 위해 사용할 수 있는 중요한 추상화 도구인 것은 사실이지만 객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지로부터 나온다. 

 

 

157p

책임-주도 설계 방법에서 역할, 책임, 협력을 식별하는 것은 애플리케이션이 수행하는 기능을 시스템의 책임으로 보는 것으로부터 시작된다. 시스템이 수행할 책임을 구현하기 위해 협력 관계를 시작할 적절한 객체를 찾아 시스템의 책임을 객체의 책임으로 할당한다. 객체가 책임을 완수하기 위해 다른 객체의 도움이 필요하다고 판단되면 도움을 요청하기 위해 어떤 메시지가 필요한지 결정한다. 메시지를 결정한 후에는 메시지를 수신하기에 적합한 객체를 선택한다. 수신자는 송신자가 메시지를 보내면서 기대한 바를 충족시켜야 한다. 즉, 수신자는 송신자가 기대한 대로 메시지를 처리할 책임이 있다. 

 

 

176p

자율적인 책임의 강력함을 느낄 수 있는가? 책임이 자율적일수록 협력이 이해하기 쉬워지고, 객체의 외부와 내부의 구분이 명확해지며, 변경에 대한 파급효과를 제한할 수 있고, 유연하게 변경할 수 있는 동시에 다양한 문맥에서 재활용할 수 있게 된다. 

 

책임이 자율적일술고 적절하게 '추상화'되며, '응집도'가 높아지고, '결합도'가 낮아지며, '캡슐화'가 증진되고, '인터페이스와 구현이 명확히 분리'되며, 설계의 '유연성'과 '재사용성'이 향상된다. 

 

 

177p

유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.  - 헤라클레이토스(Heraclitus of Ephesus)

 

 

182p

개발자의 삶이 고단하면서 흥미로운 이유는 요구사항이 예측 불가능하게 변겨오디기 때문이다. 훌륭한 설계자는 사용자가 만족할 수 있는 훌륭한 기능을 제공하는 동시에 예측 불가능한 요구사항 변경에 유연하게 대처할 수 있는 안정적인 구조를 제공하는 능력을 갖춰야 한다. 

 

 

188p

안타깝게도 대부분의 소프트웨어 도메인은 현실에 존재하지 않는 가상의 세계를 대상으로 한다. 게임 도메인은 현실에는 존재하지 않는 강력한 마법과 괴물들의 천국이다. 인터넷은 지금까지 현실 세계에서는 존재하지도, 가능하지도 않았던 새로운 유형의 서비스를 창조해왔다. 가상의 세계를 창조하는 작업에서 현실 객체를 은유하라는 목소리는 공허한 메아리일 수밖에 없다.

 

그렇다면 우리가 은유를 통해 투영해야 하는 대상은 무엇인가? 그것은 바로 사용자가 도메인에 대해 생각하는 개념들이다. 즉, 소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상은 바로 도메인 모델이다. 

 

 

197p

유스케이스 관련 아티클 [Structuring Use Cases With Goals]

https://www.researchgate.net/publication/2807676_Structuring_Use_cases_with_goals

 

 

199p

유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점을 제공한다. 도메인 모델은 기능을 수용하기 위해 은유할 수 있는 안정적인 구조를 제공한다. 책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조한다. 

 

 

202p

책임 할당의 기본 원칙은 책임을 수행하는 데 필요한 정보를 가진 객체에게 그 책임을 할당하는 것이기 때문이다. 이것은 관련된 상태와 행동을 함께 캡슐화하는 자율적인 객체를 낳는다.