ObjectOriented Design Patterns

1
CSC 335 Object-Oriented Programming and Design
Presentation 7 Object-Oriented Design Patterns
2
Patterns A definition

• A pattern is a solution to a problem in a context
• 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.

3
OOPSLA 96 Alexander PicDoug Lea quote

• "Alexander's central premise, driving over thirty
  years of thoughts, actions, and writings, is
  that there is something fundamentally wrong with
  twentieth century architectural design methods
  and practices. ... Alexander illustrates failures
  in the sensitivity of contemporary methods to the
  actual requirements and conditions surrounding
  their development. He argues that contemporary
  methods fail to generate products that satisfy
  the true requirements placed upon them by
  individuals and society, and fail to meet the
  real demands of real users, and ultimately fail
  in the basic requirement that design and
  engineering improve the human condition."

4
Alexander"Quality without a name" Quote from
Dick Gabriel (Sun Fellow)

• "Its modules and abstractions are not too big. If
  they were too big, their size and inflexibility
  would have created forces that would overgovern
  the overall structure of the software every
  module, function, class, and abstraction is small
  and named so that I know what it is without
  looking at its implementation.
• If I look at any small part of it, I can see what
  is going on, I don't need to refer to other parts
  to understand what something is doing. This tells
  me that the abstractions make sense for
  themselves -- they are whole.
• If I look at any large part in overview, I can
  see what is going on, I don't need to know all
  the details to get it.
• Everything about it seems familiar.
• I can imagine changing it, adding some
  functionality.
• I am not afraid of it, I will remember it."

5
Patterns in the GoF book

• The Gang of Four did not invent the patterns
• They found patterns that already existed in the
  software community 23 from book liner are
  attached
• These are the similarities found in the design of
  software viewed to be of high quality
• They made a rule to list three different systems
  that solved a problem in the same manner
• Thousands of patterns have been documented since
• telecommunications patterns, pedagogical
  patterns, analysis patterns, indexing patterns

6
What a pattern has

• Formats of pattern writers vary, but a pattern
  usually has at least these four things
• A name (Iterator, Stategy, Observer, Composite)
• The purpose of the pattern, the problem it solves
• A guide for how to accomplish the solution
• The constraints and forces to be considered in
  order to accomplish the solution

7
Why Study Patterns?

• Can reuse solutions
• gives us a head start
• avoids the gotchas later (unanticipated things)
• no need to reinvent the wheel
• Establish common terminology
• Design patterns provide a common point of
  reference
• Easier to say, "We need some Strategies here"
• Provide a higher level prospective
• frees us from dealing with the details too early

8
Carpenter's ConversationAdapted from Ralph
Johnson

• How should we build the cabinet drawers?
• Cut straight down into the wood, cut back up 45
  degrees a specific length, then go straight back
  down a specific length, the cut back up at 45
  degrees until you reach, .....

9
A Higher Level Discussion

• A high level discussion could have been
• "Should we use a miter joint or a dovetail
  joint?"
• This is a higher, more abstract level
• Avoids getting bogged down in details
• Which level of detail is more efficient?

10
Consequences of which joint

• Dovetail joints
• are more complex, more expensive to make
• withstands climate conditions dovetail joint
  remains solid as wood contracts and expands
• independent of fastening system
• more pleasing to look at
• Thoughts underneath this question are
• Should we make a beautiful durable joint or a
  cheap and dirty one that lasts until the check
  clears?

11
Consequences

• Carpenters, patterns writers, and software
  developers discuss consequences
• consequences simply refer to cause and effect
• If we do this, what will happen both good and
  bad
• also known as the forces that patterns consider
• Example If we use Mediator to add and drop
  courses
• Add an extra class that needs reference to
  several objects
• All of the logic and process is confined to one
  class so any change to the "rules" would be
  handled there
• Reduces dependencies between others objects
  (simpler design when student does NOT tell the
  scheduled course to change)

12
Other advantages

• Most design patterns make software more
  modifiable, less brittle
• we are using time tested solutions
• Helps increase the understanding of basic
  object-oriented design principles
• encapsulation, inheritance, interfaces,
  polymorphism
• Designs of large systems can avoid large
  inheritance hierarchies (there are alternatives)
• learned the hard way about big inheritance
  hierarchies

13
A few Patterns

• The next slides present a few patterns
• Iterator Pattern that you have seen in 227 or
  127B
• Observer You will use this in your next project
• Strategy which you are use with Layout managers

14
Pattern Iterator

• Name Iterator (a.k.a Enumeration)
• Problem How can you loop over all objects in any
  collection. You dont want to change client code
  when the collection changes. You also want the
  same interface (methods)
