💡 조영호님의 오브젝트를 읽고 생각을 정리하였습니다. 객체지향 설계를 하는 이유는 궁극적으로 앞으로의 설계 변경에 쉽게 대응하기 위함인 것 같다. 책에서는 왜 객체지향설계를 하면 설계변경에 대응하기 쉬운지 데이터지향 설계를 했을 때의 단점을 보여주면서 설명해 주고 있다. 또한 좋은 설계를 판단하는 기준으로 캡슐화, 응집도, 결합도에 대해서 설명하고 있다. 캡슐화 목적 객체의 내부 구현을 외부로 부터 감추는 것 구현이란? 변경 가능성이 높은 부분 인터페이스? 상대적으로 안정적인 부분 불안정한(변경가능성 높은) 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화하자 궁극적으로 이뤄내려는 것 높은 응집도와 낮은 결합도는 캡슐화로 부터 나온다 응집도 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도 하나의 변경..

💡 조영호님의 오브젝트를 읽고 생각을 정리하였습니다. 이번 장에서는 시스템을 객체지향 패러다임을 통해 만들기 위해 “객체들의 협력하는 공동체”를 만들어야한다는 전제하에 어떤 사고의 흐름을 통해 만들어 낼 수 있을 것인가를 설명하고 있다. 객체 한 개를 만들기 위해 어떤 사고 과정을 거쳐 나가야할까? 어떤 애플리케이션에 객체가 존재하는 이유는 해당 객체가 “협력”에 참여 하고 있기 때문이다. 즉, 객체는 협력에 필요한 특정 행동을 하고 있을 것이다. 따라서 아래의 사고 과정을 거쳐서 하나의 객체를 만들 수 있을 것이다. 기능 제공을 위해 어떤 협력이 필요할까? (베이스 깔고 가는생각) 협력은 설계를 위한 문맥을 제공하기 때문에 가장 우선시 되어 생각되어야한다. 협력 안에서 어떤 책임(행동)이 필요할까? 시..

💡 조영호님의 오브젝트를 읽고 생각을 정리하였습니다. 조영호님의 “객체지향의 사실과 오해”라는 책을 읽고 어느 정도 객체지향이란 무엇 인가에 대해 느낌을 얻을 수 있었습니다. 하지만 해당 책에서는 코드보다는 이상한 나라의 엘리스에서의 예시를 가지고 설명을 해주어서 모호한 느낌을 받은 부분이 있었습니다. 현재 프로그램을 개발하면서, 객체의 책임과 역할에 대해서 생각해보고 어떤 메세지를 통해 서로 소통할 수 있게 할 것인가 고민하던 찰나 좋은 코드를 보고 싶다는 생각이 들었습니다. 마침 “ 오브젝트” 라는 책에서는 실제 코드를 기준으로 이야기를 해준다고 해서 읽게 되었고 읽은 내용을 정리하고자 합니다. 첫번째 챕터는 마치 “객체지향의 사실과 오해” 요약본 같았습니다. 중요 키워드로는 의존성, 캡슐화, 설계 ..

💡 조영호님의 객체지향의 사실과 오해를 읽고 정리하였습니다 자율적인 책임 객체가 어떤 행동을 하는 유일한 이유는 다른 객체로 부터 요청(메세지)를 받았기 때문임. 받은 요청을 처리하기 위해 객체가 수행하는 행동을 ‘책임’이라고함 책임을 수행하는데 있어 방법은 객체마다 다를 수 있고 자율적임. 해당 방법을 요청하는 객체가 제한하는 것은 좋지 않음 따라서, 어떻게 책임 질 것인가 보다는 무엇을 책임질 것인가가 중요함 메시지와 메서드 메세지 하나의 객체는 메세지를 전송함으로서 다른 객체에 접근함 왕이 모자 장수에게 ‘증언하라’라는 메세지를 보낸는 경우 모자 장수.증언하라(인자) 인자에는 증언에 필요한 정보가 들어갈 수 있음(언제, 어디서 등등) 메서드 메세지를 수신하는 객체가 메세지를 처리하기 위해 내부적으로..

💡 조영호님의 객체지향의 사실과 오해를 읽고 정리하였습니다 기억에 남는 문구 객체의 세계에서 협력이라는 문맥이 객체의 행동 방식을 결정함 객체지향 설계의 전체품질을 결정하는 것은 여러 객체들이 모여 이뤄내는 협력의 품질 어떤 협력에 참여 하는지가 객체에 필요한 행동을 결정, 필요한 행동이 객체의 상태를 결정 결론 : 객체지향 설계란 애플리케이션의 기능을 구현하기 위한 협력 관계를 고안하고, 협력에 필요한 역할과 책임을 식별한뒤 이를 수행할 수 있는 적절한 객체를 식별해 나가는 과정 객체지향의 세계는 동일한 목적을 이루기위해 협력하는 객체들의 공동체 협력 협력의 본질은 요청과 응답으로 연결되는 사람들의 네트워크 특정 요청을 보냈다는 것은 해당 객체가 요청에 대한 의무를 가지고 있고 요청에 필요한 지식을 가..