🚀 go-pugleaf

Am soliciting opinions on the wisdom of sub-classing all or most of
the basic objects in the Java or 3rd party toolkits.

Assume the AWT package as an example.  Rather than coding directly
with these objects, we would sub-class each one, for example:

            public class myButton extends java.awt.Button

or even:

            package mystuff.awt;

            public class Button extends java.awt.Button

and then import mystuff.awt.*


The reason for considering this is so that within our code we always
have a "hook" if it is necessary to implement a system-wide policy
(e.g. all buttons will be red) or override a method to change default
behavior (or avoid a known bug).

The questions:

1) Do we take a performance hit at run-time, or will the compiler
optimize the extra class extension away if it doesn't add any code?

2) If we keep the same name, Button, and just import only our own
packages, do we run into compile-time problems with naming conflicts?

(Undersand we have to re-implement any non-default constructors.)  The
nice part of keeping the same name is that we could actually implement
sub-classing after-the-fact by playing games with the directory trees.

3) How do we handle factory methods that do the class instantiation?
For example, the SQL Statement object has a factory method
executeQuery which returns a ResultSet.  Really want to sub-class
ResultSet with myResultSet, but how do I get my version instantiated
without tearing apart system classes?  (ResultSet is only an interface
anyway, which leads to other problems -- I don't really know what base
object is instantiated by executeQuery.)

4) Are there any other anomolies with this approach?

All opinions welcome.  We love the idea of building in a 'hook' at the
start of development, but want to be sure we understand all of the
implications.

Any references to books/articles which discuss this approach would be
greatly appreciated.  (I remember seeing the idea originally in a
Delphi publication -- but can't remember where!)

John