Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] subclassing 
Tuesday, February 19, 2002, 3:48:57 AM, Alessandro Maria wrote:
ADM> Hello!

ADM> I'm programming at moment a prototype in SWT.

ADM> So far it works well. But I was wondering, why most every widget can't be
ADM> subclassed,
ADM> although they are not declared final. Is this because of a strict mapping
ADM> between the java classes and
ADM> the native classes? And will this change in future? (What I hope)
ADM> When programming a class, the name's a little confusing: MyShell is not a
ADM> Shell, it's more something like MyShellWrapper or MyShellController.

ADM> In AWT/Swing I normaly extend a Component and add some fields to reference
ADM> to other objects (like model, beans, ...). With SWT this is not possible. But
ADM> I found some methods in the Widget class: getData() and setData().  Are this
ADM> methods the workaround for the lack of subclassing?

Alessandro,
           Check out the "Writing Your Own Widgets" article, about
           half way through the article, the issue of subclassing
           widgets directly is addressed. Here is an excerpt taken
           from that article.
           (http://www.eclipse.org/articles/Article-Writing%20Your%20Own%20Widget/Writing%20Your%20Own%20Widget.htm)

           

Subclassing Widgets Directly In extreme circumstances, you may need to
subclass a widget other than Canvas or Composite. We recommend against
doing this unless all other avenues have been explored and exhausted.
Try to wrap the widget first, before subclassing it. Here is why:

· Subclasses may inherit a lot of API that makes no sense, and must be
overridden. In Java, you cannot override a method and change the
return type; therefore you cannot reimplement some methods.

· Subclassing is typically not the safest way to extend a class that
you do not own. For a simplified list of the common arguments, see the
article by Bill Venners in the Nov '98 issue of Java World called
“Inheritance versus composition: Which one should you choose?” at:
http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html

· Widget subclasses are almost certainly guaranteed to be
platform-specific unless great care is taken to ensure that they work
on all platforms.

· Subclassed widgets can be affected by changes in the non-API
implementation of the superclass.

· Subclassing may cause bad system-level bugs, and runs the risk of
leaking resources. For example, if a subclass reimplements a method
without making certain that dispose code from the superclass method is
still called, then the new method will leak system resources.

· Binary incompatibility across releases becomes possible. If a method
signature or field name changes, or new methods or fields are added,
there may be a name conflict in the widget subclass. Only Canvas and
Composite are guaranteed not to have name conflicts in future
releases.

· See any paper by Leonid Mikhajlov on the “Fragile Base Class
Problem”. He has a summary of this problem on his web page at:
http://www.abo.fi/~lmikhajl/

HTH,
Chris
-- 
Chris Grindstaff
chrisg@xxxxxxxxxxxxxxxxxxxx  |  www.appliedReasoning.com

Back to the top