Delver

제작 기간 : 23. 06. 04 ~ 23. 07. 05

개발 인원 : 4인

담당 파트

- 맵툴 및 레벨 제작

주요 구현 내역

- ImGui를 이용한 맵툴 제작

- 이벤트 처리

- 사운드 매니저

- 대화 시스템

- 레벨 제작 및 분리

Cave Story

제작 기간 : 23. 03. 28 ~ 23. 04. 13

개발 인원 : 1인

주요 구현 내역

- 스마트 포인터 활용

- json을 이용한 리소스 관리

- 충돌 처리

- 맵 에디터

SOLID. OOP를 구글링 하면 OOP의 특징과 함께 나오는 항상 나오는 약어이다.

각 원칙들은 서로 다른 내용이라기 보다는 밀접하게 연관되어있다.

또한 설계의 근본적인 목표는 성능보다는 유지보수를 향하고 있어야 한다.

객체 지향 프로그래밍의 5가지 설계 원칙

단일 책임 원칙 (Single Responsibility Principle, SRP)

클래스는 단 한 개의 책임만을 가져야 한다.

책임은 변화에 대한 것이다.

여러개의 책임을 가지게 되면 각 책임마다 변경되는 이유가 발생하기 때문이다. 그래서 한 가지 이유로만 변경되려면 한 가지 책임만을 가져야 한다.

하지만 책임의 기준을 잡는것이 모호하고 어렵기 때문에 변경을 책임의 기준으로 잡으면 조금 더 용이하게 설계할 수 있다.

SRP를 지키지 않으면 연쇄작용이 발생할 가능성이 높아지기 때문에 유지보수가 어려워진다.

개방-폐쇄 원칙 (Open-Closed Principle, OCP)

확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

개방 폐쇄 원칙은 유연함에 대한 것이다.

추상화와 다형성을 이용해서 OCP를 달성할 수 있고 상속을 통해서도 달성할 수 있다. (오버라이딩)

쉽게 얘기하면 기능의 변경이나 확장은 가능해야 하지만 해당 기능을 사용하는 코드는 수정하지 않아야 한다는 것이다.

메소드의 내부 구현이 바뀔수는 있어도 목적은 고정시킴으로써 인터페이스를 변경하지 않고도 그대로 사용이 가능해야 한다.

OCP가 깨진 코드에는 다운 캐스팅, 비슷한 if-else 블록이 존재하는 특징이 있다.

리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

업 캐스팅 되어도 프로그램은 정상적으로 동작해야 한다.

리스코프 치환 원칙은 계약과 확장에 대한 것이다.

다형성을 이용해서 LSP를 달성할 수 있다.

상속 관계처럼 보이지만 실제로는 상속 관계가 아닌 경우 LSP의 위반이 발생한다. 예를 들어 사각형과 정사각형 클래스의 경우가 될 수 있다.

또한 잘못된 오버라이딩으로 상위 클래스에서 지정한 범위의 값을 반환하지 않는 경우에도 위반이 발생한다. 그렇기 때문에 오버라이딩을 하게 되면 반드시 반환값의 의미가 같아야 한다.

LSP를 어기면 OCP도 어길 가능성도 자연스레 높아진다.

int calculateDiscountAmount(Item* item)
{
    if (nullptr != dynamic_cast<SpecialItem*>(item))
        return 0;
        
    return item->getPrice() * discountRate;
}

위 코드처럼 다운 캐스팅으로 타입을 비교하여 예외를 처리하는 경우가 일반적인 LSP 위반 사례이다. 또한 기능을 확장하며 예외를 처리하는 과정에서 변경에는 닫혀 있어야 하는데 코드가 변경되었기 때문에 OCP도 위반된다.

class Item
{
public:
    virtual bool isDiscountAvailable() { return true; }    
};

class SpecialItem : public Item
{
public:
    virtual bool isDiscountAvailable() override { return false; }
};

int calculateDiscountAmount(Item* item)
{
    if (!item->isDiscountAvailable())
        return 0;
        
    return item->getPrice() * discountRate;
}

위와 같이 추후 기능이 확장된다 하더라도 다운캐스팅 및 코드의 변경 없이도 의도한 대로 동작할 수 있어야 LSP 및 OCP를 지킬 수 있다.

인터페이스 분리 원칙 (Interpace Segregation Principle, ISP)

클라이언트는 자신이 사용하는 메서드에만 의존해야 한다.

= 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

인터페이스 분리 원칙은 클라이언트에 대한 것이다.

