Diff b/w factory pattern and strategy pattern
Radde
Can anyone tell whats the difference between factory design pattern
and strategy pattern..I saw couple of examples,,both patterns looks
same to me..
Eg:
Factory pattern:
class shape
{
public:
virtual void draw() = 0;
};
class sqaure : public shape
{
void draw()
{
}
};
class circle : public shape
{
void draw()
{
}
};
class context
{
Shape* sh;
public:
// Factory method
Shape* Factory(int i)
{
case 0:
sh = new Square();
break;
case 1:
sh = new Circle();
break;
}
};
void main()
{
context cont;
Shape* sh = cont.Factory(0);
sh.draw();
Shape* sh = cont.Factory(1);
sh.draw();
}
// Strategy pattern
class NameStrategy {
public:
virtual void greet() = 0;
};
class SayHi : public NameStrategy {
public:
void greet() {
cout << "Hi! How's it going?" << endl;
}
};
class Ignore : public NameStrategy {
public:
void greet() {
cout << "(Pretend I don't see you)" << endl;
}
};
class Context {
NameStrategy& strategy;
public:
Context(NameStrategy& strat) : strategy(strat) {}
void greet() { strategy.greet(); }
};
int main() {
SayHi sayhi;
Ignore ignore;
Context c1(sayhi), c2(ignore), c3(admission);
c1.greet();
c2.greet();
}
Cheers....
Alvin Ryder
Factory is for creation. Strategy is for alternatives.
Factory is needed where a simple 'new' won't work because you need to
first determine 'what to create'. Check the Factory method (which is
missing the switch statement btw).
Alternate greets are brought into a situation by way of "different
strategies" Check SayHi.greet(), Ignore.greet(), YetAnother.greet().
Nothing to do with 'what to create', it's a case of 'how to compute' (a
greet in this case).
So it's Factor := 'what to create', Strategy := 'how to compute'.
HTH
Cheers
Radde
of view, both are nearly same..Iam really not able get the major
difference between these two..
H. S. Lahman
> Can anyone tell whats the difference between factory design pattern
> and strategy pattern..I saw couple of examples,,both patterns looks
> same to me..
Ryder is correct that the main difference lies in instantiation vs.
collaboration. Generally instantiation and collaboration involve
different rules and policies so that alone is sufficient to justify
different patterns.
A similar spin is static vs. dynamic. Factory is about a one-time
instantiation of object and relationships. IOW, what it instantiates is
dynamic but, once instantiated, it remains unmodified for the object's
life. Strategy is about an ongoing selection of behavior based upon
run-time context (i.e., the relationship between [Context] and
[Strategy] is often instantiated dynamically for different collaboration
contexts during the execution). IOW, Strategy deals with dynamism in
ongoing collaborations throughout the object's life.
At a megathinker level all of the GoF patterns are the same. They all
provide a solution for a collaboration that is too dynamically complex
to be described with a simple association between the Client and the
Context object. In most cases that complexity stems from the need to
substitute behavior based upon run-time context. Hence almost all of
the GoF patterns also involve delegation of one sort or another by the
Context object.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
![Nick Malik [Microsoft]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Nick Malik [Microsoft]
concept. Code comes later.
Conceptually, these are different.
Factory allows us to seperate the concerns of creation from use. The
calling code doesn't have to know the rules required to correctly construct
an object, and we can derive new mechanisms for construction without
affecting calling code.
Strategy is about creating many implementations of an algorithm or process
and being able to plug in one instead of another. It is about how
information is used by each of the objects to perform the calculation, and
how the results are returned in a common way. It is perfectly rational for
a factory to be used to decide which strategy object to create. However,
the strategy pattern is talking about how the object is used, not so much
how it is constructed.
When one human speaks with another about design, they can use different
words to covey these different concepts and motivations.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Radde" <msra...@gmail.com> wrote in message
news:1118486358.8...@f14g2000cwb.googlegroups.com...
Robert C. Martin
>Hello,
> Can anyone tell whats the difference between factory design pattern
>and strategy pattern..I saw couple of examples,,both patterns looks
>same to me..
An Abstract Factory *is* a Strategy used for creation. Some patterns
are simply specific instances of others. As another example,
Composite is a decorator for plurality, Proxy is a decorator for an
intermediary. State is a set of interlocked Strategies.
Template Method is a pattern that solves the same problem that
Strategy solves. And Factory Method is the instance of Template
Method that is used for creation.
-----
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
Ilja Preuß
> Strategy is about creating many implementations of an algorithm or
> process and being able to plug in one instead of another.
True. Of course the creation of an object can also be seen as a process. I'd
therefore say that Abstract Factory is a specialized form of Strategy (and
Factory Method a special kind of Template Method).
Don't you agree?
Cheers, Ilja
Nick Malik [Microsoft]
of Strategy. However, conceptually, they are different in their use and in
the design goals that lead you there.
My point is to ignore the code for a minute and look at the underlying
causes that led the designer to a particular pattern. If these causes are
distinct, then, for the most part, so should the term be that describes it.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Ilja Preuß" <i...@iljapreuss.de> wrote in message
news:42ab...@news.totallyobjects.com...
Robert C. Martin
<nick...@hotmail.nospam.com> wrote:
>This is not about the code. We use the names of patterns to convey a
>concept. Code comes later.
Patterns are about code; or at least structures that translate
directly to code.
As for code coming later, I find that problematic. It's too easy to
sling patterns around without justifying them. Code is that
justification. Indeed, code is often the *motivation* for a pattern.
Most of the patterns solve problems related to code structure. We
often don't even know we need a pattern until the code starts to
smell.
Factory is a good example. Far too many systems have used factory,
even though they didn't need it. The designers thought the Factory
pattern was cool, and so they deployed it into a design that had no
real use for it.
Observer often finds itself in a similar situation. The idea is so
"neat" that some designers hang observers all over the place, creating
systems that cannot be understood or diagnosed.
Another commonly abused pattern is Singleton. Lots and lots of
projects have used the Singleton pattern without bothering to consider
how simple it might have been to simply create one instance of the
object.
Robert C. Martin
<nick...@hotmail.nospam.com> wrote:
>You could say that, structurally, Abstract Factory is a "specialized" form
>of Strategy. However, conceptually, they are different in their use and in
>the design goals that lead you there.
No, I'd say that abstract factory is a strategy used for creating
objects. While there is a narrowing of the concept, there is no
mismatch.
>My point is to ignore the code for a minute and look at the underlying
>causes that led the designer to a particular pattern.
Hopefully it was code that led him to the pattern. Too many patterns
are put in place without being led by the code.
Nick Malik [Microsoft]
For example: I agree with each of your examples of "often abused patterns."
I, too, have found situations where a designer fell in love with a pattern
without knowing what value it would add to the code. I've often heard of
developers complaining because they have to maintain code where a factory
was used for every single thing, and it was frustrating.
On the other hand, I do believe that we disagree about one point: that code
comes before design. I believe that code comes before refactored code, and
that code is best refactored when it starts to "smell."
However, in a project with any real complexity, a simple
Commonality-Variability Analysis (CVA) will highlight a set of forces that
the design should meet, that are OO in nature, but not tied to a language at
all. The code could be written in Smalltalk, Java, C#, etc... but the
design process illustrates the forces that are acting on the code... and
these lead to the patterns. This is more of a Model Driven Architecture
approach.
I agree that a pattern should not be added until there is a force that is
clearly identified, and driven either directly from the requirements or the
system constraints, that leads to that pattern. Otherwise, YAGNI.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
news:e2gua1t4vgp16f1r9...@4ax.com...
Robert C. Martin
<nick...@hotmail.nospam.com> wrote:
>I think that we agree more than we disagree.
That may be, but we learn more from each other through disagreement.
(So long as it is civilized.)
>On the other hand, I do believe that we disagree about one point: that code
>comes before design.
Code is the ultimate act of design, and the ultimate test of design.
Design is not complete until code is complete. Moreover, designing
without coding is risky, and should be kept brief and informal.
>I believe that code comes before refactored code, and
>that code is best refactored when it starts to "smell."
Agreed.
>However, in a project with any real complexity, a simple
>Commonality-Variability Analysis (CVA) will highlight a set of forces that
>the design should meet, that are OO in nature, but not tied to a language at
>all. The code could be written in Smalltalk, Java, C#, etc... but the
>design process illustrates the forces that are acting on the code... and
>these lead to the patterns. This is more of a Model Driven Architecture
>approach.
I think our industry has abused the term "model" so much that we've
forgotten what a model is. A model is a device used to measure some
aspect of design. Creating a model is not the act of design. A model
is not a design. A model represents one view of a design in order to
measure how that view resolves the forces it must content with.
Aeronautical engineers build models of airframes and put them in wind
tunnels. Architects build wire frames of buildings and shake them to
see how they respond to Earthquakes. These models appear in the
*reverse* side of the feedback loop. They provide information about a
design that has already been created. They are tests of that design.
Nowadays we talk about Model Driven X. The whole notion of Model
Driven is oxymoronic. Models don't drive. Models are not on the
outgoing side of the feedback loop, they are on the reverse side.
DesignProcess-------+------->Product
A |
| |
| V
measurement<------Model
>I agree that a pattern should not be added until there is a force that is
>clearly identified, and driven either directly from the requirements or the
>system constraints, that leads to that pattern. Otherwise, YAGNI.
IMHO the forces that lead to patterns are generated by code, not by
concept. We may *speculate* about whether a Decorator or Visitor
might be needed; but it is the code that will prove or disprove that
need.
raxit...@gmail.com
Raade has started Good Topics it Really Require good Thinking.
As per My Point of view , If we Take only GoF 23 Patterns(We can take
many more)
And We study all of them then we will find that All 23 Patterns are not
Totally Isolated.
There are Some Overlap Between Some Patterns(From Features and / or
Code view).
I think we should not stick to Code(Implementation).But to Model and
Design.
Then also We might feel that so and so pattern is just Simple Variation
of Other Pattern.( Or one Pattern is more Abstract then other like
wise....)
Some one will tell Strategy is Not Factory.
some one will tell Strategy is .
Also Thinking Depends on "LAYER OF ABSTRACTION" ....!!!
I think We should note down our thoughts , share it and Use Them
Effectively.
(And that is what we doing here...:) )
Bcoz This will be the CORE /Fundamentals Thing , And we can Reuse the
Experience....!!!
So From My Point of View Factory is a Strategy to Create (Instantiate)
Some Type of Object.
But If I will Start using Strategy instead of Factory (or Vice
Versa) It will not help to make Good Communication.
Bye
Regards
Raxit Sheth
mail: raxitsh...@yahoo.co.in
raxit...@gmail.com
As A Good Software Designer/Architect Code Should Not Be Much Important
at Design Stage.
What you have told is Central to The "Code".
But If Design( Or Architecture ) of Software is More Powerful then it
will Reduce the Future Complexity.
If Design Stage Some Error (Bug / Misconcept) Happend
Then The Code will be of little use ( or Big Impect of Design Change on
Code)
So Its not Good To Think in Terms of Code.
This is My Personal Opinion
Nick Malik [Microsoft]
Thank you for your contribution. If I may ask, please, refrain from making
the first letter of every word into a captial letter. Only the first letter
of the sentence and proper nouns should get the capital letter. Using
"Sentences Where Every Word Is Capitalized" is more difficult to read.
Thanks,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
<raxit...@gmail.com> wrote in message
news:1118910814.9...@g49g2000cwa.googlegroups.com...
Nick Malik [Microsoft]
Thank you for to honest discussion.
>>On the other hand, I do believe that we disagree about one point: that
>>code
>>comes before design.
>
> Code is the ultimate act of design, and the ultimate test of design.
> Design is not complete until code is complete.
Very eloquent. I agree with each statement. It is interesting that you use
the term "ultimate." According to the American Heritage Dictionary, the
word "ultimate" means "Being last in a series, process, or progression" and
"eventual". In other words, Code is Last... after Design.
What worries me is the notion that code leads the developer to the pattern.
I disagree because code RARELY leads anyone to a pattern. Design, or the
careful and systematic consideration of structural and mechanistic forces on
an object, will produce a PLAN for addressing those forces that will lead to
structural relationships between objects, which are expressed in code. It
is true that design can be done poorly. So can code. I'm sure that we will
both agree that many examples exist for both positions there.
> Moreover, designing
> without coding is risky, and should be kept brief and informal.
I don't have any love of huge class models, or people spending huge amounts
of time creating frameworks. Design without a clear goal of producing
useful code is risky. However, would you not agree that code without
consideration of design is risky as well?
>>This is more of a Model Driven Architecture
>>approach.
>
> I think our industry has abused the term "model" so much that we've
> forgotten what a model is. A model is a device used to measure some
> aspect of design.
<aside>One of my favorite expressions: All models are wrong. Some models
are useful.</aside>
A model is a representation of an object that captures a single aspect of
the object's existence. That representation can be created at any time. It
_should_ be created at the most useful time. Using my more expansive
definition, a model could include a diagram. More typically, a modelling
tool will use a diagram as a single expression of the data, and code as
another expression of the data. Therefore, human beings can not only get a
visual representation of existing code, but they can create a visual
representation first, and then have the code flow from the representation.
There are a number of tools that work this way. Visual Studio 2005 will
have this ability as well. I have used Enterprise Architect by Sparx
systems and have found that to be quite useful.
The testing of the model comes when the coding is performed, since the model
generates the outlines of the code, but not the logic. (For example, a
typical output will be a series of Java or C# files that contain the class
definitions, parameters, inheritance, override declarations, and the
getter/setter code.) It is up to the coder to add the logic to the methods.
Therefore the act of testing IS the act of coding. The goal of the
model-expressed-code is to make it easier to generate code that conforms to
the model and therefore that single vision (and single aspect) of the
design.
Your definition is far too restrictive. Models are for more than
measurement after the fact.
> Aeronautical engineers build models of airframes and put them in wind
> tunnels. Architects build wire frames of buildings and shake them to
> see how they respond to Earthquakes.
True. But engineers and architects will also create _drawings_ of the thing
that they are building, and will share those drawings with other people.
People will examine and inspect those drawings carefully. The symbol
language is will known, so no one has to explain the drawings or provide
much of a key, except to declare that a drawing has a purpose (electrical
layout plans).
These drawings are tested... by people and (more recently) by simulation
systems. These drawings are created before the object, or even the physical
tangible model of the object, is created. They are tested before the design
is complete, and before a single act of actual construction has taken place.
Most earthquake testing occurs before a single pound of concrete is poured.
These days, most wind tunnel testing occurs before a single rivet is driven.
These models are NOT tested after the item is created. They are tested
before, not by building the item, but by testing the model itself. The
models are a respresentation of the design, not of the code. They come from
the blueprints, not from photos of the building or the plane.
Therefore, the building does not come first, followed by the blueprints.
And code does not come first, followed by the design.
> Nowadays we talk about Model Driven X. The whole notion of Model
> Driven is oxymoronic. Models don't drive.
Correct, but people who use models can use them to convey complex ideas,
assuming other folks understand those ideas and are willing to listen. The
model can solve problems that endless hours of discussion cannot. In that
way, people (who use models) can drive a project where the same people, sans
the diagram, cannot. The term Model Driven Architecture attempts to
differentiate between these two mechanisms of "human" interaction. Parsing
a term and attacking the words, without examining the meaning, is simply
argumentative.
> Models are not on the
> outgoing side of the feedback loop, they are on the reverse side.
>
> DesignProcess-------+------->Product
> A |
> | |
> | V
> measurement<------Model
>
The only problem with your diagram is the implication that the model is
somehow (a) not required, and (b) seperate from the design process. The
model is the OUTPUT of the design process. Taking the model and expressing
the code is the first act of construction. That expression can be automatic
or it can be manual. This can (and should) be done many times. Code is not
a waterfall act and design is not best done in a closet.
If you short-circuit that act, and you create code without a design, you may
be creating a toy, or even a proof of concept. The code may happen to match
a redesign, but only by coincidence, and without thought to the overall
forces that are expected to act upon it. The liklihood is that the code
will be disposed of, leaving only the algorithms and sometimes the interface
ideas.
>>I agree that a pattern should not be added until there is a force that is
>>clearly identified, and driven either directly from the requirements or
>>the
>>system constraints, that leads to that pattern. Otherwise, YAGNI.
>
> IMHO the forces that lead to patterns are generated by code, not by
> concept.
Not concept... thought.
> We may *speculate* about whether a Decorator or Visitor
> might be needed; but it is the code that will prove or disprove that
> need.
"Prove or disprove" are testing concepts. You have stated, yet again, that
code tests design.
You keep saying that we disagree, yet your words keep backing up my
statements. I don't think that we disagree that much.
Ilja Preuß
> You could say that, structurally, Abstract Factory is a "specialized"
> form of Strategy. However, conceptually, they are different in their
> use and in the design goals that lead you there.
>
> My point is to ignore the code for a minute and look at the underlying
> causes that led the designer to a particular pattern. If these
> causes are distinct, then, for the most part, so should the term be
> that describes it.
I use strategy if I want to vary the behaviour of an object at runtime. I
use Abstract Factory if I want to vary the *object instanciation* behaviour
of an object at runtime.
Does that help understand my reasoning?
Cheers, Ilja
Robert C. Martin
>So Its not Good To Think in Terms of Code.
It is *very* good to think in terms of code, because code is real,
code can be executed, code can be verified.
You should not make the error that code is low level and design is
high level. Code can be written at all levels of abstraction. You
can have high level code and low level code. Some code describes the
highest levels of abstraction. Some code describes the lowest levels
of implementation.
Code *is* our design language. Any language that does not execute is
not a design language, it's like a block diagram. There's nothing
wrong with block diagrams, but it would be a mistake to think that a
block diagram is anything more than a sketch of the design. The code
is the design.
Robert C. Martin
<nick...@hotmail.nospam.com> wrote:
>Hello Robert,
>
>Thank you for to honest discussion.
>
>>>On the other hand, I do believe that we disagree about one point: that
>>>code
>>>comes before design.
>>
>> Code is the ultimate act of design, and the ultimate test of design.
>> Design is not complete until code is complete.
>
>Very eloquent. I agree with each statement. It is interesting that you use
>the term "ultimate." According to the American Heritage Dictionary, the
>word "ultimate" means "Being last in a series, process, or progression" and
>"eventual". In other words, Code is Last... after Design.
I think you inserted a few words there. If we replace the word
"ultimate" with the word "last", then my statement becomes "Code is
the last act of design" which is, in fact, what I meant to say. If we
then add your comment it becomes: "Code is the last act of design...
after Design." which is a non-sequitur.
There are indeed design steps that may precede code. We may draw some
UML on a whiteboard. We may do some CRC. We may just brainstorm.
However, this activity is not "Design" with a capital D. Rather this
activity is just part of design, and an incomplete part at that.
Design is completed with the code.
>What worries me is the notion that code leads the developer to the pattern.
>I disagree because code RARELY leads anyone to a pattern.
Really? If I see two functions with similar structure, I think
Template Method. If I see a big if/else statement with enums, I think
Strategy, or Command. If I see the same loop over and over, I think
Composite. When I see if/else chains of data types, I think Visitor.
Each design pattern solves a particular *coding* dilemma.
>Design, or the
>careful and systematic consideration of structural and mechanistic forces on
>an object, will produce a PLAN for addressing those forces that will lead to
>structural relationships between objects, which are expressed in code.
"Plans are useless. Planning is everything." Dwight D. Eisenhower.
IMHO we plan to use far more patterns than we need to use.
See: http://www.objectmentor.com/resources/articles/xpepisode.htm
>
>> Moreover, designing
>> without coding is risky, and should be kept brief and informal.
>
>I don't have any love of huge class models, or people spending huge amounts
>of time creating frameworks. Design without a clear goal of producing
>useful code is risky. However, would you not agree that code without
>consideration of design is risky as well?
Of course. However, writing code *is* a consideration of the design.
It may be poorly considered, but it is always such a consideration.
raxit...@gmail.com
>It is *very* good to think in terms of code, because code is real,
>code can be executed, code can be verified.
Yes I agree that code is real,can be executed and verified.
If one directly start jump for coding then while maintainance comes one
would only doing testing,executing,testing..... and one will just Open
the code ,change ,test,(may document change),open code, change
,test..........And will create spaghetti of code.
>You should not make the error that code is low level and design is
>high level. Code can be written at all levels of abstraction. You
>can have high level code and low level code. Some code describes the
>highest levels of abstraction. Some code describes the lowest levels
>of implementation.
I think we both agree on this. in our previous post , we dont specify
at what level.But naturally i was thinking code=low level, design =
high level.
also plz specify that you are talking at which level coding high /
low....?
if you are talking about high level coding then we agree....its likely
equal to design.
>Code *is* our design language.
Not appicable to all. (talking about low level code).
Also one more thing i want to share.
if design is not done properly it will affect the code.
if analysis is not done properly it will affect the design (and also
code)./
take a number : 111
( the weight of all 1 is not equal)
first = 100
second = 10
third = 1.
============
if you replace first 1 by 2 (i.e. 211) its Big Impact.
if you replace second 1 by 2 (i.e. 121) its moderate Impact ( less
impact then above).
if you replace third 1 by 2 (i.e. 211) its having very little Impact.
So from my opinion
ADC=111
A-Analysis
D-Design
C-Coding(implementation).
Bye
Regards
Raxit Sheth.
Robert C. Martin
<nick...@hotmail.nospam.com> wrote:
>More typically, a modelling
>tool will use a diagram as a single expression of the data, and code as
>another expression of the data. Therefore, human beings can not only get a
>visual representation of existing code, but they can create a visual
>representation first, and then have the code flow from the representation.
>
>There are a number of tools that work this way. Visual Studio 2005 will
>have this ability as well. I have used Enterprise Architect by Sparx
>systems and have found that to be quite useful.
If code is produced from the model, then the model is not a model, it
is a programming language. If code is produced from a diagram, and
then the code itself must be altered, then the usefulness of the
diagram is compromised. If the tool must litter the code with
comments in order to keep it's bearings, then the tool is intruding on
the code, and incurring a cost.
Though I think it's "cool" to generate code from diagrams, I have yet
to find it truly useful. In the end, the code is easier and quicker
for me to maintain, than the hassle of drawing the diagrams and
keeping the code generation tool happy.
>The testing of the model comes when the coding is performed, since the model
>generates the outlines of the code, but not the logic. (For example, a
>typical output will be a series of Java or C# files that contain the class
>definitions, parameters, inheritance, override declarations, and the
>getter/setter code.) It is up to the coder to add the logic to the methods.
I find this very problematic. Test Driven Development teaches us to
move in very small increments, each of which executes after a minute
or so. As we move, minute by minute, from executing state to
executing state we make tiny changes to the structure of the software.
Thus the static structure evolves in very short cycles guided by
actual program execution.
If we use a tool to create a "model" of the static structure of our
system, and then generate the code from that model, and *then* fill in
all the missing logic, we lose the ability to move in tiny steps and
evolve the static structure. This can, and has, led to systems that
are much larger and more complex than they need to be. Again, the
bowling game is a simple, but compelling, example.
See: http://www.objectmentor.com/resources/articles/xpepisode.htm
The Bowling game example begins with an Object Oriented Design in UML
that shows a relatively complex class structure. We could generate
the code from this model and then add the logic, and we'll wind up
with 400 line of code (as measured by folks who have done it). By
following TDD it ends up as a function with a for-loop and two
if-statements with 18 lines of code in the core algorithm.
>Your definition is far too restrictive. Models are for more than
>measurement after the fact.
I disagree. Models are created as a way to measure some aspect of a
proposed (or complete) design. We build models because it is cheaper
to measure them, than it is to measure the real thing.
We may be measuring some technical aspect of the system (e.g.
dependencies), or we may be measuring appropriateness of the design by
expressing the design in a shorthand that evaluators can quickly
assimilate, or we may even be measuring the ability of people to
understand the design.
Robert C. Martin
>Hello Mrtin...
>
>
>>It is *very* good to think in terms of code, because code is real,
>>code can be executed, code can be verified.
>
>
>Yes I agree that code is real,can be executed and verified.
>
>If one directly start jump for coding then while maintainance comes one
>would only doing testing,executing,testing..... and one will just Open
>the code ,change ,test,(may document change),open code, change
>,test..........And will create spaghetti of code.
No. One does not have to create spaghetti. Spaghetti is created by
programmers who think that they don't have time to do things right.
If you think you don't have time to do things right, you will make a
mess every time, no matter whether you start with design diagrams or
not. On the other hand if you know that the only way to go fast is to
go right, then you won't make the mess. Period.
This is the essential rule of software professionalism: "The only way
to go fast, is to keep things as clean as possible at every moment."
>
>>You should not make the error that code is low level and design is
>>high level. Code can be written at all levels of abstraction. You
>>can have high level code and low level code. Some code describes the
>>highest levels of abstraction. Some code describes the lowest levels
>>of implementation.
>
>I think we both agree on this. in our previous post , we dont specify
>at what level.But naturally i was thinking code=low level, design =
>high level.
>
>also plz specify that you are talking at which level coding high /
>low....?
Code that encapsulates the high level policies of the system is high
level. Code that implements the low level details of the system is
low level.
For example:
void Payroll.payDay() {
foreach Employee e in EmployeeDatabase {
if (e.isTodayPayday()) {
Money pay = e.CalculatePay();
e.SendPay(pay);
}
}
}
This is a very high level module. It specifies how all employees are
paid, without knowing any of the details about how pay is calculated,
payday is determined, or how pay is sent.
In a procedural program, the functions: IsTodayPayday, CalculatePay,
and SendPay, could be directly traced to the particular algorithms
that implement them. They would likely have switch statements on
payTypes such as Hourly, Salaried, and Commissioned.
In an Object Oriented program those functions are not directly
traceable to their implementations. The implementations would be in
subclasses that depend on the base class Employee.
>
>>Code *is* our design language.
>Not appicable to all. (talking about low level code).
I disagree. Code is our design language at all levels. We can have
diagrams that help, but the diagrams are just help, not the actual
specification of the design.
>
>if design is not done properly it will affect the code.
Since design and code are the same thing, this is clearly true.
>if analysis is not done properly it will affect the design (and also
>code)./
If only we could define "analysis". However, analysis, design, and
implementation need not (should not) be done in phases. They should
all be done at the same time on a minute by minute basis.
>take a number : 111
>
>( the weight of all 1 is not equal)
>
>first = 100
>second = 10
>third = 1.
>============
>
>if you replace first 1 by 2 (i.e. 211) its Big Impact.
>if you replace second 1 by 2 (i.e. 121) its moderate Impact ( less
>impact then above).
>if you replace third 1 by 2 (i.e. 211) its having very little Impact.
>
>
>So from my opinion
>
>ADC=111
>
>A-Analysis
>D-Design
>C-Coding(implementation).
I think your model is rather badly broken. Consider:
If you have really good requirements and great diagrams you've got 110
out of 111. But nothing executes, and you don't get paid.
On the other hand if you do lousy analysis and lousy design but manage
to get the program to work you have 001, and you get paid.
Clearly being paid is associated with C=1.
In my view the relation between A, D, and C is the integral of
dA*dD*dC*dt. You are always doing each of them, always in tiny
increments, and if any of them are poor, the overall result suffers.
A is not more important than D which is not more important that C.
They are all part of the same activity and cannot be separated in
time.
Alvin Ryder
> What worries me is the notion that code leads the developer to the pattern.
> I disagree because code RARELY leads anyone to a pattern.
>
Hi,
Actually when I write code I often "discover" patterns.
If I do lookup documented patterns, I jump pretty well straight to the
examples (someone else's code). Either way it's code that does it for
me ;-)
Frankly I found some patterns hard to understand in their generalized,
cataloged, almost obfuscated style of writing, ... yet later I realized
"hey, is that all it was, I've been doing that for years already".
Cheers.