 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2006Please help me to design supertype-subtype ..
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 > Hi all, > [quoted text clipped - 7 lines] > 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. > 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 opalpa@gmail.com http://www.geocities.com/opalpaweb/ >> 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 [quoted text clipped - 3 lines] > > 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. > 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. > > extending Thread, > Runnable. Or using the java.util.concurrent.* classes available in 1.5.  SignatureC. Benson Manica | I *should* know what I'm talking about - if I cbmanica(at)gmail.com | don't, I need to know. Flames welcome. >> 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. 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. >>> extending Thread, > >> Runnable. > > Or using the java.util.concurrent.* classes available in 1.5. True, though I sometimes still want to use Thread directly. > 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/CachedPa ge.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/ImgList ItemGenerator.html and here http://www.weft.co.uk/library/jacquard/documentation/uk/co/weft/htform/LinkTable Widget.html while each of the classes in this package http://fisherman.cvs.sourceforge.net/fisherman/fisherman/src/java/uk/co/weft/fis herman/web/ sits on a ten deep stack of classes, each of which adds some useful functionality. Signaturesimon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/ ;; If God does not write LISP, God writes some code so similar to ;; LISP as to make no difference. > 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_%28computer_science%29 > 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 opalpa@gmail.com http://www.geocities.com/opalpaweb/ > Hi all, > [quoted text clipped - 7 lines] > 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'. Signaturesimon@jasmine.org.uk (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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.