Head First -- 디자인 모델

제1장 의 입문 내용 을 보고 저 는 정말 재 미 있 었 습 니 다. 다음은 책 에 있 는 Duck 류 에 대한 공 부 를 정리 하 겠 습 니 다. 우 리 는 문제 의 제기 부터 시작 하 겠 습 니 다.문 제 는 처음에 다음 과 같 았 다. Duck 류 를 설 계 했 는데 이런 종류 에서 많은 종류의 오리 의 초 류 를 디자인 했다. 그래서 우 리 는 깊이 생각 하지 않 고 다음 코드 를 디자인 했다.
　　

 public class Duck{

 void quack();//    

virtual void display();//       

 void swim();//      

}



public class MallardDuck:Duck{

void override display()

{

//      

}

}

public class ReadheadDuck:Duck{

void override display()

{

//      

}

}

이런 디자인 은 매우 완벽 해 보이 지만 소프트웨어 직원 들 의 유일한 진 리 는 'change' 이다.시간 이 지나 면 우 리 는 오리 에 게 하늘 을 날 수 있 는 기능 을 주어 야 한다. Duck 류 에 void fly () 라 는 함수 만 넣 으 면 되 는 것 처럼 보이 지만 현실 은 우리 가 생각 하 는 것 처럼 나무 오리 도 날 수 있 는 상황 이 나타 나 면 우 리 는 fly 를 virtual 타 입 으로 만 들 고 나무 오리 에 덮어 버 리 면 된다 고 생각한다.그 에 게 어떤 일 도 시 키 지 않 으 면 나무 오리 가 날 지 않 을 것 이 라 고 보장 할 수 있다. 보아하니 이 문 제 는 이미 해 결 된 것 같다. 그러나 이때 많은 코드 가 중복 되 었 다. 우 리 는 모든 특수 한 오리 에 대해 프로 그래 밍 을 해 야 한다. 즉, 재 업로드 가 필요 한 지 아 닌 지 를 보 는 것 이다.우 리 는 많은 행동 을 덮어 야 할 지도 모른다. 이것 은 악몽 이다.
이때 우 리 는 인 터 페 이 스 를 사용 하여 fly 를 Flyable 인터페이스 에 넣 으 면 날 아야 할 오리 가 이 인 터 페 이 스 를 계승 할 수 있 고 필요 하지 않 은 것 은 이 계승 인 터 페 이 스 를 계승 하지 않 아 도 된다 는 생각 이 들 었 다. 매우 완벽 해 보 였 다.그러나 이 로 인해 재 활용 할 수 없 는 코드 가 생 겼 다. 예 를 들 어 백 마리 의 오리 가 날 아 다 니 는 행위 가 같다 면 우 리 는 이 백 가지 오리 에 똑 같은 코드 를 백 번 써 야 한다. 이것 은 또 하나의 악몽 의 시작 이다.
이때 우 리 는 OO 디자인 원칙 중의 하 나 를 생각 했다. "응용 에서 변화 가 필요 할 수 있 는 점 을 찾 아 독립 시 키 고 변화 가 필요 없 는 코드 와 함께 두 지 마라 (OO 디자인 원칙 1)."지금 우 리 는 변화 가 필요 한 fly 행 위 를 나 누 어 오리 와 분리 해 야 한다. 이때 우 리 는 OO 디자인 원칙 중의 '인터페이스 프로 그래 밍 을 위 한 것 이지 프로 그래 밍 을 위 한 것 이 아니다 (OO 디자인 원칙 2)' 라 고 생각 할 것 이다.즉, 우 리 는 FlyBehavior 인 터 페 이 스 를 이용 하여 변화 가 필요 한 fly 를 밀봉 한 다음 에 이 인 터 페 이 스 를 대상 으로 프로 그래 밍 을 할 수 있 으 며, 모든 오 리 를 대상 으로 프로 그래 밍 을 하 는 것 이 아니다.그래서 저희 가 fly 에 대한 디자인 을 완 성 했 습 니 다.

public interface FlyBehavior{



public void fly();



}



public class FlyWithWings:FlyBehavior{



public void fly(){



//     



}



}



public class FlyNoWay:FlyBehavior



{



public void fly(){



//      



}



}

public class Duck

{

FlyBehavior flyBehavior;

void PerformaceFly

{

flyBehavior.fly();

}

}

pulbic class HeadDuck:Duck

{

HeadDuck()

{

flyBehavior=new FlyWithWings();

}

}

public class WoodDuck:Duck{

WoodDuck()

{

flyBehavior=new FlyNoWay();

}

}

이렇게 하면 우 리 는 오리 와 같은 종 류 를 비교적 완전 하 게 설계 할 수 있다.
여기 서 우 리 는 단지 원리 에 대해 전시 할 뿐, 나의 예 는 완전한 코드 형식 으로 나타 날 것 이다.
사실은 위 는 전략 모델 의 사용 이다. 알고리즘 클 러 스 터 를 정의 하고 각각 밀봉 하여 서로 바 꿀 수 있 도록 한다. 이 모델 은 알고리즘 의 변 화 를 알고리즘 을 사용 하 는 고객 에 게 독립 시 켰 다.위의 오리 의 행동 처럼 우 리 는 그것 을 오리 의 알고리즘 으로 이해 할 수 있다. 그러면 이런 행 위 는 알고리즘 클 러 스 터, 모든 것, 즉 우리 가 말 하 는 전략 모델 을 구성 할 수 있다.
그 밖 에 조합 을 많이 사용 하고 계승 을 적 게 사용 하 는 디자인 원칙 도 있다.
Duck.rar