[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Re: SWT Widgets Class Hierarchy
|
Mohsen Saboorian wrote:
I'm likely to commit suicide :)
Any comment?
I too became very sad when I discovered that SWT has passed up the
opportunity to use a good interface-oriented design for its API.
The fact that the decision arose from SWT's origin on memory-constrained
platforms (which is why they abandoned AWT) is little solace.
But suicide is not the way to go, even though it brings on many changes. :)
AOP and SWT's open source nature each offer practical approaches to
improving your situation.
AOP is probably the way to go. It can easily be used inject the
interfaces you desire for API improvement.
Also it is directly supported in the Eclipse now, so your injection
advice could be readily adopted by others who like your improvements.
If they became very popular, it is possible the changes could be adopted
by SWT's developers.
Jim
On 12/2/06, Mohsen Saboorian <mohsens@xxxxxxxxx> wrote:
Hi,
From time to time, I find something odd with SWT class hierarchy,
which causes me to code more. The only explanation I could tell to
myself is that SWT is trying to have its API as easy as possible. But
this easy-thinking could be sometimes really frustrating.
I express here 4 examples:
1. Combo and CCombo are two classes with rather same interface (say
ICombo), but in fact there is no common interface defined in SWT.
Here is a case that happened to me; I have a number of (big) combo
boxes in a SWT application, which works fine in Windows. When I wanted
to run the application on Linux, since setVisibleItemCount(int) is not
implemented on GTK (it is in fact not possible due the way GTK combo
is implemented), combos covered the full screen. If there was a common
ICombo interface, I could easily change all the Linux combos to CCombo
(which supports that method).
2. setText()/getText() is a very common method among widgets, which is
not forced by any interface. Suppose a case that you want to implement
a number of different table editors (a CCombo and a Text as an
example), with a common listener. If there was an interface for
widgets (like IWidget), you could then use that to handle all the
table columns regardless of column number.
3. Button is another example. Why should checkbox, radio button, and
normal button use the same class, and for example getSelection doesn't
work for button? neither of SRP, and LSP are hold here.
4. There would be fine to have a simple (either without any method)
interface for layout data classes. setLayoutData would better to
accept a special interface, rathe bare Object :).
I believe that there would be more examples if others share their own
experiences with class hierarchy oddities here.
Thanks.
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