C/C++같이 컴파일과 링크를 직접 해주는 언어를 사용할 때 장점이 잘 드러난다.

예를 들어 ArticleListUI, ArticleWriteUI, ArticleDeleteUI가 ArticleService 클래스의 헤더를 참조하고 있을 때,  ArticleService 클래스에서 읽기와 관련된 메소드가 변경된다고 하면 재컴파일 후에 목적 파일이 재생성 된다. 여기서 읽기 기능만 변경되었음에도 불구하고 전혀 상관없는 ListUI, WriteUI도 ArticleService 클래스의 헤더 파일을 참조하고 있기 때문에 다시 컴파일되며 목적 파일이 재생성 된다.

이런 경우 ArticleService 클래스를 각 기능으로 나누어서 분리하면 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않는다.

직관적으로 보이듯이 단일 책임 원칙과도 연결된다.

의존 역전 원칙 (Dependency Inversion Principle, DIP)

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.

추상화를 이용해서 DIP를 달성할 수 있다.

고수준 모듈과 저수준 모듈의 예를 들면 아래와 같다.

고수준 모듈은 의미 있는 단일 기능을 제공하는 모듈이라고 정의할 수 있고 저수준 모듈은 고수준 모듈을 구현하기 위해 필요한 하위 기능의 실제 구현으로 정의할 수 있다.

즉, 고수준 모듈은 상위 수준에서 프로그램을 다룬다면 저수준 모듈은 상세가 어떻게 구현될지에 대해서 다루는 것이다.

프로젝트가 어느정도 안정화가 되면 상위 수준보다는 상세 수준에서 변경이 발생할 가능성이 높아진다.

한 가지 예시를 들어보자.

어떤 상품의 가격을 결정하는 정책이 있을 때 상위 수준(고수준 모듈)에서는 아래와 같은 결정이 내려질 수 있다.

상위 수준에서의 쿠폰 정책은 한 번 안정화되면 쉽게 변하지 않지만 쿠폰은 상황에 따라 다양한 종류가 추가될 수 있다. 여기서 쿠폰을 이용한 가격 계산 모듈이 개별적인 쿠폰 구현에 의존하게 되면 새로운 쿠폰 구현이 추가되거나 변경될 때마다 가격 계산 모듈이 변경되는 상황이 발생된다.

저수준 모듈의 변경이 고수준 모듈의 변경을 초래하게 되는 것이다.

특정 클래스에 직접 의존하는 것이 아니라 추상화를 거쳐서 각 클래스들이 추상 타입에 의존하도록 만들면 저수준 모듈이 변경되더라도 고수준 모듈의 변경이 발생하지 않는다.

즉, DIP는 LSP와 OCP를 따르는 설계를 만들어 주는 기반이 된다.

추가로 DIP는 런타임에서의 의존이 아닌 소스 코드의 의존을 역전시킴으로써 변경의 유연함을 확보할 수 있도록 만들어주는 원칙이다.

정리

SOLID 원칙을 한 마디로 정의하자면 변화에 유연하게 대처할 수 있는 설계 원칙이다.

SRP와 ISP는 객체가 커지지 않도록 막아준다.

OCP는 변화되는 부분을 추상화하고 다형성을 이용함으로써 기능 확장을 하면서 동시에 기존 코드를 수정하지 않도록 만들어준다. 여기서 변화되는 부분을 추상화할 수 있도록 도와주는 것이 DIP이고 다형성을 도와주는 것이 LSP이다.

또한 사용자 입장에서의 기능 사용을 중시하기 때문에 사용자 관점에서의 설계를 지향한다.

절차 지향과 객체 지향의 차이

절차 지향 프로그램은 다수의 프로시저들이 데이터를 공유하는 방식으로 만들어지기 때문에 자연스럽게 데이터를 중심으로 구현하게 된다. 그러다보니 프로그램의 규모가 커졌을 때, 프로시저간에 서로 공유되는 데이터의 타입이 변경되거나 데이터를 서로 다른 의미로 사용하고 있다면 코드의 유지 보수가 매우 어려워지기 시작한다.

객체 지향 프로그램은 절차 지향 프로그램과 다르게 데이터 뿐만 아니라 관련된 프로시저를 묶어서 객체라는 단위로 만든다. 객체는 자신만의 데이터와 프로시저를 가지고 자신만의 기능을 제공한다. 각 객체들은 서로 연결되어 다른 객체가 제공하는 기능을 사용할 수 있고 이때 프로시저는 자신이 속한 객체의 데이터에만 접근할 수 있으며 다른 객체에 속한 데이터에는 접근할 수 없다. (캡슐화)

