조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. 상속의 2가지 용도 타입 계층 구현 : 부모 클래스는 일반적인 개념을 구현하고, 자식 클래스는 특수한 개념을 구현한다. 코드 재사용 : 상속만으로 자식 클래스는 부모 클래스의 코드를 재사용 할 수 있다. 하지만 부모 클래스와 자식 클래스가 강하게 결합된다는 단점 때문에, 객체 지향에서 권장되는 방법은 아니다. → 상속을 사용하는 일차적인 목표는 코드 재사용이 아닌 타입 계층을 구현하는 것이다. → 이를 위해서 객체의 행동을 기반으로 타입 계층을 구성해야 한다. 타입 개념 관점의 타입 → 공통의 특징을 공유 타입 : 우리가 인식하는 객체들에 적용하는 개념이나 아이디어를 가리켜 타입이라고 부른다. 심볼(symbol) : ..

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. 상속의 목적은 코드 재사용이 아닌, 타입 계층의 구조화를 위해서 사용해야한다. → 다형성을 위한 서브타입 계층을 구축하는 것의 진정한 목적을 가지고 있어야만 한다! 관점에 따른 상속 데이터 관점의 상속 : 자식 클래스의 인스턴스 안에 부모의 인스턴스를 포함하는 것. 행동 관점의 상속 : 부모 클래스가 정의한 일부 메서드를 자식 클래스의 메서드로 포함하는 것. → 런타임에 시스템이 자식 클래스에 정의되지 않은 메서드가 있을 경우, 이 메서드를 부모 메서드에서 탐색한다. → 객체의 경우에는 서로 다른 상태를 저장할 수 있도록 인스턴스별로 독립적인 메모리를 할당받아야한다. 하지만 메서드의 경우에는 동일한 클래스의 인스턴스끼..

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. Chapter 10 상속과 코드 재사용 [상속과 중복코드] 중복코드의 단점.. 중복 코드는 변경을 방해한다! (중복 코드를 제거해야 하는 이유) 코드를 수정하는데 드는 노력이 몇배나 증가한다. 요구사항이 변경 됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복이다! DRY 원칙(Don't Repeat Youtself) 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을 만한 표현 양식을 가져야한다. 상속 객체지향에서 중복코드를 제거하는 첫번째 방법! 하지만 상속을 통한 중복코드 제거는 부모클래스와 자식클래스의 결합도를 높인다는 단점이 있다. [취약한 기반 클래스 문제] 취약한 기반 클래스 문제 : ..

오브젝트 조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. 책의 내용이 반복되는 느낌이 있지만, 이름이 가진 설계 원칙을 통해 기법들을 정리하는 것은 장황하게 설명된 내용들을 정리하고, 설계를 논의할 때 사용할 수 있는 공통 어휘를 정의한다는 점에서 의의가 있다. [개방 폐쇄 원칙(Open-Close Principle, OCP)] 객체는 확장에 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다! 확장에 대해서 열려 있다 : 애플리케이션 변경사항이 생겼을 때, 변경에 맞게 새로운 동작을 추가할 수 있다. 수정에 대해 닫혀 있다 : 기존 코드를 수정하지 않고도 애플리케이션 동작을 추가 변경이 가능하다. 추상화가 핵심이다 개방 폐쇄 원칙의 핵심은 추상화에 의존하는 것이..

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. [의존성 이해하기] 변경과 의존성 실행 시점 : 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 한다. 구현 시점 : 의존 대상 객체가 변경된 경우 의존하는 객체도 함께 변경된다. 의존성은 방향성을 가지며 그 방향성은 항상 단방향이다. 객체가 의존하고 있는 객체가 의존하는 객체는 모두 의존관계이다.(의존성 전이) 직접 의존성 : 코드 안에서 명시적으로 드러나는 경우 간접 의존성 : 코드 안에서 명시적으로 드러나지 않는 경우 런타임 의존성과 컴파일타임 의존성 객체지향 어플리케이션에서 런타임에 주인공은 객체이다. 컴파일 타임에 주인공은 클래스이다. 중요한 것은 런타임 의존성과 컴파..

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. [프로시저 추상화와 기능 분해] 객체지향 이전의 추상화 기법기법이다. 프로시저 추상화 : 반복적으로 실행되거나 거의 유사하게 실행되는 작업들을 하나의 장소에 모아놓음으로써 로직을 재사용하고, 중복을 방지하는 추상화 기법 -> 프로시저를 추상화라 부르는 이유는, 구현을 모르더라도 인터페이스만 알면 사용할 수 있기 때문이다. ->전통적인 기능분해의 방법이 하향식 설계 방법이다. [하향식 설계(Tree 형식)] 하향식 설계 : 하나의 함수를 더 작은 함수로 분해하고, 분해된 함수들의 실행순서를 결정하는 방법. 하향식 설계의 문제점 하나의 함수에 제어가 집중되기 때문에 확장이 어렵다. 과도하게 함수에 집중하게 함으로써, 소프..

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. 객체지향에서 애플리케이션의 가장 중요한 재료는 클래스가 아닌, 객체들이 주고받는 메시지이다! 객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스를 구성한다. [협력과 메시지] 클라이언트 서버 모델 두 객체 사시의 협력 관계를 설명하기 위해 사용하는 전통적인 모델 협력은 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이다. 객체가 독립적으로 수행할 수 있는 것보다 더 큰 책임을 수행하기 위해서 다른 객체와 협력해야 한다! [메시지와 메시지 전송] 메시지 전송 or 메시지 패싱 : 한 객체가 다른 객체에게 도움을 요청하는 것. 메시지 전송자(클라이언트) : 메시지를 전송하는 객체 메시지 수신자(서버) : 메시지를 수..

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. 책임 주도 설계 데이터보다 행동(외부에서 제공하는 행동)을 먼저 결정하라 협력이라는 문맥 안에서 책임을 결정하라 - 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다. - 협력에 적합한 책임을 수확하기 위해서, 메시지를 결정한 후에 객체를 선택해야 한다. (메시지가 클라이언트의 의도를 표현한다) 책임 할당을 위한 패턴(GRASP?) 도메인 개념에서 출발하기 - 설계를 시작하기 전에 도메인에 대한 대략적인 모습을 그려 보는 것이 유용하다. - 도메인 개념들을 책임 할당의 대상으로 사용하면 코드에 도메인의 모습을 투영하기가 쉬워진다. 정보 전문가에게 책임을 할당하라 질문1 : 메시지를 전송할 객체는 무엇을..