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.

데브루키 스터디 발표

1,576 views

Published on

의존관계역전원칙
DIP
Bridge pattern
Layer architecture
에 관한 PT

  • Login to see the comments

데브루키 스터디 발표

  1. 1. DIPBridge patternLayer architecture<br />Devrookie, http://cafe.naver.com/devrookie<br />최기원<br />
  2. 2. DIP<br />Bridge pattern<br />Layer architecture<br />
  3. 3. DIP<br />Bridge pattern<br />Layer architecture<br />설계<br />
  4. 4. 소프트웨어 설계<br />왜 공부해야 할까?<br />개발중인 게임은 계속 바뀐다.<br />서비스중인 게임은 계속 바뀐다.<br />
  5. 5. 소프트웨어 설계<br />왜 공부해야 할까?<br />개발중인 게임은 계속 바뀐다.<br />서비스중인 게임은 계속 바뀐다.<br />점프 만들어주세요.<br />
  6. 6. 소프트웨어 설계<br />왜 공부해야 할까?<br />개발중인 게임은 계속 바뀐다.<br />서비스중인 게임은 계속 바뀐다.<br />점프 만들어주세요.<br />마영전 봐라 다음주부터 점프한댄다.<br />
  7. 7. 다음달부터는 말탈지도 몰라..<br />화살도 쏴야 하고..<br />말타면서 화살도 쏘고..<br />말타고 경주하는 레이싱 모드..<br />날아다니는 개새 몬스터가 추가될지도...<br />
  8. 8. 다음달부터는 말탈지도 몰라..<br />화살도 쏴야 하고..<br />말타면서 화살도 쏘고..<br />말타고 경주하는 레이싱 모드..<br />날아다니는 개새 몬스터가 추가될지도...<br />개새 이야기는 이창희님 PT를 보세요.<br />
  9. 9. 어떻게 하면 유연하게 기능을 추가 할 수 있을까?<br />
  10. 10. 응집도는 높게(High Cohesion)<br />의존성은 낮게 (Loose Coupling)<br />소프트웨어 디자인과 아키텍쳐 평가의보편적이고 일반적인 기준<br />
  11. 11. 응집도 높게<br />하나의 모듈에 하나의 기능을 온전히 담게 하는것<br />
  12. 12. 응집도가 높으면 뭐가 좋을까?<br />‘점프를 넣어주세요’ 라는 요구사항이 생겼을때..<br />케릭터 기능만 수정 하면 된다.<br />될까? 현실적으로 ㅡㅡ;; 뻥치는거 같애<br />응집도가 와방 높다면 케릭터 쪽만 하면 되겠죠.<br />
  13. 13. 의존성<br />서로 다른 기능의 모듈이 얼마나 얽혀 있는가.<br />상호 의존도가 얼마나 높은가<br />
  14. 14. 의존성이 낮으면 뭐가 좋을까?<br />‘점프를 넣어주세요’ 라는 요구사항이 생겼을때..<br />케릭터 기능만 수정 하면 된다.<br />될까? 현실적으로 ㅡㅡ;; 뻥치는거 같애<br />의존성이 와방 낮다면 케릭터 쪽만 하면 되겠죠.<br />
  15. 15. 응집도 ∝ 의존성<br />어떻게 설계하면 응집도가 올라가고 의존성이 내려갈까?<br />
  16. 16. OOP 설계 5대 원칙<br />SRP (Single Reponsibility)<br />단일 책임 원칙<br />OCP (Open Close)<br />개방 폐쇄 원칙<br />LSP (Liskov Substitution)<br />리스코프 교체 원칙<br />ISP (Interface Segregation)<br />인터페이스 격리 원칙<br />DIP (Dependency Inversion)<br />의존 관계 역전 원칙<br />OOP 설계를 할때<br />이것들을 한번씩 <br />생각 하면 ,<br />응집도는 높아지고<br />의존성은 낮아진다.<br />
  17. 17. OOP 설계 5대 원칙<br />SRP (Single Reponsibility)<br />단일 책임 원칙<br />OCP (Open Close)<br />개방 폐쇄 원칙<br />LSP (Liskov Substitution)<br />리스코프 교체 원칙<br />ISP (Interface Segregation)<br />인터페이스 격리 원칙<br />DIP (Dependency Inversion)<br />의존 관계 역전 원칙<br />
  18. 18. DIP<br />Bridge pattern<br />Layer architecture<br />
  19. 19. Dependency 의존관계Inversion 역전Principle 원칙<br />상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다.<br />
  20. 20. Dependency<br />의존 관계<br />LightSwitch<br />Light<br />LigthSwitch는 Light의 기능을 사용하여 자신의 기능을 수행한다.<br />
  21. 21. Class LightSwitch {<br /> …<br />public:<br /> void on()<br /> { pLight->on(); }<br /> void off()<br /> { pLight->off(); }<br /> void setLight(Light* p)<br /> { pLight = p; }<br /> …<br />private:<br />Light* pLight;<br /> …<br />}<br />Class Light {<br /> …<br />public:<br /> void on();<br /> void off();<br /> …<br />}<br />
  22. 22. …Light stand;<br /> LightSwitch stand_switch;<br /> // stand_switch에 stand를 연결<br /> stand_switch.setLight(&stand);<br /> stand_switch.on(); // stand를 킨다.<br /> ...<br /> stand_switch.off(); // stand를 끈다.<br /> ...<br />
  23. 23. Dependency<br />의존 관계<br />LightSwitch<br />Light<br />
  24. 24. Dependency Inversion<br />의존 관계 역전?<br />LightSwitch<br />Light<br />
  25. 25. Class LightSwitch {<br /> …<br />public:<br /> void on();<br /> void off();<br /> …<br />}<br />Class Light{<br /> …<br />public:void on() <br />{ pSwitch->on(); }<br /> void off()<br />{ pSwitch->off();}<br /> …<br />private:<br />LightSwitch* pSwitch;<br />}<br />
  26. 26. ?<br />Class LightSwitch {<br /> …<br />public:<br /> void on();<br /> void off();<br /> …<br />}<br />Class Light{<br /> …<br />public:void on() <br />{ pSwitch->on(); }<br /> void off()<br />{ pSwitch->off();}<br /> …<br />private:<br />LightSwitch* pSwitch;<br />}<br />역전<br />
  27. 27. 역전의 의미<br />인터페이스를 누가 정하는가!!!<br />
  28. 28. 파란게 빨간걸 의존한다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />Light<br />Switch는 Switch로서의 기능만을<br />Light는 Light로서의 기능만을 한다.<br />
  29. 29. Switch가 인터페이스를 제공한다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />
  30. 30. Class Switch {<br /> …<br />public:<br /> void on()<br /> { pSObject->on(); }<br /> void off()<br /> { pSObject->off();}<br /> void setSwitchableObject ( ISwitchableObject* p ) <br /> { pSObject = p; }<br /> …<br />private:<br />ISwitchableObject* pSObject;<br /> …<br />}<br />Class ISwitchableObject {<br /> …<br />public:<br />virtual void on() = 0;<br /> virtual void off() = 0;<br /> …<br />}<br />
  31. 31. Light가 인터페이스에 맞게 구현을 바꾼다.<br /><<interface>><br />ISwitchableObject<br />Light<br />
  32. 32. Class Light : public<br /> ISwitchableObject {<br /> …<br />public:<br />void on();<br /> void off();<br /> …<br />}<br />Class ISwitchableObject {<br /> …<br />public:<br />virtual void on() = 0;<br /> virtual void off() = 0;<br /> …<br />}<br />
  33. 33. 파란게 빨간걸 의존한다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />Light<br />Switch는 Switch로서의 기능만을<br />Light는 Light로서의 기능만을 한다.<br />
  34. 34. …SwitchableObject pLight = new Light;<br /> Switch lightSwitch;<br />lightSwitch.setSwitchableObject(pLight);<br />lightSwitch.on();<br />lightSwitch.off();<br /> ...<br />
  35. 35. 뭐가 붙어도 Switch는 수정이 필요없다. 하지만,<br />Switch 인터페이스 수정하면 대망, 확장은 상관 없다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />Light<br />TV<br />이것저것<br />
  36. 36. 뭐가 붙어도 Switch는 수정이 필요없다. 하지만,<br />Switch 인터페이스 수정하면 대망, 확장은 상관 없다.<br />OpenClose Principle<br /><<interface>><br />ISwitchableObject<br />Switch<br />Light<br />TV<br />이것저것<br />
  37. 37. …SwitchableObject pTv = new TV();<br /> Switch tvSwitch;<br /> tvSwitch.setSwitchableObject(pTv);<br />tvSwitch.on();<br />tvSwitch.off();<br /> ...<br />…SwitchableObject pLight = new Light;<br /> Switch lightSwitch;<br /> lightSwitch.setSwitchableObject(pLight);<br /> lightSwitch.on();<br /> lightSwitch.off();<br /> ...<br />
  38. 38. DependencyInversion Principle<br />상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다.<br />복습<br /><<interface>><br />ISwitchableObject<br />Switch<br />Light<br />
  39. 39. DIP<br />Bridge pattern<br />Layer architecture<br />
  40. 40. 패턴 이란?<br />의존성은 낮게응집도는 높게 하다 보니 자주 사용되는 설계 패턴이 생겼다.<br />
  41. 41. Bridge Pattern<br />Client<br /><<interface>><br />Implementor<br />Abstraction<br />RefinedAbstraction<br />ConcreteImplemntorA<br />ConcreteImplemntorB<br />
  42. 42. Bridge Pattern<br />정적인 구조 보다는 <br />패턴의 의도가 <br />중요하다.<br />Client<br /><<interface>><br />Implementor<br />Abstraction<br />RefinedAbstraction<br />ConcreteImplemntorA<br />ConcreteImplemntorB<br />
  43. 43. Bridge Pattern<br />의도 : <br />인터페이스를 통해 서브시스템사이의 의존성을 없앤다. 이는 한 서브시스템의 변화가 다른 서브시스템에 영향을 미치지 못하게 한다.<br />
  44. 44. DIP를 Pattern으로 응용하면<br />
  45. 45. ISwitchableObject 인터페이스를 통해 Switch와 Light사이의 의존성을 없앴다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />인터페이스를 통해 서브시스템사이의 의존성을 없앤다. 이는 한 서브시스템의 변화가 다른 서브시스템에 영향을 미치지 못하게 한다.<br />Light<br />
  46. 46. 패턴에 대한 생각.<br />그냥 귀에 걸면 귀걸이 코에 걸면 코걸이 원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게응집도 높게만들자.<br />
  47. 47. 패턴에 대한 생각.<br />그냥 귀에 걸면 귀걸이 코에 걸면 코걸이 원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게응집도 높게만들자.<br />
  48. 48. DIP<br />Bridge pattern<br />Layer architecture<br />
  49. 49. Dependency InversionPrinciple <br />Architecture에 응용하면?<br />
  50. 50. 아키텍처<br />가장 첫단계는 시스템을 추상화 수준에 따라서 구분한다.<br />
  51. 51. 일반적인 게임의 아키텍쳐<br />
  52. 52. 의존관계를 따지면<br />렌더러<br />게임로직<br />시스템<br />
  53. 53. <<interface>><br />렌더러가 사용하는 인터페이스<br />렌더러<br /><<interface>><br />게임로직이 사용하는 인터페이스<br />게임로직<br />DIP 적용<br />시스템<br />
  54. 54. DependencyInversion Principle<br />상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다.<br /><<interface>><br />렌더러가 사용하는 인터페이스<br />렌더러<br /><<interface>><br />게임로직이 사용하는 인터페이스<br />게임로직<br />시스템<br />또 다시 복습<br />
  55. 55. 끝, 정리<br />오늘 이야기한 것들을 <br />두개의 키워드로 정리하면 뭘까요?<br />질문???<br />
  56. 56. 박일님 PT<br />http://parkpd.egloos.com/3339098<br />공봉식님 PT<br />http://www.slideshare.net/kongbong/3-4646419<br />Kasa 이창희님 PT<br />http://dev3d.tistory.com/32<br />NDC2010, 김주복님 PT 46~55p<br />http://ndc.nexon.com/150088595939<br />

×