게임 프로그래머를 위한 클래스 설계
SOLID CLASS DESIGN
신규개발 3본부
조정훈

발표자
조정훈
@blindex99
2003 ~ 마비노기
~ 2012 마비노기2

모든 프로그래머들의 고민
오늘 점심 뭐 먹을까 말고

왜 내 코드는 폭발하는가

퇴근해서 디아3도 해야하는데

성현들의 가르침
어른들 말씀 틀린거 하나 없다

- KISS
- DRY
- HCLC

KISS
Keep It Simple, Stupid
- 간결함은 미덕이다
- 오컴의 면도날
간결하게 만들어야 그걸로
복잡한걸 만들지 이 멍청아! ‚Kelly‛ Johnson
Skunkworks Lead Engineer

SR-71 ‚Blackbird‛
가장 높이, 빨리 나는 비행기

DRY
Don’t Repeat Yourself
- Once And Only Once
- Rules Of Three
Three or more?
Charles Petzold
Use a for! Microsoft Most Valuable Professianal

한마디로 복붙하지 말란 이야기
문제도 복사된단 말이다

HCLC
High Cohesion Louse Coupling
- 높은 응집도, 낮은 결합도
- 비슷한 것들은 뭉쳐 있어야 한다
- 서로의 의존도는 낮아야 한다
Is It Good Programming? Larry Constantine
Check Cohesion & Coupling Writer of ‚Structured Design‛

연관된 기능을 하는 객체들은 가까울수록 좋다
시간적, 공간적, 논리적 측면에서 모두

여기서 잠깐
어르신들 말씀이 다 맞는데요

어떻게요!
누군 복붙 하고 싶어서 하나

SOLID
이 밤의 끝을 잡는 그 솔리드?

- S RP
- O CP
- L SP
- I SP
- D IP

Single Responsibility Principle
단일 책임 원칙

하나의 객체는 하나의 책임을 가짂다
- 그 하나의 책임에 의해서만 변경된다
- GRASP
General
Responsibility
Assignment
Software
Pattern
君君臣臣父父子子

GOD OBJECT
- 전지 전능한 객체 - MONSTER OBJECT
모든 것에 접근, 수정 가능하다 비대해져서 수정이 어려운 객체

저런 코드를 누가 만들어
누굴 초보로 아나

Omnipresence
- 신께서는 어디에나 존재하신다
물론 여러분의 코드에도
- CGod
- CCharacter
- CWorld
가슴에 손을 얹고 반성해봅시다

산탄총 수술
- 하나의 수정 사항이 여러 모듈에 영향을 미침
- 단순한 기능을 고치는데 여러 파일을 수정해야 한다면 의심해보자
새로 사는게 싸겠는데요?

컴포넌트 시스템
최소의존 게임 컴포넌트 시스템
NDC2009 - 조정훈

Open Closed Principle
개방 폐쇄 원칙

확장에는 열려있고, 변경에는 닫혀있다
- 모듈의 수정 없이 기능 확장 가능
- 인터페이스는 임의로 변경할수 없다
- 변경은 오류를 수정할때만
- 확장은 새 클래스로 구현한다

USB
- Universal Serial Bus
- 통일된 인터페이스
- 표준만 지키면 확장은 자유 다양한 악세서리

당연한거 아닌가?
- 안 당연하던 시절이 있었습니다
- 수정이 무한대로 가능하던 시절

IT에선 저런 삽질 안함
USB좋은건 초등학생도 안다

에러 리포트 시스템
- Assert
- Throw Exception
- Error Mail
- DB/File Log
- Dialog Box

라이브 서비스에서의 오류 보고
이 부분이 예상보다 많이 발생하면?

IErrorReporter
- 상속해서 콘크리트 에러 리포터를 만드는 것은 자유
- IErrorReporter 자체를 수정하는 것은 금지

Liskov Substitution Principle
리스코프 치환 원칙

객체는 부모 객체를 대체가능해야 한다
Derived Class ‘is-a’ Base Class
Barbara Liskov
First Woman Ph.D in CS
MIT Professor
Turing Award Winner

Bag is-an Inventory
- 많은 부분이 동일하다
- Bag은 Inventory의 특수한 형태
- 통상 Inventory를 먼저 구현한다
Bag은 Inventory를 상속한다 World of Warcraft
Blizzard

You just activated my trap card!

Bag in the Bag
- 인벤토리는 가방을 수납할수 있다
- 따라서 가방안에 가방을 넣을수 있다
인벤토리는 무한하다
Infinite box
rumo_der_wolperdinger

Bag is not an Inventory (LSP)
- 인벤토리와 가방은 상속관계여선 안된다

Interface Segregation Principle
인터페이스 격리 원칙

인터페이스는 서로 격리되어야 한다
- 객체는 사용하지 않는 인터페이스의 영향을 받아서는 안된다
- 필요 인터페이스만 사용 가능해야한다
- 미사용 인터페이스는 구현하지 않는다

몬스터 집단 행동
- 몬스터는 동료 몬스터를 도와준다
- SRP 원칙은 준수
- SRP = ISP ?

보스 몬스터와의 연계
- 보스 몬스터
보스는 단독으로 행동함
- FindBuddy?
필요 없는 인터페이스

보스 & 집단행동 몬스터(ISP)
- 무리 인터페이스 분리

Dependency Inversion Principle
의존성 역전 원칙

상위 객체는 하위 객체를 몰라야 한다
- 의존성 순환이 벌어지면 안된다
- 추상화 인터페이스를 이용한다
- A Knows B
- B Knows A (X)
- B Knows Abstract A (O)

게임 로직 & 렌더러
- GameLogic Render to Renderer
- Render GetRenderObjects from GameLogic
- GameLogic knows Renderer
- Renderer knows GameLogic

게임 로직 & 더미 렌더러
- 더미 클라이언트
- 성능을 위해 간략한 버전의 렌더러를 작성
- 렌더러가 변경되면 더미 렌더러도 변경해줘야 한다

Abstract Factory Pattern
- 필요에 따라 원하는 객체를 생성해준다
- RenderFactory Knows Renderer, DummyRenderer
- GameLogic Knows IRenderer

Inversion Of Control
- 복수개 또는 0개의 렌더러가 등록되어야 한다면?
- Callback, Event Handler
- GameLogic Doesn’t know IRenderer

정리
이것만 기억하세요

목차/챕터/간지

References
- SOLID Development Principles – In Motivational Pictures
http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures
- Agile Code Design
http://www.planetgeek.ch/2011/07/08/presentation-agile-code-design-how-to-keep-your-code-flexible/
- Is your design SOLID?
http://blogs.globallogic.com/is-your-design-solid
- 객체지향 SW 설계의 원칙
http://www.zdnet.co.kr
- Wikipedia
http://wikipedia.org

http://devcat.nexon.com/M2_Recruit.html