Sorry, I'd like to stay away from this, but can not.
Intelligence is NOT, and never EVER will be
"a capability to find algorithm to solve some problem"
This is the HIGHER order insult to Intelligence.
That is ALL I am interested in saying or even seeing
in THIS grade of crap.
So, everybody had a chance to talk their brains out on "design patterns".
And here is the scoop from my end of the wire:
Design patterns are not some recepies of God telling you "how it is"
in Reality.
They are ideas by some hopefully creative people that discovered
certain things, and those things are:
1) Optimization
Optimization is a broad issue.
You can optimize for performance.
You can optimize for code size.
You can optimize for minimum number of methods,
thus assuring the max. generality of code.
2) System structure
System structure is highly complex issue.
Basically, the MAJOR principles, the #1 criteria in system
is STABILITY.
If your program, which is a system, ever breaks,
than you may end up with a nuclear disaster,
just for the sake of argument.
Performance IS important, but only to the extent that it
does not affect the #1 criteria, stability.
System needs to be structured to minimize the complexity
of interactions. The more components and subcomponents
the system has, the more complexity results, and complexity
of ALL sorts, such as the number of interactions, the path
length to interact (the more steps you have to perform,
the longer is your path, the more probability of increased
complexity).
This is basically a beauty domain.
The simplicity.
Well designed system has the minimal number of components
and the minimal amount of interactions.
3) Reusability
Reusability is anotother way to describe generality or
universality of some component or subsystem.
It indirectly translates into portability as a side effect.
In a well designed system, some component or subsystem
could be used for multiple purposes by adding a thin
layer above it.
So, the fundamental premise behind the "design patterns"
is to maximize the system "correctness".
What is "correct" system?
Well, it is a mathematical issue.
In formal terms, it requires proof that your program logic
will perform as advertized under ANY conditions whatsoever.
To prove that system is "correct" in terms of mathematics
is FAR from being a trivial task.
It is interesting to note the fact that beyond an idea of
a semaphore that has been proven to be formally correct
by Digjstra, there exists no proof for more complex
systems to the best of my knwledge.
The complexity of problem is just immense.
Why are we leaning toward this train of thought?
Well, because when you evaluate and applicability of some
design "pattern", you have to watch really carefully what
does it buy you.
There are ALL sorts of issues in a system design, and,
especially in the modern and hecktic times,
you need to consider the information overload factor.
What is information overload factor?
It is a very interesting issue and higly complex.
One of the aspects of it is the fact that we are subjected
to tremendous amounts of information jamming our brains
almost anywhere we look.
In the software business, most of the time, people designing
something do not even bother to consider how consistent their
system is in terms of being similar conceptually with that,
which is well known and established at the moment.
So, they keep hacking some "new" ways of looking at things.
Take for example the user interface issue.
Have you noticed that most of the programs out there do not
present you with consistent user interface. They simply
invent all sorts of buttons, functionality, tabs, etc. as
THEY see fit, without even considering the fact that the user
may have to deal with hundreds of different programs, each
having thousands of different parameters, notions, functions,
buttons and you name it.
Each program simply exists in its own artificially created
world without even bothering that the user's mind can not
possibly switch from one world view to another with a flip
of the finger. His mind has to literally switch to another
universe with thousands if not millions of ALL sorts of
parameters, ways of looking at essentially the same things, etc.
One very interesting thing was the idea of Microsoft on
consistent GUI design they started advocating nearly a
generation ago.
The idea was essentially this:
Since the the most general level of GUI with any program
is the menu bar, you need to design it in a consistent manner.
Each program, no matter what it does, should have following
menu items:
1) File
2) Edit
3) Help
I do not remember exactly the details, but the idea still holds.
Basically, what it means is that your mind can easily switch
while using different programs because your basic menu categories
are logically similar, so the mind does not have to RADICALLY
switch from one world view to another, so different, that it
basically has nothing in common with the first one.
But what does it have to do with design patterns?
Well, it happens to apply to the idea of design patterns
just as well. How?
First of all, why do you need some "design pattern"?
Don't you have your own brain to structure the system
in the most optimal way?
What IS the design pattern?
Is it some kind of a pill against stupidity?
Is it some kind of recepie to "enlightenment" or way to heaven?
Nope.
Take for example an idea of an interface as such.
What is an interface?
Well, simple enough.
It is simply a way to communicate between systems that
minimizes the amount of different ways of looking at different
things by providing the most common parameters.
Secondly, it shields you from knowing the internals
of the other system you are trying to communicate with.
So, if you perform some operation, there is a requred
minimum of parameters to pass regarless of what kind of
operation are you going to perform.
That is basically an optimization issue.
Secondly, you can achieve a "code reuse" concept.
If system is architectured in general enough way,
then each component of that system may perform the necessary
operations in multiple situations and produce the correct
result REGARLESS of who is the client or consumer of that
operation. That is basically all there is to it.
Poorly designed system has a separate piece of code to
perform a similar operation but in a slightly differnt
context. As a result, you are basically dealing with
"special cases" no matter where you look in your system.
Another aspect of "design patterns" is the aspect that
ties in directly with the ability to very easily comprehend
some operation or a set of parameters and to be able to
understand a different piece of code. The information
overload issue.
In a well designed system, you should be able to look at
any piece of code and be able to understand what it does
within seconds. Nowadays, THAT is the time frame.
We no longer can afford switching our minds from one world
view to another, with its thousands or even millions of
different parameters and points of views.
The switch has to be smooth and easys.
That means things to be consistent.
There is a limited logical number of things that may
happen in ANY system, no matter what it does.
So, when you look at a totally different part of your system,
you don't want to have to switch your mind from Bible to
Coran and Yoga or Exestantialism.
You'll simply go crazy one day if you do these things
hundreds if not thousands of times a day.
You have to have some solid ground to stand on.
No wonder Jesus said:
"House that was built on the sand is bound to fall".
Correct.
Add the debugging aspect.
Since it is not possible to write the "correct" programs
from the very first attempt, no matter what smart guy tells you,
you would have to debug your code.
So, when you write that code, you need to be aware of
two fundamentally different approaches.
1) Syncronous mode
2) Asynchronous mode
In synchronous mode everything is simple.
Because you can follow each step of what your program does.
It is all sequential. One thing logically follows the other.
In async mode, it is a totally different world.
You can hardly single step it.
You'll come to some point where one component of your
system with perofm and write or send operation and that's it.
You won't be able to see the result of that write in
a syncronous manner.
Some event will occur and will trigger some other method
to handle the input or a result of your write.
Considering the fact that modern programs are mostly
multithreaded, the task of debugging becomes immense
if not monumental.
But what does it have to do with design patterns?
Well, that means when you have some issue to resolve,
yes, you CAN recall or review some "design pattern",
helping you to solve it.
But be very careful to consider ALL sorts of issues,
such as:
1) Information overload
2) Ability to read and understand the code fast, within seconds.
3) Ability to debug this thing
4) Ability to log this thing so it could be easily fixed.
If your design pattern exhibits the asyn behavior that is
not logically necessary, you may have a hell of a time
debugging or reviewing the log information.
5) What does that design pattern buy you at the end?
What issues does it solve?
What impact on system stability and performance does it have?
Get the drift?
:--}
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP,
organized by major topics of language, tools, methods, techniques.
