🚀 go-pugleaf

Hello Tad,

My use of object pooling lies in 2 main areas.

1.  Server's client connection threads
2.  Just threads of all kinds

I found it really improved performance for code that must constantly create
threads to instead check one out at the pool, then set properties to make
the threaded object useful for the given context.  Threaded object creation
is very expensive, even more so than just plain object creation.  Setting
references in fields however is a speedy process.  I use threads to manage
most of the dataExpress stuff, and each DataSet has at least one associated
thread that takes care of it.  And no, I haven't done anything that would
require one to visually monitor pool activity.  I never believed in
supervised beaches anyway ;-)

About the delegation...

Tad Frysinger wrote in message ...
<SNIP>
>I'm also interested in your comment that delegation causes weaker
>coupling.  I've always thought it was just the opposite: inheritance by
>its very nature is a weaker contract, because changes in the super
>classes more easily affect the subclasses, whereas interfaces are a
>contract that holds true even as implementations change over time.  Can
>you elaborate?


What I mean't was that: Delegation = Looser Coupling = Weaker Relationship =
Not Responsible for Each Other = Less Dependency

By coupling I meant the coupling between classes.  What that means is that I
can have a JTextField use code that lies within a JFrame one second, then
have JTextField use code lying in a JButton with the same method name the
next.  All this, even though JFrame, JTextField, and JButton are completely
independent classes.  Generally, the term weak or loose coupling is used
when classes can change and evolve independently from each other.  This is
why reuse through acquaintance is considered a weaker "coupling" than reuse
through aggregation.  Reuse through inheritance on the other hand submits
your subclass to utter dependancy on its superclass.  Not only is the
relationship set statically in stone, but the implementation of a subclass
become so "Bound" with the implemenation of the parent's, that any change in
the parent's implementation will force the subclass to change.  Thus the
subclass's implemenation is strongly bound "coupled" with that of its
superclass -  "Inheritance breaks encapsulation". Classes within an
inheritance pattern are so strongly coupled, that changes in the
superclass's implementation also effect that the subclass.  Are we just
mincing words here?

See ya at the Pool!

Gerry Mantha