OO debate: assuming type of containing object

[John A Grandy]

I'm in a vigorous debate at my work regarding objects assuming knowledge of
the type their containing object.

This debate pertains specifically to ASP.NET, but I have decided to post in
the C# forum because this is where most of the OO gurus hang out, and I view
this as a fundamental issue of OO design.

In ASP.NET, objects of type WebForm and UserControl have an intrinsic Page
property which refers to their containing Page.

So, for an instance of UserControl1 "oUserContr ol1" located inside an
instance of WebForm1 "oWebForm1" , oUserControl1.P age = oWebForm1.

Nesting is also possible: for an instance of UserControl2 "oUserContr ol2"
located inside oUserControl1, oUserControl2.P age = oWebForm1.
By default, WebForms inherit from the base ASP.NET Page class :
System.Web.UI.P age.

One common pattern is to include common page functionality in a derived
class, and then derive all WebForms from it. For example, CorePage :
System.Web.UI.P age.

So if we define WebForm1 : CorePage , it is possible and convenient to write
following code inside UserControl1 :

((CorePage)Page ).CustomPropert y = "abcd";
((CorePage)Page ).CustomMethod( textBox1.Text );

But if you do write such code, instances of this UserControl can only be
located inside WebForms which derive from CorePage.

We can also write the above code inside UserControl2. But if we do, all
instances of UserControl2 must be ultimately contained in WebForms which
derive from CorePage.
The debate is as follows: I argue that there are other ways for
UserControls to trigger functionality provided by containing objects.
Events are one such mechanism. I do not think that portability of objects
should be compromised in favor of coding convenience.

Others argue that for our project there is no anticipated need to ever use
WebForms that do not derive from CorePage. Further they argue that making
such an assumption is non-agile ( "agile" being a buzzword of such import on
the current sw dev scene that those arguing against "agile" are branded as
witches and burned at the stake).

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

John A Grandy wrote:

The debate is as follows: I argue that there are other ways for
UserControls to trigger functionality provided by containing objects.
Events are one such mechanism. I do not think that portability of objects
should be compromised in favor of coding convenience.

Others argue that for our project there is no anticipated need to ever use
WebForms that do not derive from CorePage. Further they argue that making
such an assumption is non-agile ( "agile" being a buzzword of such import on
the current sw dev scene that those arguing against "agile" are branded as
witches and burned at the stake).

How the communication between controls is done, isn't only about
reusability. By keeping the communication channels as limited as
possible, they can be kept well defined and easily manageable.

For example, when a control wants access to a method in a common base
class for the page, it's not a bad idea to use an interface, for several
reasons:

:: You get a reference to an interface, with which you can only do what
was indended.

- The intellisense won't show you half a million other properties,
methods and events from the Page class that you don't care about.

- You can't use a method from the Page class instead of a method from
the base class by mistake, as they are simply not available.

:: It's flexible, as the interface can either be implemented by a base
class or by the page itself, and the control doesn't have to know which
it is. If one of the pages needs to implement
Creating pages and controls that depend on each other doesn't only
prevent reusability, it also makes the code harder to follow. You have
to be aware of all the code in the page and all the code in all
controls, to be able to tell how the code is working. Welcome back,
spaghetti code...

If a control instead uses interfaces and events, you can tell how the
code in the control is working without knowing anything about the code
in the page and the code in other controls on the page. This is how OO
programming should be.
--
Göran Andersson
_____
http://www.guffa.com

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Göran Andersson wrote:

John A Grandy wrote:

>The debate is as follows: I argue that there are other ways for
UserControls to trigger functionality provided by containing objects.
Events are one such mechanism. I do not think that portability of
objects should be compromised in favor of coding convenience.

Others argue that for our project there is no anticipated need to ever
use WebForms that do not derive from CorePage. Further they argue
that making such an assumption is non-agile ( "agile" being a buzzword
of such import on the current sw dev scene that those arguing against
"agile" are branded as witches and burned at the stake).

How the communication between controls is done, isn't only about
reusability. By keeping the communication channels as limited as
possible, they can be kept well defined and easily manageable.

For example, when a control wants access to a method in a common base
class for the page, it's not a bad idea to use an interface, for several
reasons:

:: You get a reference to an interface, with which you can only do what
was indended.

- The intellisense won't show you half a million other properties,
methods and events from the Page class that you don't care about.

- You can't use a method from the Page class instead of a method from
the base class by mistake, as they are simply not available.

:: It's flexible, as the interface can either be implemented by a base
class or by the page itself, and the control doesn't have to know which
it is. If one of the pages needs to implement

Lost it in the middle of a thought there... ;)

If one of the pages needs to implement the methods differently, that can
be done without changing the base class to handle it.

>

Creating pages and controls that depend on each other doesn't only
prevent reusability, it also makes the code harder to follow. You have
to be aware of all the code in the page and all the code in all
controls, to be able to tell how the code is working. Welcome back,
spaghetti code...

If a control instead uses interfaces and events, you can tell how the
code in the control is working without knowing anything about the code
in the page and the code in other controls on the page. This is how OO
programming should be.

--
Göran Andersson
_____
http://www.guffa.com