Design Pattern

3 minute read

필요한 내용만 정리

Strategy pattern

Encapsulate what varies!

Reuse in Object-Oriented System

  1. Class Inheritance
     subclass’ implementation is defined in terms of the parent class’ implementation.
     the parent class implementation is often visible to the subclasses
     While-box reuse
    (+) done at compile-time and is
    easy to use
    (-) the subclass becomes
    dependent on the parent class implementation
    (-) the inherited implementation
    cannot be changed at run-time
  2. Object Composition
     objects are composed to achieve more complex functionality
     needs well-defined interfaces since the internals of the objects are unknown
     functionality is acquired dynamically at run-time by utilizing references to other objects
     Black-box reuse
    (+) implementations can be replaced at
    run-time
    (+) less implementation dependencies (-) harder to understand

Hierarchy of Pattern Knowledge

Design Patterns
 Knowing the OO basics does not make you a good OO designer
 Good OO design are reusable, extensible and maintainable
 Patterns don’t give you code, they give you general solutions to design problems
 Most patterns and principles address issues of change in software.

Way to Learn Design Patterns
 Learning how such a pattern was discovered
 When people begin to look at design patterns, they often focus on the solutions the patterns offer. This seems reasonable because they are advertised as providing good solutions to the problems at hand.
 However, this is starting at the wrong end. When you learn patterns by focusing on the solutions they present, it makes it hard to determine the situations in which a pattern applies. This only tells us what to do but not when to use it or why to do it.

Template method pattern

Design Principle: Hollywood Principle
 The Hollywood Principle: Don’t call us, we’ll call you!
 It prevents “Dependency rot”
 Dependency rot: high-level components depend on low-level components, and vice versa.
 With the Hollywood principle
 We allow low level components to hook themselves into a system
 But high level components determine when they are needed and how.
 High level components give the low-level components a “don’t call us, we’ll call you” treatment.

Iterator pattern

Single Responsibility
 A class should have only one reason to change  Aggregate and Iteration – two different responsibilities  Cohesion
• measure of how closely a class or a module supports a single purpose or responsibility
• High cohesion – designed around a set of related functions
• Low cohesion – designed around a set of unrelated functions

보관과 꺼내는건 다른 책임이다

Factory Method pattern

concrete class를 몰라도 객체를 생성할 수 있어야한다(DIP)
=> new를 추상화하라

Factory method => use inheritance -> 템플릿메소드의 생성버전
Abstract Factory => use delegates

public abstract class PizzaStore {  
	public Pizza order(String type) {  
		return createPizza(type);  
	}  
  
	protected abstract Pizza createPizza(String type);	// 누군가 채워줄 것이다. 프레임워크.  
}

Abstract Factory pattern

object pattern
delegates creation calls
제품군별 생성 클래스 위임

Builder pattern

여러파트의 합으로 뭔가를 만들때(문장처럼)
전략패턴의 생성버전
abstract factory와의차이는 abstract factory는 각 부품들을 원하는 것이고(그래서 조립순서에는 관여안함)
빌더는 부분의 합으로 만들어주지만 결과물만을 원하는 것이다

Decorator pattern

OCP를 만족하면서 확장할 수 있도록

decorators have the same super type as the objects they decorate

 public abstract class CondimentDecorator extends Beverage { protected Beverage beverage;  
public abstract String getDescription();  
}  
public class Mocha extends CondimentDecorator { public Mocha(Beverage beverage) {  
this.beverage = beverage; }  
public String getDescription() {  
return beverage.getDescription() + ", Mocha";  
}  
public double cost() {  
return .20 + beverage.cost();  
} }

자바 표준라이브러리의
BufferedInputStream같은것도 활용된것

recursive 활용

Adapter pattern

Composite pattern

object hierarchies

트리구조인데 부모형태로 계속 순회할수있는거

Where to place Child Mgt. Interface?

Bridge Pattern

추상계층과 구현계층을 분리

한쪽이 다른한쪽을 참조해야하는데 참조 방향은 grasp에서 말하듯
인포메이션을 가진쪽이 참조하라

Summary

디자인패턴을 쓰는 이유
designing for change

  • Creating an Object by specifying a class explicitly -> abstract factory, factory method, builder
  • Dependence on Hardware and software platform -> bridge, abstract factory
  • algorithmic dependancy -> builder, iterator, strategy, template method
  • Extending functionality by subclassing -> bridge, composite, decorator, strategy
  • inability to alter classes conveniently -> adapter, decorator

You may also enjoy