Unity 에서 자주 사용 하 는 몇 가지 디자인 모델

23 가지 디자인 모델 이 너무 많 습 니 다. 그리고 그 중 일 부 는 보기 에는 차이 가 많 지 않 은 것 같 아서 이해 하기 어렵 습 니 다. 모든 디자인 모델 의 의 미 를 어렵 게 이 해 했 습 니 다. 그리고 위조 코드 를 한 무더기 본 후에 고 기 쁘 게 책 을 덮 고 LOL 을 몇 판 했 습 니 다. 몇 판 을 이 긴 후에 머 릿 속 에 그 23 가지 디자인 모델 에 대한 개념 이 80% 밖 에 남지 않 았 습 니 다.그리고 앞으로 매일 일 할 때 코드 를 거의 쓸 때 도 사용 할 수 없 잖 아!사장 님 께 서 기능 을 하 라 고 재촉 하 시 는데 디자인 모델 을 사용 하 는 것 을 어디서 기억 하 세 요? 낙서 를 시작 하 세 요. 하루 가 다 르 게 23 가지 디자인 모델 은 기본적으로 당신 과 안녕 히 계 세 요. 안녕 히 계 세 요.
사실은 게임 개발 에서 우리 가 유 니 티 에서 볼 수 있 는 것 은 우리 가 자주 사용 하 는 것 과 바로 몇 가지 입 니 다. 다른 소프트웨어 디자인 에서 도 마찬가지 로 이런 몇 가 지 를 자주 사용 합 니 다. '비망록' 모델, '책임 체인' 모델 등 은 대체적으로 사용 하지 않 습 니 다. 다음은 우리 가 자주 사용 하 는 이 몇 가 지 를 말씀 드 리 겠 습 니 다. '단일 모델',"관찰자 모드", "교체 기 모드", "방문 자 모드".
1. 단일 모드
개념 은 간단 합 니 다. 하나의 인 스 턴 스 만 있 고 전체 방문 점 을 제공 합 니 다. 저 는 두 개의 코드 를 제공 하면 좋 겠 습 니 다. 게임 에서 두 가지 종류 가 있 습 니 다. 하 나 는 MonoBehavior 를 계승 하지 않 고 다른 하 나 는 계승 하 는 것 입 니 다. 먼저 계승 하지 않 는 것 을 보 겠 습 니 다.
Class Singleton {       Static MySingleton;                           // 단일 대상, 전역 유일.
     Static Instance()
{
if(MySingleton == null)
             MySingleton = new MySingleton();
return MySingleton;
}       // 대외 노출 인터페이스
}
다음은 모 노 Behavior 로부터 물 려 받 은 클래스,
Class Singleton：MonoBehavior {       Static MySingleton;                          
     Static Instance()
{
return MySingleton;
}    
void Awake()
{
MySingleton = this;
}
}
그냥 게임 개발 에서 이렇게 쓰 면 돼.
2. 관찰자 모드
개념: 대상 과 대상 간 에 의존 관 계 를 만 듭 니 다. 그 중 한 대상 이 변화 할 때 이 변 화 를 관 계 를 만 드 는 대상 에 게 알 리 고 자동 화 된 알림 업 데 이 트 를 실현 합 니 다.
게임 개발 에서 예 를 들 어 UI 에 드 롭 다운 List 가 있 는데 저 는 그 중의 모든 항목 을 선택 하면 UI 인터페이스의 변 화 를 초래 할 수 있 습 니 다. 예 를 들 어 저 는 '강화' 를 선택 하면 강화 장비 가 나타 나 는 인터페이스 에 대응 하고 저 는 '상감' 을 선택 하면 상감 인터페이스 가 나타 납 니 다.
의사 코드 는 다음 과 같 습 니 다:
Class Subject {       // 이 대상 에 게 관찰자 Attach (Observer) 를 연결 합 니 다.      // 한 관찰자 의 귀속 해제  DeleteAttach( Observer );       // 본 목표 가 바 뀌 었 습 니 다. 모든 관찰자 에 게 알 리 지만 변경 한 것 은 전달 되 지 않 았 습 니 다.      Notity()       {              For (... 전체 Observer List 를 옮 겨 다 니 며...)             { pObserver ->Update(); }       }       // 관찰자 가 노출 된 인터페이스 에 대해 관찰자 로 하여 금 본 류 에 어떤 변동 이 있 는 지 얻 게 한다.      GetState ();} / / 관찰자 / 감청 자 클래스 Class Observer {      // 대상 목표 클래스 에 노출 된 함수, 감청 대상 에 변동 이 발생 하면 이 함수 로 관찰자 에 게 알 립 니 다.      Void Update ()       {             pSubject ->GetState();  
/ 감청 대상 획득 에 어떤 변화 가 생 겼 는 지            TODO：DisposeFun();  
/ / 상태 에 따라 다 르 게 처리      } }
이거 잘 이해 되 죠?
3.  교체 기 모드
우 리 는 C \ # 의 교체 기 를 예 로 들 어 직접 설명 하면 된다. 교체 기 모델 의 개념 도 알 수 있 고 C \ # 중 교체 기 가 어떻게 실현 되 는 지 알 수 있다.
교체 기 모드 는 디자인 모드 에서 행동 모드 (behavioral pattern) 입 니 다.예 를 들 어 그 는 대상 간 통신 을 간소화 하 는 모델 이자 쉽게 이해 하고 사용 할 수 있 는 모델 이다. 쉽게 말 하면 교체 기 모델 은 배열 의 모든 요 소 를 얻 을 수 있 고 그 유형 이 array, list, linked list 또는 다른 어떤 서열 구조 인지 에 관심 을 가지 지 않 아 도 된다. 이 점 은 데이터 처리 채널 을 효율적으로 구축 할 수 있다.(data pipeline) - 즉, 데이터 가 처리 채널 에 들 어가 일련의 변환 을 하거나 여과 한 후에 결 과 를 얻 을 수 있 습 니 다. 사실은 이것 이 바로 LINQ 의 핵심 모델 입 니 다.
    . NET 에 서 는 교체 기 모드 가 IEnumerator 와 IEnumerable 및 그 에 대응 하 는 범용 인터페이스 에 의 해 봉 인 됩 니 다. 만약 하나의 클래스 가 IEnumerable 인 터 페 이 스 를 실현 한다 면 교체 할 수 있 습 니 다. GetEnumerator 방법 을 호출 하면 IEnumerator 인터페이스 의 실현 으로 되 돌아 갑 니 다. 교체 기 는 데이터베이스 에 있 는 커서 와 유사 합 니 다. 그 는 데이터 시퀀스 의 위치 기록 입 니 다.앞으로 만 이동 할 수 있 고 같은 데이터 시퀀스 에서 여러 개의 교체 기 가 동시에 데 이 터 를 조작 할 수 있 습 니 다.
    C \ # 1 에 교체 기 지원 이 내장 되 어 있 습 니 다. 바로 foreach 문 입 니 다. for 순환 문 구 를 보다 직접적 이 고 간단하게 집합 을 교체 할 수 있 도록 컴 파일 러 는 foreach 를 GetEnumerator 와 MoveNext 방법 및 Current 속성 으로 컴 파일 합 니 다. 대상 이 IDisposable 인 터 페 이 스 를 구현 하면 교체 가 완 료 된 후에 교체 기 를 방출 합 니 다. 그러나 C \ # 1 에 서 는 구현 합 니 다.하나의 교체 기 는 상대 적 으로 좀 번 거 로 운 조작 이다. C \ # 2 는 이 작업 을 크게 간단 하 게 만 들 었 고 교체 기 를 실현 하 는 많은 작업 을 절약 했다.

