Post

KDT Unity 2주차~4주차 - 게임에 자주 쓰는 디자인 패턴 7가지

2023-11-30 TIL

알고리즘 문제

오늘의 알고리즘 문제 : 약수의 개수와 덧셈

두 정수 left와 right가 매개변수로 주어집니다. left부터 right까지의 모든 수들 중에서, 약수의 개수가 짝수인 수는 더하고, 약수의 개수가 홀수인 수는 뺀 수를 return 하도록 solution 함수를 완성해주세요.

1
2
3
4
5
6
7
8
using System;

public class Solution {
    public int solution(int left, int right) {
        int answer = 0;
        return answer;
    }
}

Desktop View

해결

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
using System;

public class Solution {
    public int solution(int left, int right)
    {
        int answer = 0;
        for(int i = left; i <= right; i++)
        {
            int plus = Measure(i);
            if (plus % 2 ==0) answer+=i;
            else answer -= i;
        }
        return answer;
    }
    int Measure(int number)
    {
        int check = 0;
        for(int i = 1; i <= number; i++)
        {
            if(number % i ==0) check++;
        }
        return check;
    }
}

이번 알고리즘은 메서드를 2개로 나눠서 풀었습니다. public int solution(int left, int right)메서드에서는 들어온 값을 for문을 이용하여 answer에 더하거나 빼는 역할을 합니다.

solution메서드에서 진행되는 for문 안에int Measure(int number)메서드는 작은수인 left부터 약수가 총 몇개인지를 세어 약수의 개수를 리턴해주는 함수입니다.

Desktop View

7가지의 디자인 패턴

오늘은 게임 자주 사용된다는 7가지의 디자인 패턴에 대해 소개해볼려고 합니다.

Singleton - 싱글톤

싱글톤 패턴이란 객체의 인스턴스가 오직 1개만 생성되는 패턴을 의미합니다.

해당 객체의 생성자가 여러차례 호출이 되더라도 실제로는 처음 생성된 객체가 리턴됩니다.
그로 인해 다른 클래스간의 데이터 공유가 매우 쉬워진다는 이점이 생깁니다.

하지만 여러 객체에서 싱글톤의 객체에 동시접근을 한다면 문제가 생길수도 있다는 문제점이 있습니다.

보통 유니티에서는 GameManager와 같은 매니저객체를 예로 들수 있습니다.

State - 상태

상태 패턴은 해당 패턴의 인터페이스의 파생클래스로 각각의 상태를 구현합니다.

쉽게 말하면 조건문으로 검사하여 상태를 업데이트하는 것이 아닌 상태를 객체화하여 상태에 따라 행동을 하게하는 방식입니다.

장점으로는 행동을 객체화하여 분리하여 행동이 다른 행동에 영향을 주지 않습니다. 그래서 행동을 추가하는데 비교적 쉽습니다.

상태가 많지 않은 경우 해당 패턴을 적용하는 것은 과할수 있습니다.

또한 상태에 따른 클래스를 많이 생성하므로 관리할 클래스가 많아집니다.

Observer - 관찰자

옵저버 패턴은 여러 객체가 자신이 관찰 중인 객체에서 발생하는 모든 이벤트에 대하여 알림받는 형식입니다.

일(주 객체) 대 다(관찰자 객체)의 관계로 구성되어 있습니다. 주 객체에서 상태 변경시 모든 관찰자 객체로 해당 내용을 전달해줍니다.

해당 관찰자 객체들은 상태에 따른 기능을 수행합니다.

주 객체와 관찰자 객체의 관계가 느슨하게 유지됩니다. 그로 인해 새 구독자 클래스의 도입이 매우 간편합니다

하지만 알림순서를 제어할수 없습니다

상태값이 변경될 때 해당 변경값이 필요없는 관찰자도 해당 변경내용을 전달 받습니다.

Command - 커멘드

커맨드 패턴은 요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 매서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴입니다.

커맨드 패턴에는 명령(command), 수신자(receiver), 발동자(invoker), 클라이언트(client)의 네개의 용어가 항상 따릅니다.

커맨드 객체는 수신자 객체를 가지고 있으며, 수신자의 메서드를 호출하고, 이에 수신자는 자신에게 정의된 메서드를 수행합니다. 커맨드 객체는 별도로 발동자 객체에 전달되어 명령을 발동하게 합니다.

Component - 컴포넌트

컴포넌트란 독립적인 객체로 만들어둔 부품을 붙이듯 가져다 사용하는 방식입니다.

상속과 다르게 각자 기능을 가지고 독립적입니다.

코드의 의존성을 줄이고 재활용성을 높힙니다.

서로의 커플링 없이 다룰수 있게 해줍니다.

Builder - 빌더

빌더 패턴은 복잡한 객체의 생성 과정과 표현방법을 분리하여 다양한 구성 인스턴스를 만드는 방식입니다.

생성자에 들어갈 매개변수를 메서드로 하나하나 받고 통합하여 빌드하는 방식입니다.

그로 인해 생성과정을 일관되게 할수 있습니다.

또한 필수와 선택 멤버를 분리할 수 있습니다.

Flyweight - 플라이웨이트

플라이웨이트는 각 객체에 모든 데이터를 유지하는 대신 여러 객체들 간에 상태의 공통 부분들을 공유하여 사용할 수 있는 RAM에 더 많은 객체들을 포함할 수 있도록 하는 구조 디자인 패턴입니다.

그로 인해 프로그램에 유사한 객체들이 많으면 RAM을 절약할 수 있습니다.

오늘의 정리

아직까지는 잘 모르겠는 부분이 많다.

이것도 솔리드 원칙과 같이 나중에 하나씩 다시 정리해볼 예정이다.

Desktop View

This post is licensed under CC BY 4.0 by the author.