Please help me to design supertype-subtype ..

[krislioe]

Hi all,

We are designing our business components, I am confused about the
criteria to determine whether my two classes should be put into
Supertype/Subtype relationship.

Just because two classes have common attributes, is it enough reason to
create supertype-subtype on them ? What are other reason ?

For example, I have two classes : Sales & SalesReturn. They have
attributes in common. Should I make them supertype-subtype ?

Thank you very much,
xtanto

 

[Jeffrey Schwab]

Hi all,

We are designing our business components, I am confused about the
criteria to determine whether my two classes should be put into
Supertype/Subtype relationship.

Just because two classes have common attributes, is it enough reason to
create supertype-subtype on them ? What are other reason ?

For example, I have two classes : Sales & SalesReturn. They have
attributes in common. Should I make them supertype-subtype ?

No, not in Java. As long as you have any doubt at all, avoid sub-classing.

What you are describing is called implementation inheritance. In C++,
this is a reasonable technique, because you have multiple inheritance,
virtual inheritance, and the full public/private/protected access
control mechanism. In Java, you are better off moving the functionality
into a completely separate, third class, and letting Sales and
SalesReturn each instantiate the third class.

Come to think of it, there's probably no good reason at all for one
class to extend another in modern Java except for brevity in simple
cases, e.g. an anonymous inner listener class extending an adapter.

 

[opalpa]

Just because two classes have common attributes, is it enough reason to
create supertype-subtype on them ? What are other reason ?

What comes to my mind is that supertype-subtype relationship is used to
represent when one type of thing is another type of thing. The key
words being "is a" sometimes written as is-a or IS-A. Here is some
information
http://en.wikipedia.org/wiki/Inheritance_(computer_science)

For example, I have two classes : Sales & SalesReturn. They have
attributes in common. Should I make them supertype-subtype ?

A Sale is not a SaleReturn and a SaleReturn is not a Sale so no.
Perhaps they are both something ... like an Exchange

Sale extends Exchange { }
SaleReturn extends Exchange { }

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[opalpa]

Come to think of it, there's probably no good reason at all for one
class to extend another in modern Java except for brevity in simple
cases, e.g. an anonymous inner listener class extending an adapter.

A few good reasons:

Event hiearchies, parsers, extending swing components (JPanel, JFrame,
JComponent etc.), extending Thread, Strategy refinment, "extends
UnicastRemoteObject", "extends TestCase", "extends
HTMLEditorKit.ParserCallback"


All the best,
Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Jeffrey Schwab]

A few good reasons:

Event hiearchies,

Use interfaces instead, so that an event can be a "kind of" multiple
other event types. The same goes for exceptions.

parsers,

Use interfaces and composition instead.

extending swing components (JPanel, JFrame,
JComponent etc.),

True. The same goes for many other frameworks. I don't know that the
same design decisions would be made if Swing were being written from
scratch today.

extending Thread,
Runnable.

Strategy refinment,

No! The strategy should be an interface, and you can do all the
refinement you want on the back end.

"extends
UnicastRemoteObject", "extends TestCase", "extends
HTMLEditorKit.ParserCallback"

Right, for the same reason as Swing.

 

[Christopher Benson-Manica]

Use interfaces instead, so that an event can be a "kind of" multiple
other event types. The same goes for exceptions.

That gives you only one level, however, which is fairly limited. It's
worth noting that the builtin exception hierarchy is an example of the
use of inheritance for good, not for evil.

Runnable.

Or using the java.util.concurrent.* classes available in 1.5.

 

[Jeffrey Schwab]

That gives you only one level, however, which is fairly limited.

I'm not sure what you mean.

It's
worth noting that the builtin exception hierarchy is an example of the
use of inheritance for good, not for evil.

I disagree.

Or using the java.util.concurrent.* classes available in 1.5.

True, though I sometimes still want to use Thread directly.

 

[Simon Brooke]

in message <[email protected]>,

Hi all,

We are designing our business components, I am confused about the
criteria to determine whether my two classes should be put into
Supertype/Subtype relationship.

