이름이 익명 :: HOW TO UNITY

HOW TO UNITY | SOLID 원칙

unity 유니티 공부 2025. 11. 22. 03:07 |

https://www.youtube.com/watch?v=J6F8plGUqv8&list=PL412Ym60h6uvqYiCVKk5NiEFpDEwOMQFX&index=9

디자인 패턴 기원

디자인 패턴 연구는 gang of Four 에서 출발
네 명의 사람이 연구한 거고
이 사람들이 낸 gof 어쩌구 책에서 출발한 거임

+

SOLID Principles 솔리드 원칙

게임 뿐만 아니라 모든 소프트웨어는 이 솔리드 법칙을 지켜야 한다

꼬여버리지 않게 하기 위한 약속

단일 책임 원칙 (Single Responsibility Principle, SRP)
"하나의 클래스는 딱 하나의 역할만 맡자."

맥가이버 칼 처럼 다 하는 것 보단
주방 조리기구 처럼 각각 따로 쓰는 게 효율적이다

개방-폐쇄 원칙 (Open/Closed Principle, OCP)
"확장에는 열려있고, 수정에는 닫혀있어야 한다."

핸드폰 케이스 부착시킬 땐 핸드폰 본체를 뜯는 사람은 없다

리스코프 치환 원칙 (Liskov Substitution Principle, LSP)
"자식 클래스는 부모 클래스 역할을 완벽하게 대신할 수 있어야 한다."

오리 를 만들 었는데 날개도 없고 부리도 없으면 안된다
새 의 기본 기능을 탑재하고 있어야 한다

인터페이스 분리 원칙 (Interface Segregation Principle, ISP)
"한꺼번에 다 담지 마라, I 인터페이스를 잘게 쪼개라."

식당에서 짜장면 하나만 시키려는데
모든 메뉴판을 다 읽어야 한다면 불편하다

의존역전 원칙 (Dependency Inversion Principle, DIP)
"또렷한 것에 의존하지 말고, 추상적인 것(I 인터페이스)에 의존해라."

전기 플러그를 꽂을 때, 콘센트 구멍만 맞으면 되지
그 전기가 화력발전소에서 왔는지 원자력발전소에서 왔는지 따지지 말 것

사실 여기서 더 깊게 생각하자면,
부모 자식 관게는 칼로 물베기임

뭐가 하이레벨이냐 뭐가 로우레벨이냐
딱 정확히 가를 순 없음

세부 부연 설명 추가

단일 책임 원칙 Single Responsibility Principle, SRP

인스펙터 창 컴포넌트가 그 예시다

코드 300 줄 이하, 간결해야 한다

모듈처럼 분리되어 있다

그래서 자식으로 부착이 쉽다

이렇게 하나의 class 안에 모든 걸 다 때려박으면 불 편

class 를 여러개 만들어 나누는 게 좋다

PlayerAudio

PlayerInput

PlayerMovement

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

실무에선 DLL, 라이브러리 를 직접 수정하지 않는다

원본은 냅두고

모드, 모듈만 갈아치우는 느낌으로 만든다

원본으로 잡은 건 Shape, 추상적인 개념

Rectangle : Shape

Circle : Shape

쉐이프 밑 자식을 추가함

네모와 동그라미를 자식으로 배치하는 느낌으로 만듦

림월드 모딩의 헉스립 PatchOperation 를 예로 들면,

더하고 , 빼는 것도 있음
원본을 수정 하는 것도 있음

원본 수정을 패치 를 통해서 하기도 함

Liskov subs 원칙

부모님이 죽으면 자식이 그 사회에서 역할을 대신할 수 있어야 한다

서브 클래스 만들 때 기능을 제거하지 마라

abstract 추상화 할 땐 단순하게 유지하라
추상화 된 걸 복잡하게 만들면 아무데도 못 쓰는 빈 껍데기 코드만 남음

팩토리 패턴 비슷한 개념이다

Vehicle 탈 것 아래엔
Car 도 있고 Train 도 있다

하지만 그냥 이렇게 만들면
어? 기차는 좌회전 우회전 못하는데? 하며 충돌 일어남

부모인 Vehicle 을 둘로 쪼개서

ITurnable IMovable 로 나눔

ITurnable 좌우 방향 조절 가능

IMovable 앞 뒤 이동 가능

인터페이스 분리 원칙 Interface Segregation

큰 덩어리 인터페이스들을 구체적이고 작은 단위로 분리
꼭 필요한 메서드만 이용할 수 있게 함

내부에 의존하지 말고 유연하게 할 수 있게 됨

I 인터페이스 뜻
청사진, 계약서, 큰 틀

IDamageable
피해를 입을 수 있는 것
이펙트 총알 말고, 플레이어 몬스터 를 뜻함

TakeDamage
피해를 입다

IExplodable
폭발할 수 있는것, 화약 통 같은 거

폭발통 의 경우

데미지 입을 수 있고, 폭발할 수 있음

적 유닉 의 경우

데미지 입을 수 있고, 이동할 수 있고, 유닛 스탯도 있음

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

추상화, abstraction 에 의존하자

클래스 간에 서로 끈끈하게 연결이 되는 걸 피하라
되도록 서로 나눠져야 함

철수가 영희의 하위 변수를 쓰고,
영희가 영수의 하위 함수를 쓰고
이렇게 서로 꼬이는 걸 피하라

이렇게 서로 꼬여져 있는 걸 결합, coupling 이라고 함

서로 꼬여져 있으면
수정할 때마다 이 파일 저 파일 뒤져야 함