DIPBridge patternLayer architecture<br />Devrookie, http://cafe.naver.com/devrookie<br />최기원<br />
DIP<br />Bridge pattern<br />Layer architecture<br />
DIP<br />Bridge pattern<br />Layer architecture<br />설계<br />
소프트웨어 설계<br />왜 공부해야 할까?<br />개발중인 게임은 계속 바뀐다.<br />서비스중인 게임은 계속 바뀐다.<br />
소프트웨어 설계<br />왜 공부해야 할까?<br />개발중인 게임은 계속 바뀐다.<br />서비스중인 게임은 계속 바뀐다.<br />점프 만들어주세요.<br />
소프트웨어 설계<br />왜 공부해야 할까?<br />개발중인 게임은 계속 바뀐다.<br />서비스중인 게임은 계속 바뀐다.<br />점프 만들어주세요.<br />마영전 봐라 다음주부터 점프한댄다.<br />
다음달부터는 말탈지도 몰라..<br />화살도 쏴야 하고..<br />말타면서 화살도 쏘고..<br />말타고 경주하는 레이싱 모드..<br />날아다니는 개새 몬스터가 추가될지도...<br />
다음달부터는 말탈지도 몰라..<br />화살도 쏴야 하고..<br />말타면서 화살도 쏘고..<br />말타고 경주하는 레이싱 모드..<br />날아다니는 개새 몬스터가 추가될지도...<br />개새 이야기는 이창희님 ...
어떻게 하면 유연하게 기능을 추가 할 수 있을까?<br />
응집도는 높게(High Cohesion)<br />의존성은 낮게 (Loose Coupling)<br />소프트웨어 디자인과 아키텍쳐 평가의보편적이고 일반적인 기준<br />
응집도 높게<br />하나의 모듈에 하나의 기능을 온전히 담게 하는것<br />
응집도가 높으면 뭐가 좋을까?<br />‘점프를 넣어주세요’ 라는 요구사항이 생겼을때..<br />케릭터 기능만 수정 하면 된다.<br />될까? 현실적으로 ㅡㅡ;;  뻥치는거 같애<br />응집도가 와방 높다면 케릭터...
의존성<br />서로 다른 기능의 모듈이 얼마나 얽혀 있는가.<br />상호 의존도가 얼마나 높은가<br />
의존성이 낮으면 뭐가 좋을까?<br />‘점프를 넣어주세요’ 라는 요구사항이 생겼을때..<br />케릭터 기능만 수정 하면 된다.<br />될까? 현실적으로 ㅡㅡ;;  뻥치는거 같애<br />의존성이  와방 낮다면 케릭...
응집도 ∝ 의존성<br />어떻게 설계하면 응집도가 올라가고 의존성이 내려갈까?<br />
OOP 설계 5대 원칙<br />SRP (Single Reponsibility)<br />단일 책임 원칙<br />OCP (Open Close)<br />개방 폐쇄 원칙<br />LSP (Liskov Substituti...
OOP 설계 5대 원칙<br />SRP (Single Reponsibility)<br />단일 책임 원칙<br />OCP (Open Close)<br />개방 폐쇄 원칙<br />LSP (Liskov Substituti...
DIP<br />Bridge pattern<br />Layer architecture<br />
Dependency       의존관계Inversion            역전Principle            원칙<br />상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 ...
Dependency<br />의존 관계<br />LightSwitch<br />Light<br />LigthSwitch는 Light의 기능을 사용하여 자신의 기능을 수행한다.<br />
Class LightSwitch {<br />	…<br />public:<br />	void on()<br />		{ pLight->on(); }<br />	void off()<br />		{ pLight->off();...
	…Light stand;<br />	LightSwitch stand_switch;<br />	// stand_switch에 stand를 연결<br />	stand_switch.setLight(&stand);<br />...
Dependency<br />의존 관계<br />LightSwitch<br />Light<br />
Dependency Inversion<br />의존 관계 역전?<br />LightSwitch<br />Light<br />
Class LightSwitch {<br />	…<br />public:<br />	void on();<br />	void off();<br />	…<br />}<br />Class Light{<br />	…<br />...
?<br />Class LightSwitch {<br />	…<br />public:<br />	void on();<br />	void off();<br />	…<br />}<br />Class Light{<br />	...
역전의 의미<br />인터페이스를 누가 정하는가!!!<br />
파란게 빨간걸 의존한다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />Light<br />Switch는 Switch로서의 기능만을<br />Light는 Lig...
Switch가 인터페이스를 제공한다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />
Class Switch {<br />	…<br />public:<br />	void on()<br />		{ pSObject->on(); }<br />	void off()<br />		{ pSObject->off();}...
Light가 인터페이스에 맞게 구현을 바꾼다.<br /><<interface>><br />ISwitchableObject<br />Light<br />
Class Light : public<br />	ISwitchableObject {<br />	…<br />public:<br />void on();<br />	void off();<br />	…<br />}<br />...
파란게 빨간걸 의존한다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />Light<br />Switch는 Switch로서의 기능만을<br />Light는 Lig...
	…SwitchableObject pLight = new Light;<br />	Switch lightSwitch;<br />lightSwitch.setSwitchableObject(pLight);<br />lightS...
뭐가 붙어도 Switch는 수정이 필요없다.  하지만,<br />Switch 인터페이스 수정하면 대망, 확장은 상관 없다.<br /><<interface>><br />ISwitchableObject<br />Switch...
뭐가 붙어도 Switch는 수정이 필요없다.  하지만,<br />Switch 인터페이스 수정하면 대망, 확장은 상관 없다.<br />OpenClose Principle<br /><<interface>><br />ISwi...
	…SwitchableObject pTv = new TV();<br />	Switch tvSwitch;<br />	tvSwitch.setSwitchableObject(pTv);<br />tvSwitch.on();<br ...
DependencyInversion  Principle<br />상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에...
DIP<br />Bridge pattern<br />Layer architecture<br />
패턴 이란?<br />의존성은 낮게응집도는 높게  하다 보니 자주 사용되는 설계 패턴이 생겼다.<br />
Bridge Pattern<br />Client<br /><<interface>><br />Implementor<br />Abstraction<br />RefinedAbstraction<br />ConcreteImple...
Bridge Pattern<br />정적인 구조 보다는 <br />패턴의 의도가 <br />중요하다.<br />Client<br /><<interface>><br />Implementor<br />Abstraction<...
Bridge Pattern<br />의도 : <br />인터페이스를 통해 서브시스템사이의 의존성을 없앤다. 이는 한 서브시스템의 변화가 다른 서브시스템에 영향을 미치지 못하게 한다.<br />
DIP를 Pattern으로 응용하면<br />
ISwitchableObject 인터페이스를 통해 Switch와 Light사이의 의존성을 없앴다.<br /><<interface>><br />ISwitchableObject<br />Switch<br />인터페이스를 통...
패턴에 대한 생각.<br />그냥 귀에 걸면 귀걸이 코에 걸면 코걸이  원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게응집도 높게만들자.<br />
패턴에 대한 생각.<br />그냥 귀에 걸면 귀걸이 코에 걸면 코걸이  원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게응집도 높게만들자.<br />
DIP<br />Bridge pattern<br />Layer architecture<br />
Dependency InversionPrinciple <br />Architecture에 응용하면?<br />
아키텍처<br />가장 첫단계는 시스템을 추상화 수준에 따라서 구분한다.<br />
일반적인 게임의 아키텍쳐<br />
의존관계를 따지면<br />렌더러<br />게임로직<br />시스템<br />
<<interface>><br />렌더러가 사용하는      인터페이스<br />렌더러<br /><<interface>><br />게임로직이 사용하는  인터페이스<br />게임로직<br />DIP 적용<br />시스템<...
DependencyInversion  Principle<br />상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에...
끝,  정리<br />오늘 이야기한 것들을 <br />두개의 키워드로 정리하면 뭘까요?<br />질문???<br />
박일님 PT<br />http://parkpd.egloos.com/3339098<br />공봉식님 PT<br />http://www.slideshare.net/kongbong/3-4646419<br />Kasa 이창희님...
Upcoming SlideShare
Loading in...5
×

데브루키 스터디 발표

1,067

Published on

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

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,067
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

데브루키 스터디 발표

  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 />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×