[izpack-devel] FW: private to protected -> Objection

[Elmar Grom]

Sorry, I just noticed that I only sent this to Ryan, not to the list...

	Elmar

-----Original Message-----
From: Elmar Grom [mailto:elmar at grom.net]
Sent: Friday, September 01, 2006 3:25 PM
To: Ryan Shillington
Subject: RE: [izpack-devel] private to protected -> Objection


Ryan,

I agree that we talk about case a) here, this is inherent in the meaning of
deriving classes. However I do not agree about the conclusions from this
fact. ExtendedUserInputPanel is a UserInputPanel by the simple fact that it
is derived form UserInputPanel. But this does in no way mandate that it
therefore should also know about the inner workings of UserInputPanel. Even
setters and getters if used without clean interface specification can be too
much knowledge.

Setters and getters isolate the using class (derived or otherwise) to some
degree from the implementation. For one thing the variables you set and get
don't actually have to exist in the way suggested by the interface. The
remaining problem is, that the using class may make wrong assumptions about
situations when the contents of those fields changes or should change and
which values are legal. These assumptions may be wrong at the time of
writing of the derived class or they may become wrong because of a change in
the implementation of the base class. As a result, interfaces should be as
unspecific as possible to avoid trouble down the road. Simply replacing
direct variable access with setters and getter is often not sufficient.

If it appears necessary to get involved in the inner workings of the base
class, then it is rather questionable if we still talk about case a). I
don't think we can say ExtendedUserInputPanel is a UserInputPanel and find
at the same time that the inner works of UserInputPanel need to be muddled
with in some way. This would mean that it is actually not.

In such cases I find it useful to ask these questions:

1) is the derived class really only a more specialized Version of the base
class or is it only similar? Even though there might be similarities, it
does not necessarily follow that extension is the proper approach. A
parallel implementation might still be called for.

2) if the answer to the above question is yes, but it still appears that we
need to get involved in the inner works of the base class, then I would
assert that the base class has some sort design problem. Perhaps its code
should be distributed in some way among different classes. Actual
implementations of the extended classes might become assemblies of classes
and become an instance of the base class primarily be sharing an interface,
rather than inheriting...

In summary, I find it valuable to understand the Problems Marc is dealing
with. With this knowledge it should be possible to identify design problems
in UserInputPanel and redesign it as necessary to solve the problem. This
tends to be a better approach than hiding a problem by building another one
on top of it.

	Elmar

-----Original Message-----
From: Ryan Shillington [mailto:Ryan.Shillington at troux.com]
Sent: Friday, September 01, 2006 2:21 PM
To: elmar at grom.net; izpack-devel at lists.berlios.de
Subject: RE: [izpack-devel] private to protected -> Objection


Hello team,

I've been mulling this over for a while now too.

As I'm sure many of you know, whenever you're considering delegation
over polymorphism, the question always comes down to whether you would
put the words "is a" or "uses" in between the class names.

Hence, which one is more correct?
    a) ExtendedUserInputPanel is a UserInputPanel
 or b) ExtendedUserInputPanel uses UserInputPanel

I think the answer is a), and if so then it'll be very hard to write a
new ExtendedUserInputPanel without being closely coupled with
UserInputPanel.  Even if we provide getters and setters instead of
protected member variables, the implementation in ExtendedUserInputPanel
is still going to greatly depend on the implementation of UserInputPanel
because ExtendedUserInputPanel will expect UserInputPanel to be using
them internally.

One of IzPack's great strengths is that it is open source, meaning that
you can find a panel that does 80% of what you want it to do, and
override it to remove/add what you need.   Hence, especially because
we're in the installer business here, I'm leaning towards making our
variables protected.  Unfortunately your point is very, very valid - we
will be making it easier for people to write installers at the cost of
making it difficult for them to upgrade to the next great version of
IzPack.

But I digress... :-)

Ryan
</soapbox>
-----Original Message-----
From: izpack-devel-bounces at lists.berlios.de
[mailto:izpack-devel-bounces at lists.berlios.de] On Behalf Of Elmar Grom
Sent: Friday, September 01, 2006 2:54 PM
To: izpack-devel at lists.berlios.de
Subject: Re: [izpack-devel] private to protected -> Objection

Hi Marc,

I do object. This is against the very important principles of
information
hiding.

I am not sure which fields you want to access from your subclass. I
would
strongly advise to find other approaches to solve your problem. Writing
subclasses with detailed knowledge of the inside workings of the super
class, such as data fields, is never a good idea. This is particularly
true
in such a disconnected case as you present. If we ever make changes to
those
data fields or how we use them, anyone who wrote a subclass will see
their
code break. In many cases there will be no obvious indication of that
fact.

Instead we should strive to have a clean and dependable interface that
subclasses can really depend on.

	Elmar

-----Original Message-----
From: izpack-devel-bounces at lists.berlios.de
[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Marc
Eppelmann
Sent: Friday, September 01, 2006 11:57 AM
To: izpack-devel at lists.berlios.de
Subject: [izpack-devel] private to protected


Hi all,

I want to change the fields and methods of the UserInputPanel from
private
to
protected, to make it possible to derive an userdefined UserInputPanel
from
it. If there is nobody which has an objection about it, I will commit
this
next week at Tuesday. Then I will describe and document the features(**
of
my
derived ExtendedUserInputPanel and if there is anybody that interests
on, I
will commit this.

**) such as userdefined Title Layouts.

Cheers
Marc
_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel

_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel

IMPORTANT NOTICE:
This message may contain confidential information. If you have received this
e-mail in error, do not use, copy or distribute it. Do not open any
attachments. Delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.