책/Object (15) 썸네일형 리스트형 디자인 패턴과 프레임워크 디자인 패턴 - 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법 - 특정한 변경을 일관성 있게 다룰 수 있는 협력 템플릿을 제공프레임워크 - 설계와 코드를 함께 재사용하기 위한 것 - 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공 디자인 패턴과 설계 재사용소프트웨어 패턴 - 반복적으로 발생하는 문제와 해법의 쌍으로 정의 - 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사 소통 할 수 있음 - 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 도움 - 패턴은 실무에서 탄생함 - 하나의 실무 컨텍스트에서 유용한 동시에 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아.. 일관성 있는 협력 객체는 협력을 위해 존재협력은 객체가 존재하는 이유와 문맥을 제공잘 설계된 애플리케이션은 이해하기 쉽고, 수정이 용이하며, 재사용 가능한 협력의 모임객체지향 설계의 목표는 적절한 책임을 수행하는 객체들의 협력을 기반으로 결합도가 낮고 재사용 가능한 코드 구조를 창조하는 것객체지향 패러다임의 장점은 설계를 재사용할 수 있다는 것 설계에 일관성 부여하기변하는 개념을 변하지 않는 개념으로부터 분리하라변하는 개념을 캡슐화하라캡슐화란 변하는 어떤 것이든 감추는 것캡슐화의 종류 - 데이터 캡슐화 : 속성에 접근할 수 있는 방법은 메서드를 이용하는 것. 클래스는 내부에 관리하는 데이터를 캡슐화 - 메서드 캡슐화 : 클래스 외부에 영향을 미치지 않고 메서드를 수정. 클래스의 내부 행동을 캡슐화 - 객체 캡슐화 : 객체.. 서브클래싱과 서브타이핑 상속의 두가지 용도타입 계층을 구현 - 부모 클래스는 일반적인 개념을 구현하고 자식 클래스는 특수한 개념을 구현 - 부모 클래스는 자식 클래스의 일반화(generalization), 자식 클래스는 부모 클래스의 특수화(specialization)코드 재사용 - 간단한 선언만으로 부모 클래스의 코드를 재사용함 - 점진적으로 애플리케이션의 기능을 확장할 수 있음 - 부모 클래스와 자식 클래스가 강하게 결합되기 때문에 변경하기 어려운 코드를 얻게 될 확률이 높음상속을 사용하는 일차적인 목표는 코드 재사용이 아니라 타입 계층을 구현하는 것타입 사이의 관계를 고려하지 않은 채 단순히 코드를 재사용하기 위해 상속을 사용해서는 안 된다 타입개념 관점의 타입 - 우리가 인지하는 세상의 사물의 종류 - 우리가 인식하는 .. 다형성 다형성(Polymorphism)하나의 추상 인터페이스에 대해 코드를 작성하고 이 추상 인터페이스에 대해 서로 다른 구현을 연결할 수 있는 능력여러 타입을 대상으로 동작할 수 있는 코드를 작성할 수 있는 방법 유니버셜(Universal) 다형성 매개변수(Parametric) 다형성 클래스의 인스턴스 변수나 메서드의 매개변수 타입을 임의의 타입으로 선언한 후 사용하는 시점에 구체적인 타입으로 지정하는 방식 제네릭 프로그래밍과 관련이 높음 포함(Include) 다형성 메시지가 동일하더라도 수신한 객체의 타입에 따라 실제로 수행되는 행동이 달라지는 방식 객체지향 프로그래밍에서 가장 널리 알려진 형태의 다형성 상속을 사용 : 어떤 메시지, 어떤 클래스의 인스턴스인지에 따라 처리할 적절한 메서드를 상속 계층 안에서.. 합성과 유연한 설계 상속(is-a 관계)부모 클래스와 자식 클래스 사이의 의존성은 컴파일타임에 결정부모 클래스의 코드를 재사용클래스 사이의 높은 결합도 합성(has-a 관계)두 객체 사이의 의존성은 런타임에 결정 객체의 퍼블릭 인터페이스에 의존객체 사이의 낮은 결합도 상속을 남용했을 때 직면할 수 있는 세가지 문제불필요한 인터페이스 상속 문제 : 자식 클래스에게 부적합한 부모 클래스의 오퍼레이션이 상속되므로 자식 클래스의 인스턴스의 상태가 불안정해짐메서드 오버라이딩의 오작용 문제 : 자식 클래스가 부모 클래스의 메서드를 오버라이딩할 때 자식 클래스가 부모 클래스의 메서드 호출 방법에 영향을 받음부모 클래스와 자식 클래스의 동시 수정 문제 : 부모 클래스와 자식 클래스 사이의 개념적인 결합으로 인해 부모 클래스를 변경할 때 .. 상속과 코드 재사용 DRY 원칙모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을 만한 표현 양식을 가져야 한다중복 여부를 판단하는 기준은 변경 - 요구사항이 변경 됐을 때 두 코드를 함께 수정해야 한다면 중복이다 상속을 이용해서 중복 코드 제거하기이미 존재하는 클래스와 유사한 클래스가 필요하다면 코드를 복사하지 말고 상속을 이용해 코드를 재사용해라상속을 염두에 두고 설계되지 않은 클래스를 상속을 이용해 재사용하는 것은 생각처럼 쉽지 않다부모 클래스와 자식 클래스 사이의 결합도를 높인다 취약한 기반 클래스 문제부모 클래스의 변경에 의해 자식 클래스가 영향을 받는 현상자식 클래스를 점진적으로 추가해서 기능을 확장하는 데는 용이하지만 높은 결합도로 인해 부모 클래스를 점진적으로 개선하는 것은 어렵게 만든다자식 클.. 유연한 설계 개방 폐쇄 원칙(OCP)확장에 대해 열려 있고, 변경에 대해서는 닫혀 있어야 한다. - 확장에 대해 열려 있다 : 요구사항이 변경될 때 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다 - 변경에 대해 닫혀 있다 : 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다 컴파일 타임 의존성을 고정시키고 런타임 의존성을 변경하라컴파일 타임 의존성 : 코드에서 드러나는 클래스들 사이의 관계런타임 의존성 : 실행시에 협력에 참여하는 객체들 사이의 관계개방 폐쇄 원칙을 따르는 설계를 하자 추상화가 핵심이다개방 폐쇄 원칙의 핵심은 추상화에 의존하는 것추상화 - 핵심적인 부분만 남기고 불필요한 부분은 생략함으로써 복잡성을 극복하는 기법 - 문맥이 바뀌더라도 변하지 않는 부분.. 의존성 관리하기 변경과 의존성실행 시점 : 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 한다.구현 시점 : 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경된다. 의존성 전이(transitive dependency)직접 의존성(direct dependency) : 한 요소가 다른 요소에 직접 의존하는 경우간접 의존성(indirect dependency) : 직접적인 관계는 존재하지 않지만 의존성 전이에 의해 영향이 전파되는 경우 런타임 의존성과 컴파일 타임 의존성런타임 의존성(run-time dependency) : 애플리케이션이 실행되는 시점의 의존성 - 객체 사이의 의존성컴파일타임 의존성(compile-time dependency) : 작성된 코드를 컴파일하는 시점.. 이전 1 2 다음