Foundations of Software Engineering Patterns Introduction Component operation

Foundations of Software Engineering Patterns - Introduction Component operation Concrete Component operation() Concrete Dec #1 added. State operation() Decorator operation() component->operation() Concrete Dec #2 added. Behavior() operation() Decorator: : operation() added. Behavior()

What Are Patterns? Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander A pattern is a general solution to a problem in a context • general -- outline of approach only • problem -- a recurring issue • context -- consider the expected design evolution 2

Describing Patterns § Describe design patterns using a consistent format, according to the following template w A uniform structure to the information, making design patterns easier to learn, compare, and use § Pattern name and § Structure classification § Participants § Intent § Collaboration § Also known as … § Consequences § Motivation § Implementation § Applicability § Sample code § Known Uses § Related Patterns 3

Patterns allow us to gain from the experience, and mistakes, of others. § Design for re-use is difficult § Experienced designers: • Rarely start from first principles • Apply a working "handbook" of approaches § Patterns make this experiential knowledge available to all § Support evaluation of alternatives at higher level of abstraction 4

The most important piece of information about a pattern is its intent. § The intent provides the general indication of when a pattern may be appropriate. § Some intentions may be familiar sounding while others are not. Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. 5

Patterns Organized by Purpose and Scope [Go. F] 6

The main classification for Gang-of-Four design patterns is by purpose of the pattern’s intent. § Creational: intent is mainly about creating objects § Structural: intent is mainly about the structural relationship between the objects § Behavioral: intent is mainly about the interactions between the objects 7

A second dimension for classification is binding time. § Using inheritance is compile-time (early) binding or class-based § Using delegation or composition is run-time (late) binding or object-based § Creational • class => defer creation to subclasses • object => defer creation to another object § Structural • class => structure via inheritance • object => structure via composition § Behavioral • class => algorithms/control via inheritance • object => algorithms/control via object groups 8

Patterns Organized by Purpose and Scope [Go. F] 9

Pattern Relationships 10

To apply a pattern you need to, at least, know structure, participants, and collaborations. § Structure • The static class relationships between elements of the pattern. • Note: Go. F structure is not standard UML notation § Participants • Each class/object in the patterns • The responsibilities for each class/object § Collaborations • General description of interactions between participants • Sequence diagram defining interactions 11

The consequences describe the nuances of the pattern usage. § How does the structure support the intent of the pattern? § What are the trade-offs in pattern usage? § Where are the variation points? 12

The implementation details can be language specific. § Pitfalls to avoid when implementing the pattern § Hints and techniques for applying the pattern § Language-specific design choices 13

Describing Design Patterns § How do we describe design patterns? Graphical notations, while important and useful, aren't sufficient. They simply capture the end product of the design process as relationships between classes and objects. § To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it. § Concrete examples are important too, because they help you see the design in action. 14

Composite

Composite Intent Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. (Structural) 16

Composites let you represent the small and big pieces “exactly” the same way. Everything is a Component! Component children Leaf (a) Leaf (b) Leaf (c) Lots of types of elementary leaves which are all components. 17 Composite The composite is a collection of components.

One of your design choices is what should be on the component interface. § Composites deal with children • Child-related operations on the Component interface o What does that mean for a Leaf? • Only on the Composite interface o When are you dealing with a Composite? o Everything is not a Component. § Leaf-specific operations • On the Component interface o Lot’s of leaves large component interface • Only on the Leaf interface o What Leaf are you dealing with? 18

Who should be responsible for deleting child objects when composite is deleted? § You can tell this from the UML notation • Aggregation • Composition § What is the nature of the part-whole relationship? 19

Observer 20

Observer Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. (Behavioral) 21

The Observer pattern allows observers to monitor state changes in a subject object. Did something happen? I’m interested! I did not see anything. The sun was in my eyes. How many spots? I’ll register too. I wish I did not have to keep watching. Me too! I am such a popular Hey, I changed. subject maybe I’ll start I have four spots. tweeting! ØSubject I think I saw it. Sign me up! 22

There are two ways that updates can be done. § Pull • After update, observer queries ("pulls from") subject for information needed. § Push • Subject sends ("pushes") data payload with update 23

Observer Structure Subject Observer observers update() attach(Observer) detach(Observer) notify() for ( o in observers ) { o->update() } Conc. Observer update() Conc. Subject subject my. State get. State() subject. State my. State = subject->get. State() How does Java support this? 24

