독서 노트 의 1: 디자인 모델 입문 (전략 모델)

오리 시 뮬 레이 션 게임 을 예 로 들 어 우리 의 디자인 모델 학습 여행 을 시작 합 니 다.
 
우선, 우 리 는 각종 오리 의 부 류 를 설계 해 야 한다. 오리 의 공 통 된 특징 과 행 위 를 포함한다.
Duck
quack()
swim()
display()
....    //오리 의 기타 행동 특징
 
그 후에 PM (제품 매니저) 은 오리 가 비행 하 는 행 위 를 해 야 하기 때문에 우 리 는 자 연 스 럽 게 아버지 류 Duck 을 fly () 방법 에 넣 었 고 자 류 는 아버지 류 를 계승 함으로써 모두 비행 행 위 를 했다 고 생각 했다.
 
문제 가 생 겼 군..
PM 은 게임 속 장난감 고무 오리 도 날 아 오 르 는 것 을 발견 했다.   이 건 정말 천둥 이 야.
 
그래서 불쌍 한 우 리 는 다시 설계 해 야 한다.우 리 는 아버지 류 에서 fly () 방법 은 어떠한 실현 도 하지 않 고 자 류 에서 각자 자신의 fly 행 위 를 실현 하 는 것 을 생각 했다. 예 를 들 어 고무 오리 의 fly () 는 아무것도 하지 않 는 다.
하지만 곰 곰 이 생각해 보면 앞으로 오리 의 종류 가 계속 증가 할 것 이다. 우 리 는 fly 방법 을 계속 실현 하고 덮어 야 한다. 이것 은 정말 슬프다.
 
어 떡 하지?
 
우 리 는 이러한 fly 특수 행 위 를 Duck 류 에서 분리 하여 새로운 종 류 를 만들어 구체 적 인 행 위 를 실현 해 야 한 다 는 깨 우 침 을 받 았 다.이 그룹의 새로운 종 류 는 fly 행위 유형의 인터페이스 로 이 루어 진다.
OK, 우 리 는 비행 행위 의 인 터 페 이 스 를 설계 했다.
FlyBehavior
우 리 는 이 인터페이스 에 대해 서로 다른 비행 류 를 실현 할 수 있다. 예 를 들 어 Fly With Wings (진실 한 날개 비행).  플라이 노 웨 이 (날 지 못 한다, 예 를 들 어 고무 오리)
 
이렇게 하면 우리 의 오리 부류 코드 는 다음 과 같다.

public abstract class Duck{
    FlyBehavior  flyBehavior;
   
    public Duck(){
   }
 
    public abstract void display();
   
    public void performFly(){
    
    flyBehavior.fly();

  }

}

FlyBehavior 인터페이스의 실현 코드:

public interface FlyBehavior{
  public void fly();
}

public class FlyWithWings implements FylBehavior{
   public void fly()
   {
      ........
   }
}

public class FlyNoWay implements FlyBehavior  //   
{
    public void fly()
   {
      ......
   }

}

 
현재 의 디자인 은 이미 매우 큰 발전 을 이 루 었 지만 우 리 는 구체 적 인 행위 인 터 페 이 스 를 동적 으로 연결 할 수 있 도록 해 야 한다.그래서 우 리 는 Duck 부류 에 새로운 방법 을 넣 었 다.

public void setFlyBehavior(FlyBehavior fb)
{
    flyBehavior = fb;
}

이렇게 하면 우 리 는 오리 의 구체 적 인 행동 을 동태 적 으로 바 꿀 수 있 습 니 다. 다행 입 니 다 하하
 
상기 실현 과정 에서 우 리 는 여러 가지 유형 을 조합 하여 사용 하면 유연성 이 강하 고 결합 성도 상대 적 으로 약 해 졌 다.
 
 
상기 디자인 을 마치 고 우 리 는 첫 번 째 디자인 모델 인 전략 모델 (Strategy Pattern) 을 배 웠 다.
 
정책 모드 정의:  이 는 알고리즘 족 을 정의 하고 각각 밀봉 하여 그들 사이 에 서로 바 꿀 수 있 도록 합 니 다. 이 모델 알고리즘 의 변 화 는 알고리즘 을 사용 하 는 고객 에 게 독립 되 어 있 습 니 다.
 
 
소프트웨어 개발 에 있어 서 변 함 없 는 진리 가 있다. change
 
설계 원칙:
1. 응용 프로그램 에서 변화 가 필요 할 수 있 는 부분 을 찾 아 독립 시 키 고 변화 가 필요 없 는 코드 와 섞 이지 마 세 요.
2. 인터페이스 프로 그래 밍 을 위 한 것 이지 프로 그래 밍 을 위 한 것 이 아니다.
3. 조합 을 많이 쓰 고 계승 을 적 게 쓴다.