[ Pobierz całość w formacie PDF ]
.The other three reliances field use, state change, and cohesion give rise totheir own design spaces that are in the process of being defined.The method-call design space was explored lightly.Code examples were givenfor many of the EDPs, and you saw how they relate to one another.Finally, youlearned a set of the core EDPs, which define many of the basic concepts that under-lie object-oriented programming.You now have a solid footing to understand the importance and utility of theEDPs and are ready to start learning how to work with them.In Chapter 3, you lllearn a valuable way to graphically depict pattern instances to help you visualizetheir interactions.From the Library of Santiago Itzcoatl Salinas Reyna Pattern Instance Notation3Before we explore the impact of what we can do with Elemental Design Patterns(EDPs), I want to take a bit of a side jaunt and introduce a new graphical notation,the Pattern Instance Notation, or PIN.PIN is used from here out to help you visu-alize some of the concepts we discuss.This chapter provides an informal description of PIN and how it is used inthis book.If you re interested in further information or in how PIN can be used intool support for software design, PIN is fully described in  The Pattern InstanceNotation: A Simple Hierarchical Visual Notation for the Dynamic Visualization andComprehension of Software Patterns [36].3.1 BasicsPIN is a visual representation of the concepts and ideas that comprise patterns.Itis intended as a quick and easy way to document and describe design patterns andtheir interactions.The name PIN was chosen because it also is useful in showinginstances of patterns or concepts in other diagramming notations, such as UML.This was the original use case.45From the Library of Santiago Itzcoatl Salinas Reyna 46Chapter 3: Pattern Instance NotationIn Chapter 2, Section 2.2.2, I mentioned the Participants section of a designpattern specification.Participants are the parts of a design pattern that must existfor an instance of the design pattern to occur.Another name for them are the roles ofthe design pattern, because each participant has a particular role to play in bringingtogether the pattern.In other words, each participant fulfills a role of the pattern.When we say  the participant namedConcreteDecoratorof the Decorator pat-tern, what we really mean is  the class of the implementation that fulfills the Con-creteDecorator role of the Decorator pattern. The roles are abstractions as well,because they provide a name for, and constraints on, the implementation or designfeatures that will act as participants.It s not unlike a play, such as Hamlet.Hamlet is a role, as are Ophelia, Rosen-crantz, and Guildenstern.They describe a part and provide guidelines for the kindof actor who will be cast in each role.The actor is a participant in the stage produc-tion, and all the actors collaborate to form it.The play is analogous to a design pattern, and the particular stage productionis an instance of the pattern.The script is like the design pattern specification: itdescribes roles, and it describes how they communicate and interact.The actorswho are cast in those roles are the participants.UML has a graphical feature, the collaboration element, to describe such situa-tions.An example using Decorator is shown in Figure 3.1.This isn t a bad notationby any means, and it is very flexible, but it suffers from a couple of problems forour needs.For one thing, it is a bit messy in practical use at anything other thanin trivial diagrams.It only adds information to a UML diagram.The more you useit, the more complex the diagram becomes.Abstractions such as design patternsare intended to reduce complexity and detail by letting us operate at a higher levelof abstraction.A sticking point of UML collaborations is that they aren t capableof reducing the complexity in a UML diagram.They can t reduce the amount ofexposed information as a higher level of abstraction should.A collaboration ele-ment also requires a complete UML diagram to be placed in, in the first place.Thismay seem like an odd complaint when we re discussing a UML feature, but it turnsout that there are plenty of situations where we may want to discuss how patternsinteract without having to create a diagram for all the pieces necessary to implementthem.Another common notation for design patterns is the pattern:role notation intro-duced by the Gang of Four (GoF) [21].It is also an annotation to be used on topof UML, and it uses an external flag that is named with the pattern and the role.This annotation can be applied to a class, package, field, or method as needed, asshown in Figure 3.2.It s very flexible and obvious, but it isn t without issues.From the Library of Santiago Itzcoatl Salinas Reyna ConcreteComponentComponentWindowdraw()DecoratorDecoratorwindowOperationConcreteSimpleWindow DecoratedWindowDecoratordraw() draw()window.draw()TintedDecorator ScrollBarDecoratorDecoratedWindow::draw();draw()draw()drawScrollBar();drawScrollBar()Figure 3.1 UML collaboration diagram.From the Library of Santiago Itzcoatl Salinas Reyna3.1Basics47 48Chapter 3: Pattern Instance NotationPhysicalObjectStrategy:Strategyalgorithm()AlgorithmA AlgorithmB AlgorithmCalgorithm() algorithm() algorithm()Strategy:ConcreteStrategy Strategy:ConcreteStrategy Strategy:ConcreteStrategyFigure 3.2 Strategy as pattern:role tags in UML.Figure 3.3 Huge UML of a not-so-huge system.This approach isn t so bad when only one pattern is involved and displayed,but what happens when you have a pattern hidden in a diagram with hundreds oreven thousands of pieces? Say, something like in Figure 3.3?Figure 3.3 is an actual UML diagram from an actual project.It s unreadable atthis scale, but practically speaking, it s almost unreadable at any scale.If you wereto print it at actual dimensions, such that the type was 10-point size, it would be 86by 32 feet.That s a lot of paper: 3,290 standard U.S.letter-size sheets.At this size,it s too small to be read, but at the full size, it s too large to be searched visually.Frustratingly, a wealth of patterns are recorded in the diagram, ready to be foundand learned from to help document the system.As a more concrete example, consider a UML diagram such as in Figure 3.4.There are two instances of the Strategy pattern in Figure 3.4, but using the pat-tern:role notation, we can t tell which pieces go with which pattern instance, evenin this small example.From the Library of Santiago Itzcoatl Salinas Reyna 493 [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • funlifepok.htw.pl

    •