Nicolas Alvarez <nic### [at] gmailcom> wrote:
> FactoryFactory??

> http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

  Overengineering (or in the case of software, overdesigning) really can be
a real problem.

  I have encountered this problem myself in a project I was working.
One guy was really too infatuated with object-oriented design, and went
really overboard with it. Almost *everything* had to be its own separate
class, in a really complex inheritance hierarchy, with several layers of
abstractions, one on top of another. One program he made consisted of over
20 source code files and was rather long and really complicated. The
program source code was rather hard to understand.

  Years later I had to reimplement that same functionality from scratch
(basically it was a simple modification of a similar tool). My version
of the same program consisted of 3 source code files, and the program
was 10 times faster with all inputs I tried. The OOD was, IMO, still
pretty good, but much more understandable because of a way more simplistic
approach.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Overengineering (or in the case of software, overdesigning) really can be
> a real problem.
> 
>   I have encountered this problem myself in a project I was working.
> One guy was really too infatuated with object-oriented design, and went
> really overboard with it. Almost *everything* had to be its own separate
> class, in a really complex inheritance hierarchy, with several layers of
> abstractions, one on top of another. One program he made consisted of over
> 20 source code files and was rather long and really complicated. The
> program source code was rather hard to understand.
> 
>   Years later I had to reimplement that same functionality from scratch
> (basically it was a simple modification of a similar tool). My version
> of the same program consisted of 3 source code files, and the program
> was 10 times faster with all inputs I tried. The OOD was, IMO, still
> pretty good, but much more understandable because of a way more simplistic
> approach.

I think if you're actually *trying* to do something that's inherantly 
complicated, a complex design may be called for. (And especially if 
future requirements aren't completely certain.)

OTOH, unless you're psychic, you will never know what the future holds, 
and any flexibility you design in will probably turn out to be not quite 
the right thing for what you *really* end up trying to add. There is 
definitely a lot to be said for keeping a design as simple as feasible!

Ever heard the phrase "analysis paralysis"? ;-)

Post a reply to this message

Warp wrote:
>   I have encountered this problem myself in a project I was working.

Same here. The one major program we hired a consultant to do at the last job 
needed to simply read a config file, then read from  N streams on a device 
driver and stuff them into a database as the data came in. Something like 30 
classes to do that, because each bit had its own abstract memory manager 
class and then the class that actually did work then yadda yadda. I would 
want to change something after he left, and it would take me like an hour to 
track down where he parsed the value of a config variable (and this is 
simple name=value\nname=value\n... sort of thing). You'd think given the 
names, you'd be able to, like, grep for the name in the source code and 
track it from there, wouldn't you?

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Invisible wrote:
> OTOH, unless you're psychic, you will never know what the future holds, 

Yeah. The first time I ran into this was early Java socket libraries, where 
they tried to make it possible to talk to different kinds of sockets. 
Granted, it was the first time I ran into the factory pattern (since 
Smalltalk doesn't need factories, since "new" is a method that returns a 
value), so it was a little confusing. I don't remember how you specified 
what protocol you wanted, but it wasn't something simple like passing some 
enum for the protocol to the factory method and getting back the right 
subclass of socket.

There are complexities you can hide, like "here's a URL, give me back an 
appropriate object to manipulate a URL with that scheme." There are some you 
shouldn't hide, tho.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   I have encountered this problem myself in a project I was working.
> 
> Same here. The one major program we hired a consultant

HAHAHA!

Seriously, are there *any* consultants who are good at something other 
than job security? Or is that just a myth?

Post a reply to this message

On 16-Jan-09 10:30, Invisible wrote:
> Darren New wrote:
>> Warp wrote:
>>>   I have encountered this problem myself in a project I was working.
>>
>> Same here. The one major program we hired a consultant
> 
> HAHAHA!
> 
> Seriously, are there *any* consultants who are good at something other 
> than job security? Or is that just a myth?

Gail?

Post a reply to this message

>> Seriously, are there *any* consultants who are good at something other 
>> than job security? Or is that just a myth?
> 
> Gail?

I wasn't aware Gail was a consultant...

Post a reply to this message

Invisible wrote:
> Seriously, are there *any* consultants who are good at something other 
> than job security? Or is that just a myth?

There are, actually. We just hired poorly in that case. (My interview 
process got overruled due to time constraints, basically.)

The code eventually worked. It was just impossible to maintain.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

On 16-Jan-09 16:58, Invisible wrote:
>>> Seriously, are there *any* consultants who are good at something 
>>> other than job security? Or is that just a myth?
>>
>> Gail?
> 
> I wasn't aware Gail was a consultant...

Last year she left her company to become a consultant in a small firm, 
remember?

Post a reply to this message

>> I wasn't aware Gail was a consultant...
> 
> Last year she left her company to become a consultant in a small firm, 
> remember?

Oh, right. I must have missed that...

Post a reply to this message