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 이라고 함
서로 꼬여져 있으면
수정할 때마다 이 파일 저 파일 뒤져야 함
문 같은 on. off 스위치 구현 할 때의 예시
Switch 와 ISwitchable 을 따로 뻬는 전략을 써서 서로 분리하기
Switch 안엔
ISwitchable client; 한줄만 넣어버리는 거다
주의점
abstract 상속은 두개 이상 못한다
그래서 abstract 와 interface 를 같이 써서 다중 상속을 구현한다
abstract 추상 클래스 i interface 차이
