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).