.Open Patterns and Principles
. Good Links on Patterns
A good list, overview and, discussion of patterns
can be found at
.See http://c2.com/cgi/wiki?CategoryPattern
on the WikiWikiWeb.

Another source of pattern information is
.See http://www.dofactory.com/Patterns/Patterns.aspx
but this is biased towards C# and is an advert for $2,000 courses.

Here is a nice resource
.See http://home.earthlink.net/~huston2/dp/
and visual
.See http://home.earthlink.net/~huston2/dp/patterns.html
provided by Vince Huston.  Here is a quiz
.See http://home.earthlink.net/~huston2/dp/patterns_quiz.html

The Wikipedia
.See http://en.wikipedia.org/wiki/
also documents many (if not all) patterns
.See http://en.wikipedia.org/wiki/Category:Software_design_patterns
here.

. GRASP -- General Responsibility Assignment Software Patterns
From Craig Larman
.See ../cs375/text.html

Expert::=`allocate a responsibility to a class that has the information`. Look
in both the design classes and the domain model to find a type of object 
that knows enough to handle the responsibility.  Knowledge includes
having the data, and also knowing who has got the data!

Creator::=`creating an object should be the responsibility of a class that is closely related to the created object`.  Notice that you always need at least
one way of creating an object that doesn't depend on already having an object
of that type already.  So which class or object is closs enough 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`.
.See MVC
(Model-View-Controller).

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
.See 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`.
.List
 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,...
.Close.List
. GoF Patterns
GoF::="The Gang of Four".... see $GoF_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. 
GoF_book::=following,
.See [Gammaetal94]
, note -- uses a pre-UML notation.

.Key Links on the Gang of Four patterns.
THe Wikipedia has articles of varying quality on the $GoF patterns.
Here
.See http://pw.tech-arts.co.jp/download/design_pattern/
are some quite good UML diagrams but I'm not sure of the descriptions.
And the WikiWikiWeb
.See http://c2.com/cgi/wiki?DesignPatterns
discusses them all -- but is short of diagrams (if you like diagrams).
More links:
.Hole

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.
.See http://c2.com/cgi/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.
.See http://c2.com/cgi/wiki?AdapterPattern
.See http://www.dofactory.com/Patterns/PatternAdapter.aspx
.See ./fig25_25_1.cpp
.See ./test.fig25_25_1.cpp
(From Larman05)

Bridge::$GoF=`A class of objects that acts as an interface between clients and an implementation`.
Unlike an $Adapter the bridge connects to a family of objects with the same operations.
.See http://c2.com/cgi/wiki?BridgePattern
.See http://pw.tech-arts.co.jp/download/design_pattern/images/bridge_s.jpg
.See http://en.wikipedia.org/wiki/Bridge_pattern

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`. 
.See http://c2.com/cgi/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.
.See http://c2.com/cgi/wiki?CompositePattern
.See http://www.dofactory.com/Patterns/PatternComposite.aspx

Decorator::$GoF=`A class can take an object and wrap new functions around it`.
.See http://www/dick/cs375/decorator.gif
.See http://www/dick/cs375/TestDecorator.java
.See http://c2.com/cgi/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.
.See http://c2.com/cgi/wiki?FacadePattern
.See http://www.dofactory.com/Patterns/PatternFacade.aspx
.See http://en.wikipedia.org/wiki/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.
.See http://www/dick/cs375/Observer.gif
(Class diagram)
.See http://www/dick/cs375/observer.png
(sequence diagram)
.See http://c2.com/cgi/wiki?ObserverPattern
.See http://www.dofactory.com/Patterns/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.
.See http://www/dick/cs375/proxy.gif
.See http://c2.com/cgi/wiki?ProxyPattern

Singleton::$GoF=`To make sure that there is precisely one object in a class and provide access to it`.
.See http://c2.com/cgi/wiki?SingletonPattern
.See http://www.dofactory.com/Patterns/PatternSingleton.aspx
.See ./singleton.cpp
.See ./test.singleton.cpp

Strategy::$GoF=Place different ways to do something behind a common interface and use indirection via an object to pick the right one.
.See http://www/dick/cs375/Strategy.gif
.See http://c2.com/cgi/wiki?StrategyPattern
.See http://www.dofactory.com/Patterns/PatternStrategy.aspx?

State::$GoF=`When an object changes behaviors (responsibilities) with time, place the state in a different State object and place the different behaviors in special kinds of State object`. 
Note: in most programming language can not change its class!  Also
note that an efficient State implementation can use $Singleton for
the states.
.See http://c2.com/cgi/wiki?StatePattern
(on the WikiWikiWeb).  Examples:
.See ./StatePatternExample.html
.See ./test.State.cpp
.See ./State.cpp
(using lazy $Singleton and a "call back")
OR
.See ./State2.cpp
(using eager $Singleton, breaking $CQS principle, and hiding the initial state)
.See ./test.State2.cpp
, Exercise: redraw the UML diagram to show the changed classes between
State and State2.

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`.
.See http://c2.com/cgi/wiki?TemplateMethodPattern
This result is also called a `Framework`.

Flyweight::$GoF=`when you have lots of small similar objects keep exemplas ina data structure and point to those for the details`.
.See http://c2.com/cgi/wiki?FlyweightPattern
.See http://en.wikipedia.org/wiki/Flyweight_pattern
Classic example: characters in wordprocessing.  Used for $State and $Strategy.  Used with $Composite.

