디자인 패턴

디자인 패턴

• 프로그래머들이 개발을하다가 공통적으로 비슷한 양상을 띄는 개발패턴이 나와서 그것을 이름을 붙여 만든 패턴
• 모든 프로그래밍 분야에 활용 가능한 가이드라인
• 직역 - 설계양식
• 품질유지,가이드라인 ,효율증가,시간감소,확장성증가,유지보수 용이

디자인 패턴의 세 가지 주요 분류

널리 알려진 디자인 패턴들은 주로 **GoF(Gang of Four)**라고 불리는 네 명의 저자가 정리한 23가지 패턴을 기반으로 하며, 목적에 따라 세 가지로 분류됩니다.

1. 생성 패턴 (Creational Patterns) 🛠️

객체의 생성 방식을 다룹니다. 객체를 직접적으로 인스턴스화하는 대신, 객체를 생성하는 작업을 캡슐화하거나 유연하게 만들어 시스템의 다른 부분이 객체 생성 방식에 덜 의존하도록 합니다.

 

2. 구조 패턴 (Structural Patterns) 🧱

클래스나 객체들을 조합하여 더 큰 구조를 만드는 방법을 다룹니다. 서로 다른 인터페이스를 가진 클래스들을 연결하거나, 클래스들의 기능을 확장하는 데 사용됩니다.

 

3. 행위 패턴 (Behavioral Patterns) ⚙️

객체 간의 상호작용과 책임 분배를 다룹니다. 객체들이 서로 통신하고 협력하는 방식을 정의하여 코드의 유연성을 높입니다.

 

 

《주의사항》

• 쉽게 구현가능한 기능에 구지 디자인패턴을 넣지말자
• 협업자가 디자인패턴을 모를 수 있다
• 게임말고도 다른곳에서도 쓰는 패턴이라 그대로적용하면 게임에 안어울릴 수 있어 재구성 해줘야함

---

🛠️게임제작에서 유용한 디자인 패턴들

패턴 이름	분류	핵심 목적	게임 개발 적용 예시
Singleton	생성	인스턴스를 오직 하나만 생성하고 전역 접근을 제공하여 관리자 객체에 사용합니다.	GameManager, AudioManager, InputManager
Factory Method	생성	객체 생성을 캡슐화하여, 생성 로직을 클라이언트 코드로부터 분리하고 유연성을 높입니다.	다양한 몬스터, 무기, 아이템 등의 생성
Builder	생성	복잡한 객체 생성을 단계별로 진행하여, 동일한 과정으로 다양한 설정의 객체를 만듭니다.	복잡한 속성을 가진 캐릭터 또는 맵 생성
Object Pool	생성 (변형)	객체들을 미리 생성하고 재사용하여, **빈번한 생성/파괴로 인한 성능 저하(GC)**를 방지합니다.	총알, 폭발 이펙트, 파티클 시스템
Component	구조	객체의 기능을 **작은 부품(컴포넌트)**으로 분리하고 조립하여 기능을 확장합니다. (합성)	게임 오브젝트에 Movement, Health, Render 컴포넌트 부착
Flyweight	구조	객체들이 공통으로 공유할 수 있는 데이터를 분리하여, 대규모 객체들의 메모리 효율성을 높입니다.	수많은 나무, 풀, 환경 오브젝트 렌더링
Observer	행위	한 객체(주제)의 상태 변화를 다수의 객체(관찰자)에게 자동으로 알리고 갱신합니다.	플레이어 HP/점수 변화 시 UI 업데이트, 이벤트 알림 시스템
State	행위	객체의 내부 상태에 따라 행동을 변경하도록 하여, 복잡한 조건문(Switch/If)을 대체하고 상태 관리를 단순화합니다.	캐릭터나 몬스터의 행동 상태(Idle, Attack, Dead)
Command	행위	요청(명령)을 객체로 캡슐화하여, 요청을 큐에 저장하거나 되돌리기(Undo/Redo) 기능을 쉽게 구현합니다.	사용자 입력 처리, 리플레이 기능, 매크로 구현

 

---

객체지향 SOLID 규칙

• SOLID 원칙은 객체 지향 프로그래밍(OOP) 설계의 5가지 핵심 원칙을 모아놓은 것으로, 소프트웨어의 유연성, 재사용성, 확장성을 높이는 데 중점을 둡니다.
• 디자인패턴을 공부해보면 예전에 배웠던 SOLID 규칙이 더 명확히 이해가 되니 다시보도록 하자

 

원칙	영문 명칭	핵심 요약
S	Single Responsibility Principle (SRP)	단일 책임 원칙: 클래스는 단 하나의 책임만 가져야 하며, 이는 곧 클래스를 변경해야 할 이유가 하나만 있어야 함을 의미합니다. (게임에서는 지키기 어려울 수 있음)
O	Open/Closed Principle (OCP)	개방-폐쇄 원칙: 코드는 확장에 대해서는 열려 있어야 하지만, 수정에 대해서는 닫혀 있어야 합니다. 기능 추가 시 기존 코드를 건드리지 않고 새로운 코드를 추가해야 합니다.
L	Liskov Substitution Principle (LSP)	리스코프 치환 원칙: 자식 클래스는 언제나 자신의 부모 클래스 타입으로 안전하게 교체될 수 있어야 합니다. 다형성을 올바르게 활용하는 핵심입니다.
I	Interface Segregation Principle (ISP)	인터페이스 분리 원칙: 클라이언트는 자신이 사용하지 않는 메서드에 의존해서는 안 됩니다. 하나의 거대한 인터페이스보다 용도에 맞게 작게 분리된 인터페이스를 사용해야 합니다.
D	Dependency Inversion Principle (DIP)	의존 역전 원칙: 고수준 모듈(상위 정책)은 저수준 모듈(세부 구현)에 의존해서는 안 되며, 추상화(인터페이스 또는 추상 클래스)에 의존해야 합니다.