THe idea of MVC is that each function as seen be the user is spread out over all three
types of classes. Any function has a View, a designated controller, and one or more
Internally I think that real systems need a Technical Services layer underneath the Model
of MVC. There are some things a software system must do (highly technical things) that are
not what the user wishes to see(V), control(C), or understand(M).
The list in the front cover puts the ones used most often first. They are all important
for some problems.
I think that Polymorphism is the one that people who don't get objects have the most problem
with. But Coupling and Cohesion are a little too abstract to understand -- you have to have
worked for a month or two inside a humongous design to really get a feel for these ideas.
Because a pattern is deduced from pre-existing examples. If there
are no examples then it is not a pattern. And Patterns tend not to evolve.
When documented and published they tend to distort reality to fit. SO they
don't change once promulgated.
This is a common mistake made people who a new to object-oriented design.
We have some names for these large low cohesion classes: "The God Class",
"A Mudball class".
Do this and your code will be unmaintainable very quickly.
Make your self some templates so you can make the code for a class quickly.
It is not a matter of size but whether things belong together, in some
sense or other: do all the methods need the same data? Is all the
data needed by several methods/operations?
You shouldn't have to cycle through either the GRASP or the GoF patterns.
You need to describe the current problem in terms of responsibilities
and let that remind you of a suitable pattern:
By the way -- it is quite OK to come with the designs intuitively
and then label them "Controller", "Creator", "Expert", ...
Larman has listed them in decreasing frequency of use and popularity.
But they are in the list because they are in use in many projects already.
is probably used more often than any other -- even by poeple who
don't know it by name. The close runner up is
because most scenarios will lead to creating new objects and we
have to choose where this creating/construction is invoked.
are the two of the oldest patterns. But they
are less useful because they are tools for evaluating a design rather than
coming up with one.
is very common but a bit controversial.
I hope it can be more than a learning aid. I think they will
guide you to good solutions -- even if used silently.
To be useful to a team,
however, the GRASP patterns have to be a shared language. At this
time I don't know what the odds are of this happening. For example
I can see a tom of ASP and .js files on the WWW so I know that
a lot of teams use these languages/technologies. However GRASP
doesn't leave such obvious traces to a user.
I did find over 1,000 pages referring to "Larman GRASP" but not much recent
activity on usenet/google groups. I figure that quite a few
current grads are likely to "talk GRASP".
Hmmmm this would be an interesting bit of research for a senior or
graduate student: what patterns are actually used in practice.
GRASP dates back to the first edition of the text book -- late 1990s I guess.
What tends to happen is that people use it without making any fuss when they
are doing OO design. The 9 patterns do no more than name the way most
good designers thought. This means I can use them to teach good OO design.
However you don't see students and staff taking the time and trouble to note
that the allocated a responsibility using Information Expert, or
choose a session controller.... it is just obvious....
On camus there is a lot of non-OO work being done. A lot of simple scripting
at the high level. But even here some of the priciples still apply. Low
coupling is still good, and high cohesion is still good.
I do see student work that is not well designed.
One thing I have seen too much of in student projects is having SQL scattered all over
the code rather than hidden in a Technical Services class.... These are students
who don't do CS375, I'm glad to say.
It will depend on the platform you are using. Once upon a time we tweeaked the
loudspeaker to generate tomes.... nowadays you send a message to an object in the GUI
interface, I guess.
Time to research the particular platform: hit the books and google.
Your system has to do something -- which part should be responsible? Answer the
part that has the data (or can find the data) that is needed to carry out the task.
The alternative: mudball designs and the kind of code that your colleagues will
make fun of and hate you for.
Problem: when there are several possible experts... (which may, perhaps, hint
at lack of cohesion?).
Controllers are classes and so are inside packages/layers. System operations are
messages and flow between classes and so can cross layer boundaries.
When the team is scared to change some parts of the software because it might break the system
then you probably have too much coupling.
When any change you make involves a dozen classes being modified then you have too much coupling.
However -- some changes -- called "cross-cutting concerns" do effect almost every part of
a piece of software even if the coupling is low enough. It take some special design techniques
to handle these aspects that effect everything (like security, persistence, language, ...).
Note: in this class project is running very slowly, like a slowed down
movie. I haven't got lab time for you to implement the designs:-(
However -- I'd love to see a project group demo some code....
I coded up the Dice game in week 1. Diagrams on page 10 and code
[ DiceGame.cpp ]
[ Die.cpp ]
[ testDiceGame.cpp ]
[ testDie.cpp ]
Here is the code for last class's quiz:
[ SalesItem.java ]
[ SalesOrder.java ]
[ Stock.java ]
There is some code coming the book. Several pages of it.
You can start coding your project
any time you've got an interaction design. I invite all project teams to
write code to
test their design classes and interaction diagrams by coding and demoing them.
I've laid down this challenge each year... and nobody wants to do it:-(
If we get time... and people pick an interaction I'll do some test driven
C++ coding in class. Should be fun. Do the design right, and if you know
the languages -- coding is easy. It also helps if you have some
blank "template" files like
[ testName.cpp ]
[ class.cpp ]
[ function.cpp ]
[ attribute.cpp ]
ready to go.
If we had a unit of lab added to thhis class (2 hours) then I'd be
expecting you to code something from about week 3 onward. It is
however the easy part of the unified process -- given that you made sure
you were competent in the Inception phase.
This is when the internal structure of the software closely reflects
the structure of the doamin that the software is designed to fit.
No. GRASP has been out for about 5 years so management and hirers
haven't heard of it yet.
But they will have heard of patterns and the more complex and
technical "Gang of Four" patterns (GoF).
Yes. Click here: GRASP
Not often. It tends to be a generic and popular name for a way to resolve a number
of conflicting forces -- a family of simialr problems.
GRASP is used to guide design. Design starts in the very first iteration and may occur
in the last.... See the pictures linked at end of
No. The supplement it. UML can be used in many ways. GRASP provides
guidance on OOAD, not the UML.
Use them in the order listed. Try each in turn until one fits....
you end up with a tradeoff between alternative good things to do. Two
competing patterns.... and that is when this approach becomes interesting.
In other words this is not a rigid program or procedure that does the
thinking for you. GRASP is a set of guidelines about what you need to
think about when doing design.
As a program runs, objects are constructed. They are constructed by the pieces of the software.
These can be the main program in a simple CS201/202/330 type program. But in a complex
or realistic piece of software objects construct other objects -- a lot! So the
question is: which object constructs this one? Who calls the constructor? Where
to put this code:
General * handle = new Constructor(data);
Larman suggests that we look in (1) the existing design, and (2) in the domain model
to find a class that is already tied to the type of object we want to make. And one tie
is that of containing it.... the black diamond of the UML: <*>------ that
indicates who has life and death control over objects of a class.
Thus: perhaps, in my Depot, and Stocks, .... situation, Creator would lead you to
make the Depot object construct the Stocks held in the depot. A Sales Order
might construct the Sales Items on it, etc.
Note: Larman is not refering to "containers" in the CSCI330 sense. These are vital
tools that are given to us to use, in practice, and so don't get modelled. Larman
is looking for real obects, or at worst, already invented software objects.
I don't have any personal tricks or tips. Just follow the examples
and thoughts in the book.
A controller object is sent events by the user interface (it asks to be notified, typically)
and then passes them on to other controllers (sometimes) or one or more effected domain
To be precise, some Controllers are associated with particular use cases. They
understand the sequence of events in the scenario and what to do at each step.
As the events occur, the User Interface passes the messages to the use case controller
(if the use case is recognisable). If the type of event does not determine the
use case (and there are several possible one running....) perhaps you need
a facade controller that figures out which handler to call.
In any case -- it is easier to work with a 100 line class than a 1000
not without a lot of thought inventing a deliberately bad design. I'll see what I can
So that different parts of the software do not depend on each other. So that
changes in one part do not force other parts to change as well.
To put it another way there is a certain amount of wiggle room between the
different pieces of the solution.
Here is an example of high coupling. In my Microsoft 2K Pro lap top
at home, sometimes when it comes out of hibernate mode it has the size of the
desktop wrong -- twice as big as the screen or half as big. Not the wallpaper,
oddly, but where the icons are put and the size of the pixels used to draw them.
Further this seems to happen if I enter hibernate mode when the model is active.
I don't understand how they can produce code where the modem and the desktop
size are coupled together.
And do not get me talking about the way "standby" mode fails on this machine.
It is more than reasoning and readability.
It is bad experiences with trying to modify "mudball" and "God" classes. When
you've got a large loose class you can't find out where things are done
and so it takes time to fix it. And often fixing one thing
breaks something else.
Yes -- the coupling within a package should be higher than the
coupling between packages. In other words each package tends
to be a coherent collection of classes.
However, certain couplings are needed to make the system work -- for
example UI calling controllers in the domain, and the domain model calling
the data base technical classes.
Only if there is a really good other reason. I can't think of one.... In this
class don't do it without a written excuse from me:-)
Yes. It's been a good idea since it was first suggested back in the
I just hope you start to develop a feel for when a class ahould really be split up because it
does not "stick together"... Each function/operation refers to a different set of attributes.
There is no sharing of responsibillities within the class, for example.
Notice: It is hard for me to remove points for something I can't give you an algorithm to do.
Cohesion is a property of a single class and measures how well
the class has a single purpose, common data, and intertwingled
I thought this when I first studied them. But in practice you can organize
the communication between classes and packages
to be through a small well defined interface which
lowers the coupling, while allowing a lot of communication within
a class or package.
YES. The ideal (impossible) is to have the software divided into
islands of responsibility. Much shared purpose and data inside each
island and no communication between the islands.
This would still be cohesive if it allowed you to move the triangle.
However, if we added an operation that records sales of pets it would
If we design a class figure that tried to handle Triangles and Circles in one
class ... we would create low cohesion.
Hope this helps.
Yes... but ugly and incomplete.
In other words: they are often badly layed out. Some tools
populate a data base and you have to extract the classes etc into diagrams -- the tool
also retirevies the connections between the pieces. You get an explorer window
of packages, clases, interactions, etc... and drag and drop into diagrams.
I am not aware of any tool that can reconstract the requirements (use cases) from
the code. I believe their is a fundamental disconnect between what we want
and what we have, between the ought and the is.
GRASP is simpler and more general. GoF are more code oriented
and tend to be rather sophisticated. They came first and tend to be
It turns out (later chapter) that most of the GoF patterns
are applications of Larman's GRASP principles/patterns.
Even tho' the GoF published their patterns first.
On of my reasons for selecting this book is that GRASP
summarizes a lot of best practices from many sources.
However, Craig is including an Actor icon
to show the user, which is illegal. He also attempts to show
the layers in a hypothetical architecture. The squiggly
line separates two layers: one the left is the user interface
(technology) layer, and on the right, is the domain layer.
He also has added an informal notes all over the place!
In theory these should be in comment boxes.
As a rule I'd like you to be a little more formal in your
diagrams. But, you can document the use of a GRASP pattern
the same way that Craig does.
It means that two or more use cases contain a common pattern of interaction.
This is abstracted into an included use case.
. . . . . . . . . ( end of section Questions and Answers on GRASP) <<Contents | End>>