Re: Factory Design Pattern and Select Case
From: Mr Frank (frank_at_mybusiness.com)
Date: 03/25/05
- Next message: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Previous message: David Gilliland: "Re: interfaces in APIs"
- In reply to: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Next in thread: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Reply: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 25 Mar 2005 08:21:21 GMT
"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
news:3ah7c8F68k5tqU1@individual.net...
> Mr Frank wrote:
> > "Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
> > news:3ag9r3F6b22l8U1@individual.net...
> >
> >>dean hully wrote:
> >>
> >>>I have been involved in another ng that is debating the un oo'ness of
> >>>select case statements in VB.net or C#. The consensus seems to be
> >>>avoid them where possible.
> >>>
> >>>My problem is in vb.net or C# I always seem to get to the point where
> >>>I need them. What am I missing?
> >>>
> >>>For instance, in the factory pattern how do I avoid using a select in
> >>>the factory to choose which object to create? One answer has been
> >>>CallByName and another is using the app.config or web.config to create
> >>>a coupling between the variable/property of the client and the
> >>>resulting object created by the factory.
> >>>
> >>>Any opinions out there?
> >>>
> >>>Thanks,
> >>>
> >>>Dean
> >>
> >>To begin with, select statements are innocent until proven guilty.
> >>They're certainly not the scary monster some make them to be.
> >
> >
> > It was proven guilty, several decades ago.
> >
>
> Well, whatever. If you want to stays stucked in your little dark corner
> where it's only one way, be my guest.
>
No we've added techniques not subtracted them.
> However should you bother to learn more perspective and more approaches
> you'll see that functional programming languages raised the humble
> switch to the status of fine art. It's called pattern matching.
>
> But hey, we're not gonna make a sub-thread just to split the hair in 4
> are we ?
Agreed.
> >>But anyways, since you ask how to avoid select statements in a factory,
> >>the answer is quite trivial:
> >>
> >>Use hashmaps or arrays or any other declarative means to associate a
> >>name with a type (or with a constructor)In more flexible languages you'd
> >>be using directly constructors or type as any other values, in .NET you
> >>can use delegates. Every concrete class might provide a static read only
> >>property that is the "delegate" (oh, I really hate this name!!!, for non
> >>.NET readers, it's a function reference) to construct the object.
> >>
> >>So the factory would be something like
> >>
> >> constructObject(String name) {
> >> return configHash[name]();
> >> // or something similar, add checks for nulls, etc.
> >> }
> >
> >
> > Using a hash map, avoids the keyword "switch" but it is just another
> > selection mechanism.
> >
> > How will you populate this hash, by using code like this?
> > hash.add ("Circle", factory.circleMaker() );
> > hash.add ("Square", factory.squareMaker() );
> > ....
> >
> > How is that different to this?
> > switch (type)
> > case circle: o= factory.circleMaker(); break;
> > case square: o= factory.squareMaker(); break;
> > ...
> >
> > The switch is a native construct of the language, it is therefore
faster,
> > easier to read, avoids bloat and only requires one function.
> >
>
> Whateveryou think of the switch, it's not necessarily faster, and in any
> case speed in this case is largely irrelevant.
It is an order of magnitude (or more) faster than a hash table. Compilers
are able to generate direct jump tables, the selected case is found in very
few instructions.
> But the central point is: the mapping is *data* not code. When you hide
> data into a statement construct it's gonna be less clear in the intent
> (plus it cannot be externalized, etc). Some languages even have literal
> constructs for declaring hashtable. For those that don't you have syntax
> for constructing array data.
The factory pattern is about the creation of different kinds of objects (ie
*code+data) not *data* alone.
> Hashtables are not switches no matter how much you want to handwave
> about them. Plus, hashtables can be dynamically altered if needed, and
> so on, so forth.
Correct hash tables are not switches, however the original paster asked if
various non-OO interusions could be avoided.
Unless there is direct language support ... the answer is *no*. Using a
hashtable doesn't overcome the violation of the open/closed principle. It
was only in that sense that I meant that they are similar. Also the
following code performs substantially the same job, albeit using different
mechanisms.
Hash version:-
hash.add ("Circle", factory.circleMaker() );
hash.add ("Square", factory.squareMaker() );
...
Plus the method to lookup the decided result.
Switch version:
case circle: o= factory.circleMaker(); break;
case square: o= factory.squareMaker(); break;
The similarity is obvious (or is it?).
Whether you agree that the above is performing a selection or not is
immaterial to the original question. There is no question about it not being
a solution to the original problem.
A decision is made in code as to what type of object to create.
Whether you use a switch, if statements, hash table *or whatever* the point
is /you/ need to do something. Once you've done it once, you need to keep
maintaining that code. The requirement to open up (re-hack) closed (ie
tested and finished) code is what we are trying to avoid and it's what we're
talking about (right)?
> Regardless of the merits of one versus the other, and I'm not saying
> that one is better, because it depends on the context, to argue that the
> two are the same is just a useless flamebait, that is not worth my time.
I'm not interested in flamewars but I am interested in facts :)
Have a nice day.
Frank
- Next message: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Previous message: David Gilliland: "Re: interfaces in APIs"
- In reply to: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Next in thread: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Reply: Costin Cozianu: "Re: Factory Design Pattern and Select Case"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
