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

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

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

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

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

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

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. 객체지향의 설계의 핵심은 역할, 책임, 협력이고 그 품질을 결정하는 가장 중요한 요소는 책임이다! 객체의 결합도와 응집도를 합리적인 수준으로 유지할 수 있는 중요한 원칙은 객체의 상태가 아닌, 객체의 행동에 초점을 맞추는 것이다. -> 상태의 초점을 맞추게 되면, 객체의 내부구현을 인터페이스에 노출시키는 결과를 낳게되어 유지 보수에 어려움을 겪는다. [캡슐화](객체지향에서 복잡성을 다루는 추상화의 방법!) 상태와 행동을 하나의 객체 안으로 모으는 형태로, 객체의 내부 구현을 외부에 숨기기 위함이다. 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개한다. 객체 내의 상태값..

조영호님의 책 오브젝트를 보며 정리한 내용입니다. 문제가 될 시 해당글 삭제하겠습니다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 협력 : 객체들이 애플리케이션 기능을 구현하기 위해 수행하는, 상호작용 책임 : 객체가 협력에 참여하기 위해서 수행하는 행동, 로직? 역할 : 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할이 된다. - 객체는 고립된 존재가 아닌, 시스템의 기능이라는 더 큰 목표를 향해 다른객체와 협력하는 사회적인 존재. - 협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법. -> 메시지 전송(객체가 다른 객체에게 도움을 요청) -> 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다.(객체가 자신의 일을 스스로 처리할 수 있는 자율적인 존..