객체지향 디자인 원칙

A collection of 4 posts
design pattern

객체지향 디자인 원칙

바뀌는 부분은 캡슐화한다. [http://whiteship.tistory.com/261] 상속보다는 구성을 활용한다. [http://whiteship.tistory.com/262] 구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다. 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다. [http://whiteship.tistory.com/263] 클래스는 확장에 대해서는 열려있지만 변경에 대해서는 닫혀 있어야 한다. 추상화된 것에 의존하라.
1 min read
객체지향 디자인 원칙

Losely Coupled를 활용하라.

서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다. 라는 원칙인데 간단히 줄여봤습니다. 2장 Observer Pattern => WheatherData와 Display가 서로 인터페이스를 가지고 있슴으로 해서 둘의 종속성을 느슨하게 했습니다. p91 쌍방간에 인터페이스를 활용한 예제는 2장 Observer Pattern 밖에 없는 것 같습니다. 단방향으로 느슨한 결합은 거의 단원에서 보여지고 있기 때문에 생략합니다.
1 min read
Composition

상속보다는 구성을 활용한다.

1장 Stratey Pattern => Duck 클래스에서 Flyable과 Quackable 인터페이스를 가지고 있습니다. p44 3장 Decorator Pattern => CondimentalDecorator는 상속과 Composition을 둘 다 활용하고 있습니다. p130 4장 Factory Pattern => 각각의 PizzaStore는 PizzaIngredientFacrory 인터페이스를 가지고 있습니다. p195 7장 Adapter Pattern => 객체 어댑터의 경우 Compositon을 활용하여 유연성을 높이고 있습니다. p283 9장 Composite Pattern => Decorator Pattern과 비슷한
1 min read
객체지향 디자인 원칙

바뀌는 부분을 캡슐화 한다.

1장 Stratey Pattern => fly()와 quack()이 여러 형태가 존재하기 때문에 interface로 따로 빼내었습니다. p44 2장 Observer Pattern => display()를 따로 빼내었습니다. p79 3장 Decorator Pattern => cost()를 따로 빼내었습니다. p120 4장 Factory Pattern => orderPizza()를 팩토리 메소드로 빼냈습니다. p150 5장 Command Pattern => 요구사항(action())을 커맨드 객체로 캡슐화 p244