Pattern Tips 의 4

Pattern Tips 의 4 저자: 온 욱
감사: 라 는 책의 저자 Gamma, Helm, Johnson 과 Vilsides, 번역자 이 영 군 등
설명
Composite，Decorator。그들 은 모두 Structural Patterns 입 니 다. 그들의 관 계 는 다음 과 같 습 니 다.
----------------------------------Composite----------------------------
● Tip 1: 키워드.Uniform，Tree，Recursive。
● Tip 2: 그림.
그림 에서 여러 개의 '일반화 관계' 를 제외 하고 하나의 '집적 관계' 만 남 았 다 ('관 계 를 구성 하 는 것' 이 아니 라). 바로 이 '집적 관계' 가 중요 하 다. 바로 유명한 '역방향 포함' (Reverse Contain) 이다.
● Tip 3: 실현 과 사용.
"Architect 또는 Achitecture 엔지니어" 에 대해 서 는 Composite Class 에 member var 가 Children 을 저장 하고 있 으 며, 이 member var 는 Manager 가 아 닌 Container 입 니 다. 즉, 하나의 Child 의 정례 화 작업 Composite 는 상관 하지 않 습 니 다.

class CompositeEquipment : public Equipment {
public:
  virtual ~CompositeEquipment();
  
  virtual Watt Power();
  virtual Currency NetPrice();
  virtual Currency DiscountPrice();
  
  virtual void Add(Equipment*);
  virtual void Remove(Equipment*);
  virtual Iterator* CreateIterator();
  
protected:
  CompositeEquipment(const char*);
private:
  List  _equipment; /////////// note here, a list of children
};

모든 Component 의 정례 화 작업 은 '애플 리 케 이 션 엔지니어' 가 맡 는 다.
MFC 에 서 는 OS 가 유지 하 는 window tree 가 대표 적 이다.
● Tip 4: 장점.Makes the client simple。Client can treat composite structures and individual objects uniformly, 이것 이 바로 추상 적 인 힘 이 고 추상 적 인 노드 Component 가 가 져 온 간단 한 장점 입 니 다.물론 그 중에서 Recursive 알고리즘 의 공헌 도 잊 을 수 없다. Recursive 알고리즘 은 코드 가 짧 고 논리 가 명확 하기 로 유명 하 다.
● Tip 5: 변 화 를 지원 한다.
Makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code. Clients don''t have to be changed for new Component classes.
그림 속 노란색 클 라 스 는 나중에 확 장 된 것 으로 뉴 리 프 를 확장 할 수도 있 고 뉴 컴 포 지 트 를 확장 할 수도 있다.
● Tip 6: 한계.Maximizing the Component interface。
One of the goals of the Composite pattern is to make clients unaware of the specific Leaf or Composite classes they''re using. To attain this goal, the Component class should define as many common operations for Composite and Leaf classes as possible. The Component class usually provides default implementations for these operations, and Leaf and Composite subclasses will override them.
Defining the child management interface at the root of the class hierarchy gives you transparency, because you can treat all components uniformly. It costs you safety, however, because clients may try to do meaningless things like add and remove objects from leaves.
----------------------------------Decorator----------------------------
● Tip 1: 키워드.forward，before forwarding，after forwarding。
● Tip 2: 그림.
● Tip 3: 실현 과 사용.퇴화 된 Composite 입 니 다. 이 점 은 member var 가 하나의 Container 에서 Node Pointer 로 퇴화 하 는 데 나타 납 니 다.

class Decorator : public VisualComponent {
public:
  Decorator(VisualComponent*);

  virtual void Draw();
  virtual void Resize();
  // ...
  
private:
  VisualComponent* _component; /////// note here, a point to leaf or decorator
};

ET + + 에서 CStream...
● Tip 4: 장점.
More flexibility than static inheritance.Furthermore, providing different Decorator classes for a specific Component class lets you mix and match responsibilities. Decorators also make it easy to add a property twice. For example, to give a TextView a double border,단순히 attach two BorderDecorators. Inheriting from a Border class twice is error - prone at best. ● Tip 5: 한계.When the Component class is intrinsically heavyweight, using the Decorator pattern is too costly to apply.
----------------------------------Decorator and Composite----------------------------
●Tip 1：Composite : A decorator can be viewed as a degenerate composite with only one component.
●Tip 2：Decorator is often used with Composite.
When decorators and composites are used together, they will usually have a common parent class. So decorators will have to support the Component interface with operations like Add, Remove, and GetChild.
However, a decorator adds additional responsibilities──it isn''t intended for object aggregation. ----------------------------------Builder and Composite----------------------------
●Tip 1：A Composite is what the builder often builds。
Builder and Composite 는 누구 도 누구의 초 집합 이 아 닌 것 이 분명 하 다.증명: 한편, Composite 는 Component 의 재 귀적 포함 을 제공 하고 Builder 는 제공 하지 않 습 니 다.다른 한편, Builder 는 create 와 assemble 이중 서 비 스 를 제공 하고 Composite 는 assemble 서비스 만 제공한다.
저 는 개인 적 으로 Builder 모델 을 사용 하 는 Composite 모델 은 create 와 assemble 이중 서 비 스 를 제공 하여 'Application 엔지니어' 가 '정례 화 Component' 의 임 무 를 맡 을 필요 가 없다 는 것 을 이해 합 니 다.