Unity 내일배움캠프 TIL 0925 | 전략 패턴 Strategy Pattern | 컴포넌트 패턴 Component Pattern

cheeseonrose·2023년 9월 25일

CS TIL Unity 내일배움캠프 디자인패턴 스파르타 코딩클럽

Unity 내일배움캠프

목록 보기

45/89

팀 프로젝트 발제날!
주제는 총 4가지로 2D 게임 두 가지와 3D 게임 두 가지..

3D가 하고 싶었지만 팀원 분들의 강의 진도를 고려해서 2D 게임으로 결정했다!

정할게 너무나도 많아서 하루종일 회의 끝에 클래스 설계는 각자 맡은 부분을 해오는 것으로..

디자인패턴 특강

전략 패턴

특정한 작업(알고리즘)을 독립적으로 정의하고 캡슐화하여, 해당 작업을 동적으로 교체할 수 있도록 하는 패턴
캡슐화 -> 달라지는 부분과 달라지지 않는 부분을 찾음

class Duck 
{
	display()
    quack()
    swim()
    fly()
}

class MallardDuck 
{
	display()	// 오리 모양 출력
}

class RedheadDuck 
{
	display()	// 오리 모양 출력
}

class RubberDuck 
{
	display()	// 오리 모양 출력
    
    fly() {
    	// 아무 동작 X
    }
}

러버덕이나 나무로 만든 오리는 울거나 날 수 없음
코드의 재사용성을 위해 상속을 사용하였지만, 서브 클래스에 원치 않은 영향을 끼치게 됨
-> 모든 서브 클래스의 동작을 추정하기 어렵기 때문
quack이나 fly는 오리 종류에 따라 달라지는 부분이므로 Duck 클래스에서 분리해야 함
인터페이스를 사용 (QuackBehavior, FlyBehavior)
-> 특정 행동만을 목적으로 하는 클래스에서 구현하도록
-> quack() 메서드와 fly() 메서드는 Duck 클래스가 아닌 특정 행동 인터페이스를 구현한 별도의 클래스 안에 존재하게 됨

interface IFlyBehavior

class FlyWithWings
{
	fly() {
    	// 난다
    }
}

class FlyNoWay
{
	fly() {
    	// 날개만 푸드덕
    }
}

interface IQuackBehavior

class Quack()
{
	quack() // 꽥꽥
}

class Squeak
{
	quack() // 삑삑
}

class MuteQuack()
{
	//
}

인터페이스의 메서드를 호출하는 식으로 구현

class Duck
{
	IFlyBehavior flyBehavior;
    
    void PerformFly()
    {
    	flyBehavior.Fly();
    }
}

달라지는 부분을 캡슐화하고 동적으로 교체되어 사용할 수 있도록 한다면, 상속으로 발생하는 예상치 못한 영향과 불필요한 코드 작성을 피할 수 있게 됨

void Main()
{
	Duck mallardDuck = new MallardDuck();
    Duck rubberDuck = new RubberDuck();
    
    mallardDuck.Display();
    mallardDuck.PerformFly();
    mallardDuck.PerformQuack();
    
    rubberDuck.Display();
    rubberDuck.PerformFly();
    rubberDuck.PerformQuack();
}

요기부터는 2D 강의 정리를 위해 따로 공부한 내용 ~.~

컴포넌트 패턴

컴포넌트란?

게임에서 오브젝트와 동작에 관한 기본 구성 요소
게임 오브젝트의 동작과 관련한 부품
컴포넌트는 독립적인 소프트웨어 모듈
컴포넌트는 구현, 명세화, 패키지화, 배포 될 수 있어야 함
하나의 컴포넌트는 하나 이상의 클래스로 구성될 수 있음
- 컴포넌트와 클래스 및 객체는 다른 개념
- 컴포넌트가 되기 위해서는 반드시 클래스나 객체로 만들어야만 하는 것은 아님
컴포넌트는 인터페이스를 통해서만 접근 가능
- 컴포넌트 내의 정보는 외부로부터 모두 숨겨짐

컴포넌트 패턴이란?

컴포넌트를 만들어 한 개체가 여러 분야를 서로 커플링 없이 다룰 수 있는 패턴
한 클래스 안에 모든 로직을 넣고 기능이 추가될 때마다 계속 같은 클래스에 포함시키면 결합도가 높아짐
-> 코드 한 줄 수정에도 큰 사이드 이펙트 발생
컴포넌트화 된 객체들이 서로 통신하거나 데이터를 주고 받아야 하는 때가 생길 경우
- 컴포넌트들이 공유하는 정보를 모두 컨테이너 객체에 넣음
  -> 실행 순서게 민감해지거나 컨테이너 객체가 지저분해질 수 있음
- 컴포넌트 자체가 서로 참조하도록 함
  -> 두 컴포넌트가 강하게 결합되는 단점
- 메세지를 전달
  - 한 컴포넌트에서 특정 이벤트나 변경 사항이 발생하면 그것을 상위 컨테이너 객체에 알려줌 -> 컨테이너 객체는 보유하고 있는 모든 컴포넌트 객체에 대해서 해당 메세지를 전달
    -> 보내려는 메세지 정보 형태 자체가 한계적일 수 있음

상속 vs 컴포넌트

	상속 (A is B)	컴포넌트 (A has B)
장점	부모 클래스로부터 물려받은 부분은 다시 쓸 필요가 없기 때문에 재사용 면에서 효율적	코드 의존성이 줄어들고 재활용성이 높아짐
		컴포넌트들끼리 독립적이며 커플링이 없음 -> 유지보수가 편해짐
단점	부모, 조상 클래스가 될 공통된 최소 필수 집합을 개발자가 미리 예상하기 힘듦 완벽한 순수 Base Class를 만들기 힘들다
	컴포넌트들끼리 커플링이 심함