Interwoven.  (sorry)

Once again, I'm not saying that design patterns are bad.  In fact
studying them can give you good insight into ways of doing things that
really improve your code.  Just don't use them every time you see
something that vaguely resembles something they will solve.  It's
design pattern Over-Use that I dislike.

--- Mike Bresnahan <mike at fruitioninc.com> wrote:
> We may end up having to agree to disagree.  Heh

I'm sure at least we'll disagree.  Whether we agree to it or not is
still up in the air. :)

> 
> Let me start with a disclaimer.  I have been guilty more than once of
> creating overly complex solutions as a result of my passionate
> pursuit of
> elegant, generic, and beautiful code.  I think it is the
> mathematician/physitist in me.  I'm always seeking to make my code
> more and
> more general and semmetric much like mathematicians and physiticts
> are
> always seeking to find the underlying thereom or the grand unified
> theory.

Fair enough, but even the most brilliant physicist uses 
Ag = -9.8 m/(s*s)
for the accelleration due to gravity if they are not worried about how
things will act on the moon, and don't think air friction will be that
important.  In this case, going after the generic just makes things
worse.

> So I understand first hand your concerns about unnecessary code
> complexity.
> However, I do not feel I am guilty in the current context.
> 
> I create a new class called Tuple so that I can change the
> implementation
> later without effecting client code - basic data abstraction.  I also
> find
> that the name more clearly describes the class's role.  Additionally,
> I may
> want to add more features.  For example, I may want the tuple to
> maintain
> order of the elements.  java.sql.ResultSet does this.  You can
> retrieve a
> column via its name or its index.  Hashtable does not allow this.

Fine.  If you need that functionality, a Tuple could be a useful class.
 If you don't need it, you're over-complicating things in your search
for simplicity.

> I feel the producer-consumer pattern is not nearly as complex as
> you're
> making it out to be.  Here's some sample code off the top of my head
> based
> on that found in Patterns in Java.
> 
> public class Producer implements Runnable {
>     private Queue queue;
>     public void run() {
>         Thingy thingy = getThingy();
>         queue.push( thingy);
>     }
> }
> 
> public class Consumer implements Runnable {
>     private Queue queue;
>     public run() {
>         Thingy thingy = queue.pull();
>     }
> }
> 
> public class Queue {
>     private java.util.LinkedList list = new java.util.LinkedList();
>     public synchronized void push( Thingy thingy) {
>         list.add( thingy);
>         notify();
>     }
>     public synchronized Thingy pull() {
>         if( list.size() == 0) {
>             try {
>                 wait();
>             }
>             catch( InterrruptedException ex) {
>             }
>         }
>         return (Thingy)list.removeFirst();
>     }
> }

Okay, those 3 skeletons look very simple.  However it does show that
you have 3 more classes, each of which will in the final version be
quite a bit larger than what is shown above, each requiring another
class to document, debug, and understand (for future maintainers). 

Also, what is written so far doesn't actually do much except wrap the
ends of a Queue with wait/notify.  You still have to make some threads,
do something useful with the thingy, and start the execution.  Not to
mention deciding where to put the looping (parent Thread with a
separate run() or in the run() s above) and how to control the
termination of the process.  Once you decide where to put these things,
ask yourself how obvious will your decision be to the future
maintainers?


> I'd also like to make the point that there is more to software
> quality than
> source code simplicity.  In fact, the most important software quality
> criteria have nothing to do with source code, rather they have to do
> with
> user satisfaction.  User's really don't care how simple, beautiful,
> or
> maintainable your code is.  They only care how well it performs the
> work
> they ask of it.  By not using the producer-consumer combined with a
> thread
> pool you seem to favor code simplicity over user satisfaction.

Not quite true.  Users will probably eventually care about the
maintainability of your code, but that usually happens after you have
been paid, so YOU might not care.

The other thing they don't care about is your 'passionate pursuit of
elegant, generic, and beautiful code.'  What they care about is A) How
much will it do? and B) How much will it cost? (maintainability is
buried in B)

Also, True Elegance and simplicity tend to go hand in hand; with the
other hand, they hang onto maintainability.

 
> I also believe that code simplicity is not always the road to
> maintainability.  For instance, hard coding the number of worker
> threads
> into the application may be simple, but it is a maintainence
> headache.
> People supporting the software in the future will have to make code
> changes,
> do testing, and do a rollout simply to do some simple performance
> tuning.
> Hard coding anything like that is a big no-no in my book.

I completely agree, and you will note that I did not show any
hard-coding of values.  The ALL_CAPS_VARIABLES are often pulled from a
properties file.  Or, depending on the re-use potential of your class,
they can be passed as a parameter by the using classes (which
presumably get them from properties files).


> I've had to rewrite more than once code that used polling instead of
> proper
> wait/notify semantics, because of the performance problem it was
> causing.  I
> think 20 instructions per poll is an overly conservative estimate. 
> Can Java
> get anything done in 20 cyles?  

It can get a lot done in 20 cycles.  Run some tests with a modern VM
sometime.  But you're right.  wait/notify is more proper, and that is
why I mentioned it in the first place.

However, most of the time when you have performance problems, it's
because there is a straight spin, with no sleep time.  And it would not
be too difficult to modify the sleep loop code to wait properly.


> Additionally, if you plan to run this

> application on a server shared by other applications you simply
> aren't being
> a good neighbor by wasting precious cpu cycles.  Even with today's
> 1Ghz
> processors, cpu cycles are not a renewable resource.  Perhaps you
> should
> reconsider your refusal to sign the Kioto Protocol, Mr Bush.

Again, that's why I mentioned it in the first place.


> Mike
> ----- Original Message -----
> From: "Bill Gladen" <nobody170 at yahoo.com>
> To: <tclug-devel at mn-linux.org>
> Sent: Tuesday, July 17, 2001 6:23 AM
> Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends?
> 
> 
> > Okay, today's preface will be that I'm grumpy.
> > On that note, I shall withdraw yesterday's preface and state that
> He's
> > flat out wrong. :-)
<snip/>


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/