http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html

Even way back in Java 1.0 stuff, it was fabulously complex to open a socket, 
like anyone's going to try to write software that runs on both SNA and IP.

-- 
   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:

> Even way back in Java 1.0 stuff, it was fabulously complex to open a 
> socket, like anyone's going to try to write software that runs on both 
> SNA and IP.

I thought the whole point of IP is that it's one protocol to run over 
the top of every possible transport?

What *I* love about Java so much is the way especially the AWT has 
apparently multiple methods which seem to do the same thing, but don't. 
For example, an applet has the start() and init() methods. But they're 
different. But nobody really knows why.

The API seems to abound with huge classes that have complex interfaces 
that aren't really documented very much. You're just supposed to *guess* 
what all those methods do and what they're for.

Post a reply to this message

Darren New wrote:

> Even way back in Java 1.0 stuff, it was fabulously complex to open a 
> socket, like anyone's going to try to write software that runs on both 
> SNA and IP.

Not forgetting of course that one release would add a new API and 
deprecate the old one. And then the next release would deprecate the new 
API and *undeprecate* the orginal one. (?!) That always amused me...

Post a reply to this message

Invisible wrote:
> I thought the whole point of IP is that it's one protocol to run over 
> the top of every possible transport?

It works poorly for that, as IP works poorly over lots of WAN technologies.

> What *I* love about Java so much is the way especially the AWT has 
> apparently multiple methods which seem to do the same thing, but don't. 
> For example, an applet has the start() and init() methods. But they're 
> different. But nobody really knows why.

AWT is a mess, but they promised to never deprecate it. Nobody wanted to 
learn this whole thing and "write once run once" only to have the next 
generation not run it. Did they actually manage to keep it running usably? 
Or did it get entirely replaced by Swing?

-- 
   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:
>
http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html
> 

FactoryFactory??

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

Post a reply to this message

Nicolas Alvarez wrote:
> FactoryFactory??

Not just a factory factory. A request processor factory factory!

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

Most excellent!

-- 
   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

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