MADE WITH UNITY | 옵저버 패턴 미완

 

 

https://www.youtube.com/watch?v=51sFAT2xZ40&list=PL412Ym60h6uvqYiCVKk5NiEFpDEwOMQFX&index=4

 

 

 

프로그래밍 디자인패턴

대상의 액션에 반응하는 로직을 만드는 Observer 패턴

 

 

옵저버 패턴 대표 예시 : 
버튼 누르면 이벤트 실행
사운드 재생
파티클 재생
애니매이션 재생

 

 

 

+

 

 

 

 

🧠 언제 씀?

체력 HP가 바뀌면 UI 자동 업데이트 

인벤토리 바뀌면 아이콘 자동 새로고침 

퀘스트 상태 변경 → 여러 시스템 자동 반응 

이벤트 중심 구조 만들 때 

✨ 확장 쉬움

→ “HP 바뀌면 이펙트도 나오게 해!”
→ Observer 하나 더 붙이면 끝


    void OnEnable()
    {
        Player.HpChanged += UpdateHpUI;
    }

    void OnDisable()
    {
        Player.HpChanged -= UpdateHpUI;
    }

이런식으로 
OnEnable() , OnDisable() 를 쓴다 함


+

 

 

용어 설명

 

Subject : 버튼이 될 대상

 

Observer : 버튼을 누르면 뒤따라서 플레이 되는 것

 

 

+

 

 

Subject 방송국

Observer 청취자

 

청취자 사이는 모름

방송국은 청취자 모름

 

청취자 가 방송국 을 일방적으로 앎

 

청취자는 계속해서 늘릴 수 있음

 

 

 

Subject  공격 명령 

ㄴ> 모션 실행

ㄴ> 플레이어 대기

ㄴ> 이펙트 실행

ㄴ> 데미지 전달

ㄴ> 적 넉백

 

 

+

 

델리게이트에 함수 덧붙이기
이거도 옵저버 패턴임

 

+

 

 

event Action 도 델리데이트다

 

다른 클래스에서 사용 못한다고 함

 

 

+

 

 

어웨이크 에선 사과 함수 실행 
ㄴ> 사과 함수 에서는 코루틴 실행
ㄴ> 코루틴 에서는 사운드 재생 

 

이렇게 꼬리를 물어 옵저버를 늘릴 수 있다

+

 

짜투리 정보

if (abc != null)
abc 가 있을 경우 라는 뜻


머시기 . code
머시기를 int 넘버로 쓰겠다는 뜻

+

 

 

인스펙터 창의 이벤트 도 델리게이트 비슷한 건데

인스펙터 창에서 사용 가능하다는 게 장점임

 

+

 

단, 옵저버 패턴도 단점도 있다

 

 

점점 꼬리가 추가되니까 복잡해짐

순서를 모름

메모리 누수

무한 뺑뺑이 주의

디버깅 추적 어려움

 

 

옵저버 패턴은 하나의 찰흙처럼 서로 붙어버림

꼬리를 너무 많이 만들다보면

모듈화 캡슐화가 힘들어짐