Design Patterns Introduced

CSE 115 Summer Session

Design Patterns
Library
Catalog of commonly used classes and methods concrete Catalog of commonly interactions between objects that developers have often found useful Theoretical/abstract Describe how objects communicate without complications of each others data models or methods

Design Pattern

Using Design Patterns

Reduce a particular problem to another with a well known solution
Mathematics tie in Sticky buns like dinner rolls except <blah>

Meta abstractions beyond classes and instances When possible start with interface not implementation
More important for larger systems

Has-a over isa-a

Hard Coding
Hard Coding
the use of an explicit value in the code or method of your program. this is hard coding 6, 3.14159 Generally considered poor programming
Debugging?

Get around with constants, parameters etc Some of you in lab 6 hard coding size, location etc

(simple) Factory Pattern

Returns an instance/object of one of several possible classes depending on the data provided
Usually param

Usually one of several subclasses of a common superclass. Decision on what to return (method details) could be simple or complex

Factory Pattern II
Basically:
Create abstraction that decides which of several possible classes to return and does so (factory) Caller gets an object back
with methods in common with all other possible classes,

Calls methods without ever knowing exactly what subclass it uses

Factory Method Pattern

Subtle extension of basic Factory Pattern
Not single class deciding what objects to make (subclass to instantiate) Superclass defers decision to sub-classes Using this pattern,
Define abstract class which creates objects Subclass decides what they are (what subclass of another abstract class

Recognition :Factory Method

When should you use Factory Method Pattern?
If a class can't anticipate what kind of objects it will need to create If a class specifies what objects it creates through its subclasses If you want to localize (hide details from user/other programmers) the knowledge of which class gets created

Abstract Factory Pattern

One level of abstraction above previous Return one of several related classes of objects
Each of which can return different objects on request

Pluggable look and feel example Garden example

UML

Abstract Factory
Implementation
Abstract base class (or better yet interface) Concrete subclass to implements interface And returns instances of subclasses of another base class. Where have we seen something like this before in this class? If we need to add more types then we can just create more classes that implement the interface and the rest of the code need not know the difference

Abstract Factory
Benefit
Isolates the concrete classes generated Actual names of classes are hidden at client level Because of this you can change (or switch among) different classes in the family (subclasses the same superclass) createButtons

The Singleton
Sometimes there should only be one instance of a particular class
Book: data base access, etc Also hardware mouse pointer etc

Must ensure that there is only one instance Single instance of class has to be globally accessible

OO Programs
Logic for program often divided into isolated, but communicating classes. When program gets large, and many classes, communication and interconnection gets complex Reduce this with a mediator between classes

Mediator Pattern
One objects encapsulates how the various objects of the program interact
Other objects need not know the nature or number of objects in the program they become loosely coupled.

Mediator Motivation
Dividing a program into objects generally increases re usability
But heavy interconnection between objects reduces re usability again. Lots of interconnections means an object is less likely to work without those other objects

Summary
Design Patterns:
Schema of common solutions to programming problems

Factory Singleton Mediator