public System.Collections.IEnumerator GetEnumerator()
{    for (int i = 0; i < 10; i++)
    {        yield return i;
    }
}

static void Main()
{
    ListClass listClass1 = new ListClass();    foreach (int i in listClass1)
    {
        System.Console.Write(i + " ");
    }    // Output: 0 1 2 3 4 5 6 7 8 9}

}
4. 방문 자 모드
우리 가 구조 대상 에 기능 을 추가 하고 싶 을 때 우 리 는 구조 에 영향 을 주지 않 는 전제 에서 새로운 요소 에 대한 조작 을 정의 할 수 있다.
예 를 들 어 장면 관리자 에서 관리 하 는 장면 노드 는 매우 다양 하고 종류 가 다르다. 예 를 들 어 Ogre 중의 Root 가 있 고 Irrchit 에서 카메라, 조명, Mesh, 게시판, 소 리 를 모두 장면 노드 로 한다. 각 노드 의 유형 은 다르다. 모두 가 공 통 된 Paint (), Hide () 가 있 지만등 방법, 그러나 방법의 실현 형식 은 다르다. 우리 가 외부 에서 호출 할 때 인 터 페 이 스 를 통일 해 야 한다 면 우 리 는 이런 코드 가 필요 할 것 이다.
       Hide( Object )
       { 
if (Object == Mesh) HideMesh(); 
if (Object == Light) HideLight();  
… 
}
이때 만약 우리 가 Object 의 새로운 유형 대상 을 추가 해 야 한다 면, 우 리 는 이 함 수 를 수정 해 야 합 니 다. 그리고 우 리 는 이렇게 할 수 있 습 니 다. Mesh, Light 를 모두 Object 에 계승 할 수 있 습 니 다. 그들 은 모두 함수 Hide () 를 실현 하면 됩 니 다.
       Mesh::Hide( Visitor ) { Visitor.Hide (Mesh); }
       Light::Hide(Visitor ){ Visitor.Hide (Light); }