• Observer Collaborations 25

In some systems with a lot of change activity, you will want to reduce the number of updates. § Subject has large number of state changes. • Allow observer to register for the subset of changes that it cares about. § Subjects have interdependencies for state changes. • Use a Mediator to update observers once all subjects are modified. 26

Iterator 27

Changes to consider § Why do we need iterators? • Don't require clients to do the heavy lifting • Provide clients with special iteration capabilities that the problem requires • Don't just rely on foreach constructs • Merging two ordered collections § Lighten discussion of separate vs embedded iterators § Emphasize internal vs external control with strategy for selection or processing 28

Iterator Intent Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. (Behavioral) 29

What do the Java Collection Framework iterators provide for you? • Function to call to get iterator • Iterator implements a standard interface • Common approach to access elements in the collection 30

Iterator Structure Collection Iterator Client create. Iterator() List Stack 31 first() next() is. Done() current. Item() List. Iterator Stack. Iterator

Iterators are classified along two dimensions. §Iterator is embedded in the collection object Location of iterator §Iterator is a separate class from the collection class Location of iteration control 32 §Control is external to iterator, i. e. iterator client has control §Control is internal to iterator, i. e. iterator has control

One iterator characteristic is the location of the iterator class with respect to the collection class. § The iterator definition can be in a class separate from the collection. • Good separation of concerns: traversal vs. maintenance of collection structure • Multiple traversal types (forward, backward, matching) without unneeded ones • Easier to do multiple traversals at the same time § The iterator definition can be embedded within the collection class. • Preserves encapsulation of collection 33

Who controls iteration when you use the Java Collections Framework iterators? § Consider the Java Collection Framework: Iterator iter = the. Collection. iterator(); while( iter. has. Next() ) { process( iter. next() ); } Internal or external? Embedded or separate? 34

Internal iterators require the client to provide a processing function. § Iterator has a function to perform iteration public interface Internal. Iterator { public boolean iterate(Processor p) ; } § Client requests that the iterator iterate through the collection and process each object public interface Processor { public boolean process(Object o) ; } 35

The client has no iteration control with an internal iterator except to possibly terminate early. public class ACollection. Iterator implements Internal. Iterator { private Some. Collection the. Collection; public ACollection. Iterator(Some. Collection c) { the. Collection = c; } public boolean iterate(Processor p) { boolean result = true; Start at the beginning of the. Collection while ( still elements && result) { if ( ! p. process( next element ) ) { result = false; } Move to the next element } 36 } } return result;

There advantages and disadvantages with external and internal iterators. § External iterators are more flexible • Example: Compare two lists for equality § Internal iterators are easier to use • Iteration logic handled for client 37

Recursive collections, such as Composites, present special problems for iteration. § Does the Java Collections Framework directly support internal or external iteration? § Which form of iterator is easier to implement when traversing a recursive collection like a tree? § Can you do the traversal with the other approach, and if so, what issues arise? 38

It is easier to iterate through a recursive collection with an internal iterator. § External iterator • iterator stores path for retreat (Hansel & Gretel) • composite provides back links for iterator to use (parent / sibling / children ) § Internal iterator • Traverse recursively – get backtrack for free • Get iterator for children of current element • Use null iterators at leaves. 39

Placement of knowledge of how to do traversal involves trade-offs of O-O design principles. § Iterator determines next element • Here iterator needs to know structure of collection • Violates encapsulation of collection if a separate iterator § Collection determines next element • Iterator is just a marker/cursor of where traversal left off • Traversal logic is in the collection even if a separate iterator • Complicates collection itself • Does not separate iteration from collection maintenance 40

Smalltalk Model View Control as a Combination of Go. F Patterns From Go. F Design Patterns Introduction Chapter

MVC User Interface Architecture Pattern § Three kinds of objects • Models: application object(s) • Views: screen presentation(s) • Controls: how to react to user input(s) 42

Decouple Models from Views via Observers Subject 43

Views Can Be Nested: Composite § Example: a control panel of buttons 44

Change the Way a View Responds to Input § View uses an instance of a Controller subclass to implement a particular response strategy • For example, change the way it responds to keyboard input, or have it use a pop-up window instead of command keys Command pattern is also relevant 45

Other Patterns Used § Factory Method to specify the default controller class for a view § Decorator to add scrolling to a view 46