Good Links on Patterns
A good list, overview and, discussion of patterns
can be found at
[ wiki?CategoryPattern ]
on the WikiWikiWeb.
Another source of pattern information is
[ Patterns.aspx ]
but this is biased towards C# and is an advert for $2,000 courses.
Here is a nice resource
[ http://home.earthlink.net/~huston2/dp/ ]
and visual
[ patterns.html ]
provided by Vince Huston. Here is a quiz
[ patterns_quiz.html ]
The Wikipedia
[ http://en.wikipedia.org/wiki/ ]
also documents many (if not all) patterns
[ Category:Software_design_patterns ]
here.
GRASP -- General Responsibility Assignment Software Patterns
From Craig Larman
[ ../cs375/text.html ]
- Expert::=allocate a responsibility to a class that has the information.
- Creator::=creating an object should be the responsibility of a class that is closely related to the created object. Or else you can use a GoF Factory -- a
Pure_Fabrication.
- Low_coupling::=Assign a responsibilities so that class depends less on other classes using a "need to know basis". Organize responsibilities so that classes do not depend on each other two much.
- High_cohesion::=Design elements to have strongly related and focused responsibilities".
- Controller::=Assign the responsibility for handling system event messages to a class representing either the whole system, device, or subsystem, or representing the use case /scenario within which the system event occurs.
[ MVC ]
(Model-View-Controler).
- Polymorphism::=Give the same name to services in different objects when the services are similar or related. Classify objects, using inheritance/generalization, to allow the right version of a service to be executes for the object in question. Example
[ Strategy ]
in the GOF patterns below.
- Pure_Fabrication::=assigning a highly cohesive set of responsibilities to an artificial convenience class that doesn't represent a problem domain concept.
- Indirection::=Assign a responsibility to a class that knows where to find an object that can complete the task, Avoid coupling by an intermediate (smart?) object. You can have indirect access to an abstraction without knowing
the precise concrete implementation of the abstraction: You can call
all your Pets in the same way.... and the Dogs come to you, and the Cats
think about it, for example.
- PV::=Protected_variation.
- Protected_Variation::=Identify points of predicted variation or instability and assign responsibilities to create a stable interface around them.
- Parnas: Separate your design decisions into separate modules. See Parnas.
- SDM: Separate physical from logical structures in separate processes.
- GoF: Template_Method, Facade, Proxy, Adapter,...
GoF Patterns
- GoF::="The Gang of Four".... see book and
- The_Gang_of_Four::abbreviation={Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides}, Four OO thinkers who wrote an influential book of design patterns.
[Gammaetal94]
Many GoF combine two or more GRASP patterns. For example State
is a Pure_Fabrication that uses Indirection to protect
a class from state changes (PV).
- Abstract_factory::GoF=Design a common interface for creating families of similarly or related objects. See Factory.
[ wiki?AbstractFactoryPattern ]
- Adapter::GoF=Introduce a class to convert the interface of one component into another interface. Think plugs and sockets. make one interface for one or more suppliers.
Unlike Proxy, an adapter converts different interfaces into one common one.
[ wiki?AdapterPattern ]
[ PatternAdapter.aspx ]
- Command::GoF=Design objects that know how to do (and undo) a family of tasks and pass them to other objects to be used as needed.
[ wiki?CommandPattern ]
- Composite::GoF=Make complex and simple kinds of an object share behavior. And often the complex objects keep a list of their parts: each of which is a similar kind of object.
[ wiki?CompositePattern ]
[ PatternComposite.aspx ]
- Decorator::GoF=A class can take an object and wrap new functions around it.
[ decorator.gif ]
[ TestDecorator.java ]
[ wiki?DecoratorPattern ]
- Wrapper::=Decorator.
- Facade::GoF=A class or object provides a single point of entry for services of a subsystem, Hide a complex system of objects behind a single object. Pay no attention to the man behind the curtain.
[ wiki?FacadePattern ]
[ PatternFacade.aspx ]
[ Facade_pattern ]
- Factory::=an object/operation/class is designed solely to create other kinds of object.
See Abstract_factory and FactoryMethod.
A factory is an alternative to a constructor in a class. Because it
is a member of a different class (the factory) we can get objects without
having to know precisely what class they are instances of. Other
patterns need the ability to create concrete implementations of
an abstraction -- but without knowing which implementation has been
chosen.
- Observer::GoF=An object that implements the operations that let it subscribe to learn about other objects.
Objects that need to see what an object is doing can join a collection
maintained by the observed object. These are subscribers. The observed
object publishes the changes to the subscribers using one or more special
operations that a listed in an interface that the observers all implement.
It is also possible for an object to subscribe other objects as observers.
[ Observer.gif ]
[ wiki?ObserverPattern ]
[ PatternObserver.aspx ]
- Proxy::GoF=Design an object that can stand in for other objects and knows which object it is representing and how to simulate it. As a result we can change the real object with out breaking the client.
[ proxy.gif ]
[ wiki?ProxyPattern ]
- Singleton::GoF=To make sure that there is precisely one object in a class and provide access to it.
[ wiki?SingletonPattern ]
[ PatternSingleton.aspx ]
- Strategy::GoF=Place different ways to do something behind a common interface and use indirection via an object to pick the right one.
[ Strategy.gif ]
[ wiki?StrategyPattern ]
[ PatternStrategy.aspx? ]
- State::GoF=When an object changes behaviors (responsibilities) with time place the state in a different object and the behaviors is special kinds of that object. Note: in most programming language can not change its class!
[ wiki?StatePattern ]
- Template_Method::GoF=A method in a class can use abstract operations (hooks) that are defined in a subclass so that the subclass provides some functionality while using the overall method.
The classic example is a method that sorts a vector of data in a Sortable class
but uses an undefined "less_than" operation. Other classes extend the Sortable and define "less_than" and can then sort the data Their way, right away.
[ wiki?TemplateMethodPattern ]
This result is also called a Framework.
XP Principles
- DRY::=Don't repeat yourself.
- YAGNI::=You Aint' Gonna Need It. When in doubt leave it out! Keep It Simple,
Stupid!
Persistence Principles
- tables::=All data can be expressed by a collection of simple tables.
- Persistence_as_a_superclass::=`Put all the persistence code into a superclass
and then any class can become persistent by inheriting from the persistence class`.
Notice that this can get clumsy and in Java foul up more important extensions.
- ACID::principle="Atomic, Consistent, Isolated, and Durable".
Jim Gray's ACID principles of Data Base transactions.
- atomic::=a transaction either completes or does nothing. -- no interupts.
- consistent::=a transaction never leaves the data in a state that breaks the rules. A marriage has two people: no more, no less.
- isolated::=The effect of a transaction is hidden from other transactions until it is complete.
- durable::=A transaction, once completed, is never lost -- even if things break down or fail.
- database_mapper::=The class of the object determines what data needs to be stored so define objects for each class to handle the tables.
- cache_management::=Databases should manage their own caches.
- hide_SQL::=Put all the SQL in one object -- a singleton -- and keep it separate from the rest of the code. Treats SQL as an external entity with its own secrets.
See Parnas.
Exception Principles
- Convert_exceptions::=If you can not handle an exception then convert it to a higher level exception.
- Name_the_problem_not_the_thrower::=name exceptions to indicate what is wrong not where it came from.
- centralize_error_logging::pattern. Have a single object that is responsible for recording bad things.
- standard_error_dialog::pattern. Have a standard user interface for reporting and sorting out errors.
OO Principles
- OO::=Object Oriented Principles, including abstraction, extension, polymorphism, etc.
- OID::=Objects should know their own identity... and this can be expressed as a simple data item and stored in data tables, and hidden from the user.
- abstraction::OO=Variables and parameters should be declared as reference or pointers to abstract data types whenever possible, and containers as holding pointers to abstractions.
Also known as
Aim high
-- allow your pointers to refer to abstractions
and then they can point to many special kinds of object.
For example(in C++):
- Declare variable abstract and assign adrees of concrete:
List * example = new SpecialKindOfList(....);
Person * dick = new Faculty(....);
- Declare parameters as refs to abstractions
void zark(List &w){....}
- Declare containers as containing pointers to abstractions:
map<string, Person*> people;
people.insert(string("Dick"), dick);
- extension::OO=Extend classes rather than reinventing the wheel.
- polymorphism::OO=let objects sweat the details for you. See
GRASP Polymorphism
Other Principles
- Parnas::=place different decisions in different modules, for example
- 1971: Put input, output, and logic in separate modules that communicate by function calls.
- Separate the physical from the logical.
- Hide a data structure inside an Abstract Data Type.
- Hide an algorithm behind a Strategy.
- Hide external systems behind a Facade.
- Hide libraries behind a Facade or an Adapter.
- Hide SQL inside a package or object (hide_SQL).
- Hide the User inside a User_interface (UI) Package.
- Separate particular Applications from Business Logic and Domain.
- Separate Model, View, and Controller. See MVC
- Hide a RDBMS behind a simple OO persistence layer.
- CQS::=Command_Query_Separation,
- Command_Query_Separation::principle=Operations chould either do something and return nothing or return something and do nothing, NOT both,
- void doSomething(data);// nothing returned
- Type getSomething(data);//leaves everything the same.
This dates back to the the theory of abstract data types and was
inheritted by Meyer into objected oriented coding style.
This principle leads to code that is slightly more verbose
but very much clearer. It also reduces bugs by the pricple of
Least_Surprise.
- Least_Surprise::principle=`Whenever you design anything choose a design that
minimizes the surprises that the user may experience`.
Henry Ledgard proposed this for programming languages but it
also applies to user interfaces, common appliances, and object-oriented
classes. Apple had a tendency to extend so that the user experiences
occassional pleasant surprizes: the user does the wrong thing
and the system does the right thing. This is also called
- DWIM::="Do What I Mean".
This is a dangerous philosophy because it back fires.
- MVC::pattern="Model-View-Controller",
- Separate Model (data + ...) from View(what the user sees...) from Control (what the user can do...).
[ MVCinUML.gif ]
(UML diagram of a View, Controller and Model packages)
- Split Boundary, Control and Entity objects.
[ icons.gif ]
(Graphic showing common icons and stereotypes).
- FURPS+::requirements={Functional, Usability, reliability, Performanc, supportability, Implimentation, Interface, Operations, Packaging, Legal},
Grady92.
- KISS::=Keep It Simple, Stupid, see XP.YAGNI.
- PQRST::requirements={Purposes, Qualities, Realities, Systems, Techie}, from RJB.
Net
- Purposes include functions and use cases and define why someone
wants the software. To help us sell items to customers.
- Qualities are the needed properties of the software
like security and performance criteria.
- Realities are domain models. We have the problem of integrating different
views of the the real world
- Systems are the existing systems that we are replacing, using, modifying,
and even competing with.
- Techie include technologies, techniqes, etc. and
describe what and how we might construct the software -- the decisions
we make: eg-- use VB and MySQL.
(End of Net)