. Analysis Patterns
.Open Bolloju04
 Narasimha Bolloju
 Improving  the quality of business object models using Collaboration patterns
 Commun ACM V47n7(Jul 2004)pp81-86
.See  http://doi.acm.org/10.1145/1005817.1005827
 =EXPERIMENT MODEL REALITIES PATTERN UML COMPOSITION
 Based on Coad and Fowler lists 12 simple patters that helped students improve their conceptual models in 13 different business application domains: spotting classes and connections, plus correcting errors.

.Image 19Bolloju04.gif (Figure 1 is in ASCII below)
 Collaboration_patterns::#Pattern=following,
.Set
 E1: Role (1)-(0..*) Transaction
 E6: Transaction (1)-(0..*) FollowupTransaction 
 E5: Specification (1)-(0..*) Transaction
 E3: CompositeTransaction (1)<*>-(0..*) LineItem
 E2: Place (1)-(0..*) Transaction
 R: Actor (1)-(0..*) Role
 T1: Item (1)-(0..*) SpecificItem
 T4: Group (1)<>-(0..*) Member
 E4: SpecificItem (1)-(0..*) Transaction
 T2: Assembly(1)<*>-(0..*) Part
 P: OuterPlace (1)-(0..*) Place
 T3: Container (1)<*>-(0..*) Content
.Close.Set
 Next
.See [BollojuLeung06]
.Close

. Domain Model Patterns
.See [Wagner05]
.See ./domainPatterns.png

. 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. 
.Set
atomic::=`a transaction either completes or does nothing.` -- no interrupts.
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`.
.Close.Set

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 
.Key Aim high
-- allow your pointers to refer to abstractions
and then they can point to many special kinds of object.
For example(in C++):
.List
 Declare variable abstract and assign address of concrete:
.As_is 		List * example = new SpecialKindOfList(....);
.As_is 		Person * dick = new Faculty(....);

 Declare parameters as refs to abstractions
.As_is 		void zark(List &w){....}
 Declare containers as containing pointers to abstractions:
.As_is 		map<string, Person*> people;
.As_is 		people.insert(string("Dick"), dick);
.Close.List

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
.Set
 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.
.Close.Set

CQS::=Command_Query_Separation,
Command_Query_Separation::principle=`Operations should either do something and return nothing or return something and do nothing, NOT both`,
.List
 void doSomething(data);// nothing returned
 Type getSomething(data);//leaves everything the same.
.Close.List
This dates back to the the theory of abstract data types and was
inherited 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 principle 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
occasional pleasant surprises:  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.

Model_View_controller::pattern=$MVC.
.See http://www.pns.anl.gov/images/sciandproj/isaw/mvc.gif
MVC::pattern="Model-View-Controller", 
.Set
This patterns suggests separating
the logic of the data (Model) from the code that interfaces with the user
(View+Controler).
 Separate Model (data + ...) from View(what the user sees...) from Control (what the user can do...).
.See ./MVCinUML.gif
(UML diagram of View, Controller and Model packages)
 In some methods yo split Boundary, Control and Entity objects.
And use special icons for them:
.See ./icons.gif
(Graphic showing common icons and stereotypes).

The code that describes user interfaces is independent of the code
for the logic of an enterprise or application.  The appearance of
the user interface for a pay-roll should be separated from the
rules for calculating your with-holdings.
Neither should the choice of the user interface framework change
the calculations.  So the wise designer splits all the
user interface code into specialized classes that communicate
with the application specific classes.  This is splitting
the users "View" from the logical "Model".  
As a result the "Model" classes can reflect the Domain or Business
model and so are easier to understand and get right... and keep right.

As a result you can change the View (add a new one, rip out the AWT and
put in Swing, ...) without worrying about the payroll logic.

Here is a paper
.See http://doi.acm.org/10.1145/1121341.1121453
that has a set of Java programs that access a time server and show the
user the time of day found on that server.  One program has a command line
interface, one has a menu driven ASCII interface and one a GUI interface,
but they share a common "model" of how to access the time server.  This
class never changes... each interface is implemented as a new class that
uses the model:

.Image VMSeparation.gif View -> Model

The diagrams in the paper are not correct UML, do not use them!

In general, there are lots of classes defining the user interface and
many classes in the Model.  In the UML use packages to contain them.

More strictly the user interface code is split into two sets of classes.
The View and the Controler.  Typically the user communicates with controlers
that change the model.  The view classes get data from the model
and are responsible for rendering it to the user.
.As_is 		User ---> Controler ----> Model -----> View -----> User

 Also see
.See http://en.wikipedia.org/wiki/Model-view-controller
for the history and a list of frameworks that use MVC.

.Close.Set
FURPS+ ::requirements={Functional, Usability, reliability, Performance, supportability, Implementation, 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, techniques, etc. and
describe what and how we might construct the software -- the decisions
we make: eg.-- use VB and MySQL.
.Close.Net

The_Hollywood_Principle::pattern="Don't call us, we will call you",  This is an implementation
pattern for code to interact with a framwork or operating system.  Instead of the program calling
the operating system when it needs to something, it waits to be called by the environment when events
happen. Detail at
.See http://en.wikipedia.org/wiki/Hollywood_Principle
on the Wikipedia.

.Open AntiPatterns -- Patterns that occur but don't resolve the forces well
. The Ball of Mud Pattern
You should read and study this an excellent, short, and readable
blog entry
.See http://www.codinghorror.com/blog/archives/001003.html
describing the ways in which system and software architecture goes astray
and ultimately becomes unmanageable.
.Close
.Close Patterns and Principles