Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012

16,074 views

Published on

Published in: Technology

조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012

  1. 1. 게임 프로그래머를 위한 클래스 설계SOLID CLASS DESIGN신규개발 3본부조정훈
  2. 2. 발표자 조정훈@blindex99 2003 ~ 마비노기 ~ 2012 마비노기2
  3. 3. 모든 프로그래머들의 고민오늘 점심 뭐 먹을까 말고
  4. 4. 왜 내 코드는 폭발하는가
  5. 5. 퇴근해서 디아3도 해야하는데
  6. 6. 성현들의 가르침어른들 말씀 틀린거 하나 없다
  7. 7. - KISS- DRY- HCLC
  8. 8. KISSKeep It Simple, Stupid- 간결함은 미덕이다- 오컴의 면도날 간결하게 만들어야 그걸로 복잡한걸 만들지 이 멍청아! ‚Kelly‛ Johnson Skunkworks Lead Engineer
  9. 9. SR-71 ‚Blackbird‛가장 높이, 빨리 나는 비행기
  10. 10. DRYDon’t Repeat Yourself- Once And Only Once- Rules Of Three Three or more? Charles Petzold Use a for! Microsoft Most Valuable Professianal
  11. 11. 한마디로 복붙하지 말란 이야기 문제도 복사된단 말이다
  12. 12. HCLCHigh Cohesion Louse Coupling- 높은 응집도, 낮은 결합도- 비슷한 것들은 뭉쳐 있어야 한다- 서로의 의존도는 낮아야 한다 Is It Good Programming? Larry Constantine Check Cohesion & Coupling Writer of ‚Structured Design‛
  13. 13. 연관된 기능을 하는 객체들은 가까울수록 좋다 시간적, 공간적, 논리적 측면에서 모두
  14. 14. 여기서 잠깐어르신들 말씀이 다 맞는데요
  15. 15. 어떻게요!누군 복붙 하고 싶어서 하나
  16. 16. SOLID이 밤의 끝을 잡는 그 솔리드?
  17. 17. - S RP- O CP- L SP- I SP- D IP
  18. 18. Single Responsibility Principle단일 책임 원칙
  19. 19. 하나의 객체는 하나의 책임을 가짂다- 그 하나의 책임에 의해서만 변경된다- GRASP General Responsibility Assignment Software Pattern 君君臣臣父父子子
  20. 20. GOD OBJECT- 전지 전능한 객체 - MONSTER OBJECT 모든 것에 접근, 수정 가능하다 비대해져서 수정이 어려운 객체
  21. 21. 저런 코드를 누가 만들어누굴 초보로 아나
  22. 22. Omnipresence- 신께서는 어디에나 존재하신다 물론 여러분의 코드에도- CGod - CCharacter - CWorld 가슴에 손을 얹고 반성해봅시다
  23. 23. 산탄총 수술- 하나의 수정 사항이 여러 모듈에 영향을 미침- 단순한 기능을 고치는데 여러 파일을 수정해야 한다면 의심해보자 새로 사는게 싸겠는데요?
  24. 24. 컴포넌트 시스템 최소의존 게임 컴포넌트 시스템 NDC2009 - 조정훈
  25. 25. Open Closed Principle개방 폐쇄 원칙
  26. 26. 확장에는 열려있고, 변경에는 닫혀있다- 모듈의 수정 없이 기능 확장 가능- 인터페이스는 임의로 변경할수 없다- 변경은 오류를 수정할때만- 확장은 새 클래스로 구현한다
  27. 27. USB- Universal Serial Bus- 통일된 인터페이스- 표준만 지키면 확장은 자유 다양한 악세서리
  28. 28. 당연한거 아닌가?- 안 당연하던 시절이 있었습니다- 수정이 무한대로 가능하던 시절
  29. 29. IT에선 저런 삽질 안함USB좋은건 초등학생도 안다
  30. 30. 에러 리포트 시스템- Assert- Throw Exception- Error Mail- DB/File Log- Dialog Box
  31. 31. 라이브 서비스에서의 오류 보고 이 부분이 예상보다 많이 발생하면?
  32. 32. IErrorReporter- 상속해서 콘크리트 에러 리포터를 만드는 것은 자유- IErrorReporter 자체를 수정하는 것은 금지
  33. 33. Liskov Substitution Principle리스코프 치환 원칙
  34. 34. 객체는 부모 객체를 대체가능해야 한다 Derived Class ‘is-a’ Base Class Barbara Liskov First Woman Ph.D in CS MIT Professor Turing Award Winner
  35. 35. Bag is-an Inventory- 많은 부분이 동일하다- Bag은 Inventory의 특수한 형태- 통상 Inventory를 먼저 구현한다 Bag은 Inventory를 상속한다 World of Warcraft Blizzard
  36. 36. You just activated my trap card!
  37. 37. Bag in the Bag- 인벤토리는 가방을 수납할수 있다- 따라서 가방안에 가방을 넣을수 있다 인벤토리는 무한하다 Infinite box rumo_der_wolperdinger
  38. 38. Bag is not an Inventory (LSP)- 인벤토리와 가방은 상속관계여선 안된다
  39. 39. Interface Segregation Principle인터페이스 격리 원칙
  40. 40. 인터페이스는 서로 격리되어야 한다- 객체는 사용하지 않는 인터페이스의 영향을 받아서는 안된다- 필요 인터페이스만 사용 가능해야한다- 미사용 인터페이스는 구현하지 않는다
  41. 41. 몬스터 집단 행동- 몬스터는 동료 몬스터를 도와준다- SRP 원칙은 준수- SRP = ISP ?
  42. 42. 보스 몬스터와의 연계- 보스 몬스터 보스는 단독으로 행동함- FindBuddy? 필요 없는 인터페이스
  43. 43. 보스 & 집단행동 몬스터(ISP)- 무리 인터페이스 분리
  44. 44. Dependency Inversion Principle의존성 역전 원칙
  45. 45. 상위 객체는 하위 객체를 몰라야 한다- 의존성 순환이 벌어지면 안된다- 추상화 인터페이스를 이용한다- A Knows B- B Knows A (X)- B Knows Abstract A (O)
  46. 46. 게임 로직 & 렌더러- GameLogic Render to Renderer- Render GetRenderObjects from GameLogic- GameLogic knows Renderer- Renderer knows GameLogic
  47. 47. 게임 로직 & 더미 렌더러- 더미 클라이언트- 성능을 위해 간략한 버전의 렌더러를 작성- 렌더러가 변경되면 더미 렌더러도 변경해줘야 한다
  48. 48. Abstract Factory Pattern- 필요에 따라 원하는 객체를 생성해준다- RenderFactory Knows Renderer, DummyRenderer- GameLogic Knows IRenderer
  49. 49. Inversion Of Control- 복수개 또는 0개의 렌더러가 등록되어야 한다면?- Callback, Event Handler- GameLogic Doesn’t know IRenderer
  50. 50. 정리이것만 기억하세요
  51. 51. 목차/챕터/간지
  52. 52. 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
  53. 53. http://devcat.nexon.com/M2_Recruit.html

×