Interface Invariant

[Interface Invariant]

(Say) I define Interface 'X' and implement it in
Class 'Y'.

Why, according to the interface invariant, must I create
a new interface if I want to modify any methods, members,
properties, indexers and events defined within it?

If I change, for example, a return type of a method in
Interface X, then why should it make sense to create a
whole new interface with the new return type, rather than
change it in the existing interface and do any required
changes in Class Y?

Seems to me that re-creating the interface has order of
n+1 complexity, where n is the total locations in class Y
where I have to do changes to re-establish the interface
contract, and 1 is the name of the Interface, which will
be changed in Class Y (not considering the overhead
involved in creating the new interface).

At the end of the day, the answer may reside in the large-
system situation, where it will be rather inneficient to
detect and correct Interface contract infringement, so it
might as well reside on the compiler capability to signal
that infringement and lead the developer to correct the
implementation details.

Comments?

Louis

 

[Alvin Bruney]

You can if you want.

You only need to implement a new interface if you dont want to break old
versions

 

[junk]

[This followup was posted to microsoft.public.dotnet.framework and a
copy was sent to the cited author.]

(Say) I define Interface 'X' and implement it in
Class 'Y'.

Why, according to the interface invariant, must I create
a new interface if I want to modify any methods, members,
properties, indexers and events defined within it?

If I change, for example, a return type of a method in
Interface X, then why should it make sense to create a
whole new interface with the new return type, rather than
change it in the existing interface and do any required
changes in Class Y?

Seems to me that re-creating the interface has order of
n+1 complexity, where n is the total locations in class Y
where I have to do changes to re-establish the interface
contract, and 1 is the name of the Interface, which will
be changed in Class Y (not considering the overhead
involved in creating the new interface).

At the end of the day, the answer may reside in the large-
system situation, where it will be rather inneficient to
detect and correct Interface contract infringement, so it
might as well reside on the compiler capability to signal
that infringement and lead the developer to correct the
implementation details.

Comments?

Louis

In my opinion it is because of the basic architecture of COM and
versioning.

 

[Frank Oquendo]

Why, according to the interface invariant, must I create
a new interface if I want to modify any methods, members,
properties, indexers and events defined within it?

That's simple: the whole point of interface is to create a contract
between classes which implement an interface and classes which consume
them. You cant very well advertise that you'll be returning an int and
expect to get away with returning a double.

Seems to me that re-creating the interface has order of
n+1 complexity, where n is the total locations in class Y
where I have to do changes to re-establish the interface
contract, and 1 is the name of the Interface, which will
be changed in Class Y (not considering the overhead
involved in creating the new interface).

Of course not. If you stick to the rules and do not change published
interfaces, there is absolutley no reason to go back and modify existing
consumers unless you want to avail yourself of the new functionality.

Also, if this type of change is prevalent it would seem to me that you
should be looking at inheritance, not interfaces.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)