[platform-swt-dev] SWT Widgets Class Hierarchy

["Mohsen Saboorian" <mohsens@xxxxxxxxx>]

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.