An interface defines the minimum contract requirements for a class to
implement it, not the maximum. Thus, if an interface only requires that a
class allow an accessor to be defined for a given property, the interface
does not define that the object be "read-only," but rather that the object
provides a means by which to access the value of the property. If an
interface defined the entire contract (no more, no less), then new methods
that were not present in the interface definition would be banned from
implementing classes. This restriction makes little sense.

If an object were referred to by a variable of its interface type, and this
interface type specified only an accessor while the implementing class
provided both accessor and mutator methods, then access to a provided
mutator would be illegal. Thus the defined contract is maintained.

Personally, I have thus far avoided .NET class "properties" due to their
lack of conformance or similarity to method inheritance. This case is one
clear instance of one of these such anomalies. Another example, which peeves
me big time, is the inability to assign different visibility modifiers for
accessor vs. mutator property code blocks (such as public get {} and
internal set {} for the same property). While the getProperty(),
setProperty(value) constructs are a bit more verbose and difficult to
maintain, I find the two aforementioned deficiencies all too common to
warrant the lack of consistency required to have the best of both worlds;
thus I stick with the verbose method.

joe

-----Original Message-----
From: John St. Clair [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 26, 2002 9:33 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Tricky little issue..

I'm not sure you *should* be able to do it... To me, the original poster's
request might make more sense if it was a matter of properties on the base
class itself (a straightforward inheritance question).

Instead, the confusion seems to be that properties (as merely syntactically
"sugar") can come in pairs -- he's put one-half on the original interface --
shouldn't one be able to implement the other half on the class itself?

But if you do that, can the class still be described as implementing the
interface (since it is by definition read-only)?

John

You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced 
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to