즉, Mesh 의 숨 김 은 3 단계 와 관련 될 수 있 고 Light 의 숨 김 은 10 단계 와 관련 될 수 있 습 니 다. 그러면 모든 자신의 Visitor 에서 모든 요소 의 숨 김 기능 을 실현 할 수 있 습 니 다. 그러면 요소 류 자체 와 쓸모없는 코드 를 Visitor 로 옮 길 수 있 습 니 다.
각 요소 류 는 하나 또는 여러 개의 Visitor 류 에 대응 할 수 있 습 니 다. 예 를 들 어 우 리 는 은행 카운터 에 가서 업 무 를 처리 합 니 다. 일반적인 상황 에서 몇 개의 개인 업무 카 운 터 를 열 것 입 니 다. 당신 은 그 중의 어느 카운터 에 가서 처리 해도 됩 니 다. 우리 의 방문 자 모델 은 이 장면 에 잘 옮 길 수 있 습 니 다. 은행 카운터 에 있어 서 그들 은 변화 할 필요 가 없습니다. 즉, 오늘 과 내일 제시 하 는 것 입 니 다.개인 업 무 를 제공 하 는 카 운 터 는 변화 가 필요 하지 않 습 니 다. 우 리 는 방문 자로 서 오늘 은행 에 오 면 소비 흐름 을 찾 을 수 있 습 니 다. 내일 은행 에 오 면 핸드폰 은행 업 무 를 처리 하 러 갈 수도 있 습 니 다. 이런 것들 은 우리 방문 자의 조작 으로 계속 변화 하고 있 습 니 다.
의사 코드 는 다음 과 같 습 니 다:
 //  방문 자 기본 클래스 Class Visitor {      Virtual VisitElement( A ){ … };            
/ / 방문 하 는 모든 대상 에 게 이런 방법 을 써 야 합 니 다.      Virtual VisitElement (B) {...};} / / 방문 자 인 스 턴 스 A Class VisitorA {      VisitElement( A ){ … };       
 // 실제 처리 함수      VisitElement( B ){ … };       
 // 실제 처리 함수} / / 방문 자 인 스 턴 스 B Class Visitorb {      VisitElement( A ){ … };        
/ / 실제 처리 함수      VisitElement( B ){ … };        
/ / 실제 처리 함수} / / 피 방문 자 기본 클래스 Class Element {      Virtual Accept( Visitor );     
/ / 방문 자} / / 방문 자 인 스 턴 스 A Class Element A {      Accecpt( Visitor v ){ v-> VisitElement(this); };    
/ / 방문 자 에 등 록 된 처리 함수 호출} / 방문 자 인 스 턴 스 B Class Element B {      Accecpt( Visitor v ){ v-> VisitElement(this); };   
 // 방문 자 에 등 록 된 처리 함수 호출}