An Introduction to Design Patterns Brian Ordona

Programming: Constantly Searching for the Holy Grail  “There’s got to be a better way to do this!”  The Mythical Man Month: F. Brooks – “No silver bullet,” but sees hope in Object Oriented Programming (OOP).

Object-Oriented Programming: Purpose  Provide a software solution to a defined problem through the simulation of real objects.  An example: Simulation of U.S. Senate decision making.  OK, you’ve created your objects, now what?!

Design Patterns: Purpose  Serves as an extension to OOP methodologies and techniques.  Essence: to organize code into logical constructs that attempt to achieve the following goals: 1.To complement OOP in facilitating the process of true simulation: OOP techniques dictate which objects will interact; Design patterns dictate how objects will interact (with each other and with real life). 2.To benefit to the programmer:  Better organization of code.  Facilitates the creation of reusable components.

The Design Patterns  Name  Primary Purpose  Simple (Theoretical) Example  Case Study (Practical) Example  Implementation: Main Features  3 or 4 patterns will be discussed: Singleton, Template Method, Façade, Mediator.

Case Studies  CS 631X (Software Design Methodologies) final project: Blackjack Simulator.  CS 615/616: Ear Training Application

Singleton  Purpose: Ensure that one and only one instance of a class is in use.  Example: Senate simulation – only one Vice President.  Case Study: The Card Deck object.  Implementation:  Constructor is private.  Contains a static reference to itself.  A single point of access to the Singleton object.

Template Method  Purpose: Defines a process, but gives control of each individual step to the programmer.  Example: A sorting application. public void SimpleSort() { receiveInput(); sortInput(); productOutput(); }

Template Method (cont.)  Case Study: An actual round of Blackjack.  Implementation:  The overall process is defined within the actual template method itself.  Define as abstract those methods where the programmer may want (or need) to provide custom implementation.

Template Method: Class Diagram

Facade  Purpose: Pools together the resources of a subsystem of classes in order to provide higher level functionality to a client class.  Example: A compiler.  Case Study: The “Virtual Pit Boss.”  Implementation:  The Façade calls methods on subsystem classes.  A client class calls methods on the Façade.  Loose coupling: distinct subsystem classes do not refer to each other.

Façade: BlackjackSession

Dealing a Card  NO! class Dealer { public Card deal() //Deal directly to player, NO! { player.addCard(Card); }  YES class BlackjackSession { public void play() //Façade calls methods on player and dealer. { Card dealtCard = dealer.deal(); player.addCard(dealtCard); }

Mediator  Purpose: Like the Façade, it controls the interaction between classes within a subsystem.  Difference: Façade = one-way communication, Mediator = two-way communication.  Case Study: GUI refresh methods within the Ear Training Application.  Implementation:  Loose coupling: distinct subsystem classes do not “confer” with each other, only with the Mediator.

Mediator: UPitchGUI2

Conclusion  Guaranteed, you have used design patterns even without knowing it.  Design patterns are born out of intuitive solutions to software problems: Pattern = Reoccurring Solutions that have been proven to work through experience.  The “discipline” of design patterns attempts to formalize these intuitive solutions into a methodology.