Just because two classes have common attributes, is it enough reason to
create supertype-subtype on them ? What are other reason ?

For example, I have two classes : Sales & SalesReturn. They have
attributes in common. Should I make them supertype-subtype ?

It may be appropriate to have a common abstract superclass. It doesn't seem
to me, semantically, that 'SalesReturn' is a kind of 'Sales' or
vice-versa, but both may be kinds of 'AbstractSalesTransaction'.

--
(e-mail address removed) (Simon Brooke) http://www.jasmine.org.uk/~simon/
; gif ye hes forget our auld plane Scottis quhilk your mother lerit you,
; in tymes cuming I sall wryte to you my mind in Latin, for I am nocht
; acquyntit with your Southeron
;; Letter frae Ninian Winyet tae John Knox datit 27t October 1563

 

[Simon Brooke]

Come to think of it, there's probably no good reason at all for one
class to extend another in modern Java except for brevity in simple
cases, e.g. an anonymous inner listener class extending an adapter.

Oh, absolutely disagree. Here's a hierarchy of classes:

java.lang.Object
extended by javax.servlet.GenericServlet
extended by javax.servlet.http.HttpServlet
extended by uk.co.weft.maybeupload.MaybeUploadServlet
extended by uk.co.weft.htform.Servlet
extended by uk.co.weft.htform.WithExceptionHandlerServlet
extended by uk.co.weft.domutil.DocPage
extended by uk.co.weft.domutil.TransformPage
extended by uk.co.weft.domutil.CachedPage

(http://www.weft.co.uk/library/jacquard/documentation/uk/co/weft/domutil/CachedPage.html)

I won't comment on the first three, since they aren't mine.
uk.co.weft.maybeupload.MaybeUploadServlet deals with file upload; in all
other respects its a straight plug-in replacement for Sun's HttpServlet
and can be used transparently in conventional Servlet code wherever file
upload is necessary. It is, of course, abstract.

uk.co.weft.htform.Servlet is the base layer Jacquard Servlet which does
basic configuration, and handles converting all the namespaces involved in
an HTTP service into a single namespace. It's abstract, too, but it
handles a lot of useful stuff for things higher up the tree.

uk.co.weft.htform.WithExceptionHandlerServlet provides pluggable exception
handlers for things further up the tree. It's abstract too. This
functionality could have been built into uk.co.weft.htform.Servlet, but
when it was first released it was experimental, so it seemed better not
to.

The htform Servlets were all built on the model that you print things to
the output stream as you compute them. This is simple and efficient but it
confuses content with logic and is on the whole not a good thing.
uk.co.weft.domutil.DocPage is a Servlet into which can be plugged a
DocumentGenerator. The DocumentGenerator encapsulates the logic of
whatever is being done and returns a completed org.w3.dom.Document which
DocPage can either print directly or (configurably) transform with an XSL
stylesheet serverside before printing.

uk.co.weft.domutil.TransformPage extends this by allowing which XSL
stylesheet to use for server-side transformation to be selected on the fly
at service time. This includes the possibility of not doing the transform
server-side, but instead offloading it to the client if the client
advertises that it is suitably equipped.

Doing server-side XSL transformation for each service is quite heavyweight.
In order to reduce the load on the server uk.co.weft.domutil.CachedPage
caches generated pages and serves requests from the cache where possible.

So there's a stack of six classes of mine, each of which adds some useful
functionality to its superclass, and in doing so compartmentalises
functionality in the codebase.

Browsing through my code there's a similar stack here:
http://www.weft.co.uk/library/jacquard/documentation/uk/co/weft/xhtmlgen/ImgListItemGenerator.html
and here
http://www.weft.co.uk/library/jacquard/documentation/uk/co/weft/htform/LinkTableWidget.html
while each of the classes in this package
http://fisherman.cvs.sourceforge.net/fisherman/fisherman/src/java/uk/co/weft/fisherman/web/
sits on a ten deep stack of classes, each of which adds some useful
functionality.