1) 다양한 타입 계층 구현 ● 클래스를 이용한 타입 계층 구현 타입을 구현할 수 있는 방법이 단 한가지 방법만 존재하는 경우 타입과 클래스를 동일하게 취급한다. 만약 Car라는 클래스와 인터페이스는 동일하지만 다른방식으로 구현해야 하는 객체가 필요하다면 즉, 구현은 다르지만 동일한 타입으로 분류되는 객체가 필요하면 상속을 이용하면 된다. 그러나, 자식클래스를 부모 클래스의 구현에 강하게 결합시키기 때문에 구체 클래스를 상속받는 것을 피하고 추상 클래스, 인터페이스를 이용해야한다. 그리고 대부분의 언어에서의 클래스의 다중 상속을 지원하지 않기 때문에 다양한 타입으로 사용이 불가능하다. ● 인터페이스를 이용한 타입계층 구현 위에서 발생하는 다중 상속 지원하지 않는 문제와, 결합도 문제를 피할 수 있는 방법..
1) 협력과 계약 계약에 의한 설계 라이브러리를 사용한다면 Contract.Requires(IsSatisfied(schedule)); 와 같이 제약조건을 명시적으로 표기할 수 있다. 이는 주석과 다르게 시간의 흐름에 따라 같이 움직이며, 실행중에도 체크할 수 있다. 계약은 일반적으로 다음과 같은 특성이 있다. ● 각 계약 당사는 계약으로부터 이익을 기대하고 이익을 얻기 위해 의무를 이행한다. ● 각 계약 당사자의 이익과 의무는 계약서에 문서화 된다. 이 계약 이라는 아이디어를 통해 객체 협력 방식에 적용한 아이디어가 있다. 다음 내용을 살펴보자. 2) 계약에 의한 설계 계약의 의한 설계 개념은 "인터페이스에 대해 프로그래밍하라"는 원칙을 확장한 것이다. 다음 자바코드를 보자 가시성 / 반환 타입 / 메서..
1) 디자인 패턴과 설계 재사용 패턴의 분류 ● 아키텍처 패턴: 미리 정의된 서브 시스템을 제공, 각 서브시스템 책임을 정의, 서브시스템간 조직화하는 규칙과 가이드라인을 포함한다. - 소프트웨어의 전체적인 구조 결정 ● 분석 패턴: 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합 - 도메인 내의 개념적인 문제 해결에 초점 ● 디자인 패턴: 협력하는 컴포넌들 사이에서 반복적으로 발생하는 구조를 서술 - 특정한 설계문제를 해결하는 것을 목적으로 한다. ● 이디엄 패턴: 특정 언어에만 국한된 패턴으로 주어진 언어의 기능을 사용해 컴포넌트, 혹은 컴포넌트 간의 특정 측면을 구현하는 방법을 서술 - 객체가 스스로 자신을 참조하는 객체들의 개수를 카운트해서 더이상 참조되지 않을 경우 스스로를 삭제..
1) 핸드폰 과금 시스템 변경하기 기본정책을 추가하기 위해 BasicRatePolicy를 추상화(슈퍼타입)하고 FixedFeePolicy(고정요금) TimeOfDayDiscountPolicy(시간대별 요금) DayOfWeekDiscountPolicy(요일별 요금) DurationDiscountPolicy(구간별 요금) 을 서브타입으로 구현화 한다. 이 후 통화기간을 일자별로 정리하는 전문가 DateTimeInterval 와 각 구현된 요금정책 Policy 그리고 각 요금규칙 Rule이 요금을 계산해준다. 이때, 생겨나는 Rule을 주의해야한다. 클라이언트가 요구하는 슈퍼타입과 별개로 사전조건이 계속 추가되고 있다. 시간대별, 요일별, 구간별 -> 고정요금을 제외한 사전 조건이 다르다. 결국, 클라이언트는..
1) 타입 개념관점에서 우리가 인식하는 객체들에 적용하는 개념이나, 아이디어를 가리켜 타입이라고 부른다. 어떤 대상이 타입으로 분류 될 때, 그 대상을 타입의 인스턴스라고 한다. 타입은 3가지 구성요소로 설명 할 수 있다. ● 심볼: 타입에 이름을 붙인것 ex) 침대 ● 내연: 타입에 속하는 객체들이 가지는 공통적인 속성이나 행동의 집합 ex) 물체를 지탱함.. ● 외연: 타입에 속하는 객체들의 집합 ex) 접이식 침대, 스프링 침대, 그물 침대 등등 프로그래밍 관점에서 타입은 연속적인 비트에 의미와 제약을 부여하기 위해 사용된다. ● 타입에 수행될 수 있는 유효한 오퍼레이션 집합을 정의 (연산자 종류 제한) ● 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥 제공 (+ 나 new 와 같이 약속된 문..
1) 다형성 다형성은 많은 형태를 가질 수 있는 능력을 의미한다. 프로그래밍에선 여러 타입을 대상으로 동작할 수 있는 코드를 작성할 수 있는 방법으로 얘기할 수 있다. 다형성의 분류 유니버설 매개변수 제네릭 프로그래밍과 관련이 높은데, 인스턴스 변수 혹은 메서드의 매개변수 타입을 임의의 타입으로 선언 후 사용시점에 구체적인 타입으로 지정하는 방식 포함 메시지가 동일하더라도 수신한 객체의 타입에 따라 실제로 수행되는 행동이 달라지는 능력 (서브타입 다형성) 임시 오버로딩 하나의 클래스 안에 동일한 이름의 메서드가 존재하는 경우(시그니처만 다름) 강제 언어가 지원하는 자동적인 타입변환이나 사용자가 직접 구현한 타입 변환을 이용해 동일한 연산자를 다양한 타입에 사용할 수 있는 방식 (단, String + 정수..
1) 상속을 합성으로 변경하기 앞서 상속에서 보아온 문제점들은 다음과 같다. 1. 불필요한 인터페이스 상속 문제 2. 메서드 오버라이딩 오작용 문제 3. 부모 클래스와 자식 클래스의 동시 수정 문제 합성으로 변경하는 방법은 아주 간단하다. 부모 클래스를 자식 클래스의 인스턴수 변수로 변경하면 된다. 만약 부모 클래스의 모든 기능을 자식 클래스에서 구현해야 한다면 자바의 인터페이스를 사용해서 해결 할 수 있다. (단, 부모 클래스 인스턴스 변수를 이용해서 메서드를 호출하는 방식으로 코드를 구현해야한다.) 3번의 경우 합성을 사용하여도 해결되지는 않을 수 있지만 (비즈니스 적인 연관관계) 그래도 합성이 훨씬 좋다. 파급효과를 자식 클래스내로 캡슐화할 수 있기 때문이다. 2) 상속으로 인한 조합의 폭발적인 증..
1) 상속과 중복코드 중복코드는 우리를 주저하게 만들뿐만 아니라 동료들을 의심하게 만든다. 두 코드가 중복인지, 중복을 없애도 괜찮을지 등등 여러가지 사안이 떠오르기 때문이다. DRY 원칙 중복여부를 판단하는 기준은 변경이다. 요구사항이 변경되었을 때 두 코드를 모두 수정해야 한다면 이 코드는 중복이다. 중복코드를 결정하는 기준은 코드의 모양이 아니다. DRY원칙은 Don't Repeat Yourself 간단히 말해 동일한 지식을 중복하지 말라는 것이다. 한번, 단 한번 원칙 혹은 단일 지점 제어 원칙이라고 부른다. 예제로 보여주는 NightlyDiscountPhone, Phone의 상속관계는 새로운 로직을 추가하기 위해 부모, 자식 메서드 모두 수정이 필요했다. 자식 클래스가 부모 클래스에 너무 강하게..