• Solutions 1) Have each of your classes implement
  an interface. 2) Have an Iterator interface that
  works with all collections
• Consequences Can change collection class without
  changing code to traverse the collection

15
Java version of Iterator

• interface Iterator
• boolean hasNext()
• Returns true if the iteration has more elements.
• Object next()
• Returns the next element in the iteration

16
Could change to ArrayList to LinkedList

• // The Client code
• List bank new ArrayList()
• bank.add(new BankAccount("one", 0.01) )
• // ...
• bank.add(new BankAccount("nine thousand",
  9000.00))
• String ID ???
• BankAccount searchAcct new BankAccount(ID,
  0.00)
• Iterator i bank.iterator()
• while(i.hasNext())
• BankAccount ref (BankAccount)i.next()
• if(ref.compareTo(searchAcct) 0)
• System.out.println("Found " ref.getID())

17
UML Diagram of Java's Iterator and Collections
ltltinterfacegtgt List iterator()
ltltinterfacegtgt Iterator hasNext() next()
Vector iterator()
LinkedList iterator()
ArrayList iterator()
Iterator hasNext() next()
Context
18
Pattern Strategy

• Name Strategy (a.k.a Policy)
• Problem You want to encapsulate a family of
  algorithms and make them interchangeable.
  Strategy lets the the algorithm vary
  independently from the clients that use it (GoF)
• Solution Create an abstract strategy class (or
  interface) and extend (or implement) it in
  numerous ways. Each subclass defines the same
  method names in different ways

19
Pattern Strategy

• Consequences
• Allows families of algorithms. Known uses
• Layout managers in Java
• Different Poker Strategies in 335 Project Fall
  2000
• Different Pakman chase strategies 335 Fall 2001
• TextField validators in dBase and Borland OWL
• Will use different algorithms to verify if the
  user input is a valid integer, double, string,
  date, yes/no.
• Eliminates conditional statements
• Don't need to keep asking, if this is supposed to
  be an int do this, else if it is a string do that

20
Java Example of Strategy

• this.setLayout(new FlowLayout())
• this.setLayout(new GridLayout())
• In Java, a container contains a layout manager
• There is a default perhaps set in the
  constructor
• You can change a container's layout manager with
  a setLayout message

21
interface LayoutManager

• Java has a java.awt.LayoutManager interface
• Known Implementing Classes
• GridLayout, FlowLayout, ScrollPaneLayout
• Each class implements the following methods
• addLayoutComponent(String name, Component comp)
  
• layoutContainer(Container parent)
• minimumLayoutSize(Container parent)
• preferredLayoutSize(Container parent)
• removeLayoutComponent(Component comp)

22
General UML Diagram of Strategy
ltltinterfacegtgt Strategy AlgorithmInterface
Context strategy Strategy ContextInterface
implements
ConcreteClassA AlgorithmInterface
ConcreteClassB AlgorithmInterface
ConcreteClassC AlgorithmInterface
23
Specific UML Diagram of LayoutManager
ltltinterfacegtgt LayoutManager addLayoutComponent() l
ayoutContainer() minimumLayoutSize()
JPanel panel Panel size Dimension setLayout(lm
LayoutManager) setPreferredSize(diDimension)
implements
GridLayout addLayoutComponent() layoutContainer()
minimumLayoutSize()
FlowLayout addLayoutComponent() layoutContainer()
minimumLayoutSize()
ScrollPaneLayout addLayoutComponent() layoutContai
ner() minimumLayoutSize()
24
Change the stategy at runtime

• Demonstrate LayoutControllerFrame.java
• Source code online and attached
• private class FlowListener implements
  ActionListener
• // There is another ActionListener for
  GridLayout
• public void actionPerformed(ActionEvent evt)
• // Change the layout strategy of the JPanel
• // and tell it to lay itself out
• centerPanel.setLayout(new FlowLayout())
• centerPanel.validate()

25
Observer

• Observer Define a 1 to many relationship so when
  one object changes state, all dependents are
  notified and they update the view themselves.
• You will be able to switch views at runtime or to
  show 2 or more views at the same time
• Java supports this with Observer/Observable
• More on this on next time

26
Examples of Observer

• Example of the Observer Pattern you see often
• Show 3 Explorer windows with 3 different views
• Delete a file in one of the windows
• Show Spreadsheet
• Data is the model
• Charts are the view

27
OOP and UI

• Decoupled UIs
• One model may have several user interfaces
• Web, phone, PDA, GUI on a desktop
• Each UI will hook into the same model
• But allow IO in different ways
• Desired change UI without changing the model
• Desired change the model without changing the UI
• Do not imbed the UI code inside the model
• Keep the two separate