객체 지향 프로그래밍에서 가장 중요한 것은 객체가 어떤 데이터를 가지고 있는지가 아니라 객체가 어떤 메세지를 주고 받는가이다.

객체 지향 프로그래밍의 4가지 특징

캡슐화

객체가 기능을 어떻게 구현하는지를 감추는 것이다.

내부의 기능 구현이 변경되더라도 그 기능을 사용하는 코드는 영향을 받지 않도록 만들어준다. 즉, 내부 구현 변경의 유연함을 주는 기법인 셈이다.

캡슐화는 하고싶다고 해서 자동으로 이뤄지는 것이 아니다.

그래서 캡슐화를 위한 2가지 규칙을 숙지하면 캡슐화된 코드를 작성하는 데 도움이 된다.

if (REGULAR == acc.getMembership()) { ... }

if (acc.hasRegularPermission()) { ... }

acc.getExpData().isAfter(now);

acc.isExpired();

상속

상위 클래스의 기능을 물려받으면서 기능을 변경하거나 추가할 수 있도록 해주는 방법이다. 재사용이 쉽지만 대신 몇 가지 단점이 존재한다.

상속 대신 컴포지션으로 구현하면 단점을 많이 상쇄시킬 수 있다.

또한 상속은 컴파일 타임에만 알고리즘을 변경할 수 있지만 컴포지션은 런타임에 교체가 가능해진다.

그렇다면 상속은 언제 사용하는게 좋을까?

재사용이라는 관점이 아니라 기능의 확장이라는 관점에서 사용하는 것이 좋다. 그리고 명확한 IS-A 관계일 때 적용하는 것이 옳다. 즉, 명확한 IS-A 관계에서 기능을 점진적으로 확장시켜 나가고 싶을 때 사용하면 된다.

다형성

한 객체가 여러 가지 타입을 가지는 것을 의미한다. 다형성을 구현하려면 상속을 이용해야 한다.

크게 구현 상속, 인터페이스 상속으로 나눌 수 있다.

구현 상속은 보통 상위 클래스에 정의된 기능을 재사용하기 위한 목적으로 사용되고 인터페이스 상속은 기능의 구현을 강제하기 위한 목적으로 사용된다.

추상화

데이터나 프로세스 등을 의미가 비슷한 개념이나 표현으로 정의하는 과정이다. 좀 더 쉽게 얘기하면 공통 분모를 찾아서 하나로 묶는 것이다. 그렇기에 상속 및 다형성의 개념이 자연스럽게 포함된다.

뿐만 아니라 많은 책임을 가진 객체로부터 책임을 분리하는 촉매제가 되기도 한다.

요구 사항이 바뀔 때 변화하는 부분을 추상화시키면 향후 유연하게 대처할 수 있는 가능성이 높아진다.

Longest Common Subsequence. 두 수열이 주어졌을 때, 모두의 부분 수열이 되는것 중에 가장 긴 것을 찾는 문제이다.

최장 공통 문자열의 개념에서 조금 확장시키면 어렵지 않게 구할 수 있다.

점화식을 사용하는 DP의 일종이다.

우선 최장 공통 문자열을 구하는 과정이다.

1. 두 문자열을 한글자씩 비교한다.
2. 두 문자가 다르면 LCS[i][j]에 0을 표시한다.
3. 두 문자가 같으면 LCS[i-1][j-1]에 1을 더한다.
4. 위의 과정을 반복한다.

// i, j는 1부터
if (str1[i-1] == str2[j-1])
    LCS[i][j] = LCS[i-1][j-1] + 1;
else
    LCS[i][j] = 0;

점화식을 코드로 작성하면 위와 같다.

이번에는 최장 공통 부분 수열을 구할 차례이다.

위의 과정에서 두 문자가 다를때의 식만 다르다.

if (str1[i-1] == str2[j-1])
    LCS[i][j] = LCS[i-1][j-1] + 1;
else
    LCS[i][j] = max(LCS[i][j-1], LCS[i-1][j]);

두 문자가 다를때의 식이 저렇게 나오는 이유는 부분 수열은 연속된 값이 아니기 때문이다.

LCS[i][j-1], LCS[i-1][j]가 현재 문자를 비교하는 과정의 이전 과정인 것이다.

길이만 구하는 경우라면 LCS[str1.size()][str2.size()]로 구할 수 있고 실제 문자열이 필요한 것이라면 LCS배열의 가장 끝에서부터 0을 만날때까지 역순으로 추적한 뒤에 문자열을 뒤집으면 된다.