Composite Design Patterns

ed Abstract Factory is yet another. When patterns cooperate, the cooperation itself can give rise to problems, contexts, trade-offs, and consequences. For instance, should a Visitor be a part of an Iterator, or vice versa? Or is neither the case? (They could well be one and the same class.) It all depends on the tradeoffs you’re willing to make. Sadly, these issues aren’t discussed much in Design Patterns. Just where should they be discussed? In the VISITOR pattern, in ITERATOR, or both maybe? What about other VISITOR combinations worth documenting—where do they go? Individual patterns are hard-pressed to cover such issues. Indeed, they’re hardpressed to cover their own issues. VISITOR is fourteen pages long as it is, and Jim Coplien, for one, thinks that’s way too long already. What Dirk has dubbed “composite design patterns” may be of considerable help here. Composite design patterns (or simply “composite patterns”) are themselves patterns in that they name and docu...

• Type: Conference
• Year: 1997
• Where: OOPSLA
• Authors: Dirk Riehle
• Keywords: Composite Design Patterns, Composite Patterns, Design Patterns, OOPSLA 1997, Security Privacy