개발서적/오브젝트 - 조영호

Chapter 7. 객체 분해

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 프로시저 추상화와 기능 분해 💡 프로시저는 반복적으로 실행되거나 거의 유사하게 실행되는 작업들을 하나의 장소에 모아놓음으로써 로직을 재사용하고 중복을 방지할 수 있는 추상화 방법이다. 전통적인 기능 분해 방법은 시스템을 구성하는 최상위 기능을 정의하고 작은 단계의 하위 기능으로 분해해 나가는 방법을 사용한다. 💡 세분화된 마지막 하위 기능이 프로그래밍 언어로 구현가능한 수준이 될 때까지 계속 된다. 하향식 프로시저 추상화를 통해 만든 프로그램은 다음과 같은 구성이 된다. 최상위 기능(){ 세부기능1(); 세부기능2(); 세부기능3(); .. } 최상위 기능을 수행하기 위한 여러개의 세부기능이 호출되어 원하는 최상위 기능을 수..

Chapter 6. 메시지와 인터페이스

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 메시지와 메서드 💡 메시지란, 객체가 다른 객체에게 유일하게 접근할 수 있는 방법이다. 자바 문법을 예로 들면 아래와 같은 것이 메시지 전송이다. 수신자.오퍼레이션명(인자); [ ex. condition.isSatisfiedBy(screening) ] ❓ 메세지와 메서드는 그러면 같은거 아니야? 만약, 수신자 객체가 인터페이스 형태가 아닌 구현체라면 맞는 말이 될 수 있다. 하지만, 🚨 수신자 객체가 인터페이스로 정의되어있다면, 해당 메시지를 어떻게 구현하느냐에 따라 실제 실행되는 프로세스가 달라진다. 따라서, 💡 메서드는 수신자 객체가 메시지를 받아, 실제로 실행되는 프로세스(함수)를 메서드라고 부른다. 메시지를 전송하는 ..

Chapter 5. 책임 할당하기

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 책임 주도 설계 데이터를 중심으로 설계하게되면 유연한 설계를 하기 힘들다. 애초에, '데이터' 라는 것은 객체의 구체적인 정보이고, 이는 구현에 해당한다. 따라서, 데이터 중심적 설계는 객체의 구현부에 초점을 맞추고 설계 한다는 의미이다. 그리고, 데이터를 중점으로 객체 간 협력을 생각하게 되면 외부 객체에게 자신의 데이터 정보를 넘겨주는 것이므로 캡슐화를 방해하게된다. 결과적으로, 구현을 중점으로한 설계는 캡슐화를 저해하고 응집도는 낮추고 결합도는 높임으로서 변화에 취약한 설계가 된다. 💡 따라서, 객체 지향의 핵심인 협력, 책임, 역할 중 가장 중요한 책임 을 중점으로 설계하는 것이 유연한 설계를 할 수 있게 해준다. [..

Chapter 4. 설계 품질과 트레이드오프

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 협력, 책임, 역할 그리고 설계 품질 협력은 객체들 간 메시지를 주고받으며 진행되는 상호작용이다. 책임은 객체가 수행하는 행동이다. 역할은 책임들의 집합이다. 협력, 책임, 역할 할당이 잘 되어야 바람직한 객체 지향 설계가 가능해진다. 💡 그 중에서도 책임이 잘 할당되는 것이 중요하다. 🚨 역할은 책임의 집합이기 때문에, 책임의 품질에 의존하게 된다. 협력 역시, 책임이 잘 할당되지 못하면 효율적으로 할 수 없게된다. ❓ 책임을 어떤 식으로 할당해야할까? 비슷한 책임끼리 하나의 목적을 위해 협력하는 것 끼리 모아두는 높은 응집도와 다른 책임끼리 분리하는 낮은 결합도를 만족하도록 하는 것이 좋다. 그래야만, 변경이 일어났을 때..

Chapter 3. 역할, 책임, 협력

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 객체 지향에서 가장 중요한 것은 💡 역할, 책임, 협력이다. 클래스, 상속, 지연 바인딩과 같은 개념은 구현에 초점이 맞추어져 있기 때문에, 애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할과 책임이 필요한지 고민을 하는 것이 더 중요하다. 1️⃣ 협력 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 말한다. 두 객체의 협력은, 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 객체는 다른 객체의 상세한 내부 구현에 직접 접근할 수 없으므로, 💡 메시지 전송을 통해 협력한다. 만약 다른 객체의 내부 구현에 접근하여 동작한다면, 객체의 자율성을 훼손하는 행위이다. 따라서, ..

Chapter 2. 객체지향 프로그래밍

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 객체 지향 프로그래밍을 할 때, 유념해야할 부분은 다음과 같다. 어떤 클래스가 필요한지 고민하기 전에 어떤 객체들이 필요한지 고민해야한다. 코드로서 바라보기 전에 기능이 동작되는 메커니즘을 잘 생각하라는 의미인 것 같다. 객체를 고립된 존재로 바라보지 말고 협력에 참여하는 협력자로 바라보아야 한다. 무작정 결합도를 줄이려고 노력하기 보다 효율적으로 협력하기 위한 방법을 고민하는 것이 필요하다. 클래스의 경계를 잘 구분 지어야 한다. Chapter 1에서도 많이 설명했듯이, 객체는 자신의 필드를 자신이 관리하도록 해야하며 그러기 위해서는 캡슐화를 통해 외부에 공개하지 않는 것이 좋다. 외부에서 접근이 가능한 메서드를 통해 간접..

Chapter 1. 객체, 설계

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 변경에 취약한 코드 public class Theater { private TicketSeller ticketSeller; public Theater(TicketSeller ticketSeller) { this.ticketSeller = ticketSeller; } public void enter(Audience audience) { // 관람객 가방에 초대권이 있다면? if (audience.getBag().hasInvitation()) { Ticket ticket = ticketSeller.getTicketOffice().getTicket(); // 티켓 제공 audience.getBag().setTicket(ticket..