본문 바로가기

책/오브젝트 (완)

(17)
07 객체 분해 이전 장까지는 객체지향이 무엇인지 또 어떻게 해야 객체지향적으로 설계를 할 수 있을지에 대해 이야기를 했다면 '7장 객체분해'에서는 객체지향의 본질에 대해 설명하는 챕터였습니다. 7장을 읽기 이전까지는 객체간의 의미있는 협력을 하게끔 유도 하는 것 == 객체지향이라 생각을 하였습니다. 그러나 7장에서는 '데이터 추상화'를 한 것이라 언급을 하며 객체지향이 탄생하기 까지 어떤 일들이 있었는지 이야기를 하며 이야기를 이끌어 나갔습니다. 이처럼 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을 추상화라고 한다. ... 큰 문제를 해결 가능한 작은 문제로 나누는 작업을 분해라고 부른다. 객체지향을 이야기하기 이전 객체지향이 주로 다루는 '추상화'..
06 메시지와 인터페이스 https://goto-pangyo.tistory.com/230 05 책임과 메시지 4장에 이어 5장에서는 설계에 도움이 될 법한 실질적인 조언을 해주고 있습니다. 저자는 '메시지'의 역할 및 중요성을 이야기하고 이를 설계와 코드에 어떻게 녹이며, 인터페이스의 역할에 대해 goto-pangyo.tistory.com 이미 비슷한 내용으로 포스팅을 했었습니다. 그러나 오브젝트에서 언급하는 메시지는 조금더 구체적이고 또 실제 개발을 할 때 도움이 되는 내용들이였다는 느낌을 받았습니다. 추가로 "6장 메시지와 인터페이스"는 좋은 내용들이 풍부하지만 "객체지향의 사실과 오해"에서 다루었던 내용은 간략하게 설명하거나 건너뛰며 글을 작성하고자 합니다. 훌륭한 객체지향 코드를 얻기 위해서는 클래스가 아니라 객체를 지향..
5장 책임 할당하기 4장에서는 책임중심의 접근법이 아닌 데이터중심의 접근법의 문제점을 짚어보았습니다. 그리고 5장에서는 어떻게 해야 책임을 잘 할당할 수 있는지를 언급하였습니다. 기억에 남는 접근법은 총 두개가 있는데 하나는 처음에 설계를 할 때부터 GRASP 패턴으로 접근하는것 다른 하나는 절차지향적으로 코드를 먼저 작성하고 이를 리팩토링 하는 것입니다. 다행히도 GRASP 패턴의 경우 이미 1~4장까지 언급한 내용과 동일하다는 것입니다. 객체에게 할당된 책임이 협력에 어울리지 않는다면 그 책임은 나쁜 것이다. 객체의 입장에서는 책임이 조금 어색해 보이더라도 협력에 적합하다면 그 책임은 좋은 것이다. 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다. 이는 "객체지향의 사실과 오해"라는 책에서도 나오는 대..
4장 설계 품질과 트레이드오프 4장에서는 1~3장까지 책에서 이야기해온 책임주도 설계가 가지는 특징들을 응집도와 결합도를 위주로 설명한 장이였습니다. 특히 1~3장에서는 책임 주도 설계 방식으로 구현하는 방법및 장점들을 위주로 설명했지만 4자에서는 설계를 할 때 객체가 가지는 데이터를 중심으로 설계 했을때 생기는 단점에 대해 언급하며 이야기를 풀어나갔습니다. 객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다. 객체지향 설계를 "결합도"와 "응집도"를 바탕으로 설명하는 글입니다. 결합도와 응집도를 합리적인 수준으로 유지할 수 있는 중요한 원칙이 있다. 객체의 상태가 아니라 객체의 행동에 초점을 맞추는 것이다. 이전 장에서 계속 이야기한 내용입니다. 포스팅을 하며 문득 든..
3장 역할, 책임, 협력 3장에서는 그 동안 이야기 하였던 역할, 책임, 협력을 보다 상세하게 설명하는 챕터였습니다. 3장을 다 읽은 지금 가장 기억에 남는 것 하나를 고르자면 역할은 슬롯과 같다는 말이였던것 같습니다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 과정에서 드러난다. 협력을 생각할때 중요하게 여겨야 하는 것중 하나라고 생각합니다. 1. 이처럼 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다. 2. 객체가 협력에 참여하기 위해 수행하는 로직을 책임이라고 부른다. 3. 객체들이 협력 안에서 수행하는 책임이 모여 객체가 수행하는 역할을 구성한다. 그 동안 자주 언급되었던 협력, 책임, 역할을 추상적으로 설명하는 것이 아닌 구체적으로 이야기하였기에 3장에서 가장 중요한 부분이라 ..
2장 객체 지향 프로그래밍 주요 키워드 도메인 1장에서는 객체지향 프로그래밍을 공부하기 앞서 어떠한 코드가 좋은 코드인지 알려주는 내용이였다면 2장에서는 객체지향 프로그래밍하면 빠질수 없는 "다형성", "캡슐화", "접근제어자"같은 개념들을 위주로 설명하는 파트였습니다. 객체지향의 핵심 키워드를 다시 짚어가며 공부를 했기에 복습한다는 느낌으로 읽었고 제가 중요하다고 느낀것들을 인용하고 만약 제가 따로 코멘트 할 것이 있다면 따로 남기고자 합니다. 진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 1장에서도 그랬듯 2장의 서두에서 객체지향의 본질은 클래스가 아닌 객체라고 언급하는 것을 확인할 수 있습니다. 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. 1장의 말..
1장 객체, 설계 주요 키워드 자율성 캡슐화 응집도 객체지향 책임의 이동 의존성 의인화 데이터, 프로세스 해당 장에서 제시하는 코드는 "자율성", "책임", "응집도"등 모든 면에서 객체지향스럽게 작성하지 않은 코드들입니다. 즉 해당 코드에서 나타나는 여러 문제점들을 차차 수정해나가며 공부를 해나가도록 저자는 유도를 하고 있습니다. 그리고 저는 이를 따라가고자 합니다. 1장에서 구현한 프로그램은 티켓을 판매하는 프로그램으로 UML은 다음과 같습니다. 그리고 이러한 UML을 바탕으로 구현한 코드는 다음과 같습니다. public class Theater { private TicketSeller ticketSeller; public Theater(TicketSeller ticketSeller) { this.ticketSelle..