[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework

Changing an interface

Bill D

7/22/2008 3:54:00 PM

I've seen 2 differnt approaches people take to interfaces and am just curious
on some other opinions. For purposes of this post I am talking about adding a
new method to an existing interface. The first is that an interface can
never change, once it's "published" it is fixed in stone and if a change
needs to be made you should create a new interface that possibly inherits
from the old one. The second is that it is ok as long as the change does not
break the existing contracts, which wouldn't happen if a new method was
added, since they were not using it before they wouldn't need to be aware of
it now.

thoughts?
13 Answers

Pavel Minaev

7/22/2008 4:35:00 PM

0

On Jul 22, 7:54 pm, wdudek <wdu...@newsgroup.nospam> wrote:
> I've seen 2 differnt approaches people take to interfaces and am just curious
> on some other opinions. For purposes of this post I am talking about adding a
> new method to an existing interface.  The first is that an interface can
> never change, once it's "published" it is fixed in stone and if a change
> needs to be made you should create a new interface that possibly inherits
> from the old one. The second is that it is ok as long as the change does not
> break the existing contracts, which wouldn't happen if a new method was
> added, since they were not using it before they wouldn't need to be aware of
> it now.

The second approach is incorrect since the interface can be
implemented as well as used; in fact, it is the whole point of having
an interface! If you change the interface, all existing
implementations would immediately break. Just imagine what would
happen if Microsoft added, say, a new method to IEnumerable tomorrow.

If you do not want to allow users to implement your interfaces, then
interfaces are the wrong tool for the job. Use abstract classes with
internal constructors. Those can only be used but not derived from by
code outside of your assembly (and friend assemblies, as needed), so
there you can safely add new methods. Well, almost - keeping in mind
that adding a new overload can break existing code; if you had a
method Foo(double), and in your new version added an overload
Foo(decimal), any code that called it passing an integer - e.g.
Foo(123) - would now stop compiling because of ambiguity.

Peter Duniho

7/22/2008 4:50:00 PM

0

On Tue, 22 Jul 2008 09:34:45 -0700, Pavel Minaev <int19h@gmail.com> wrote:

> The second approach is incorrect since the interface can be
> implemented as well as used; in fact, it is the whole point of having
> an interface! [...]

While I agree with pretty much everything else you wrote, I'll point out
that allowing the client to implement the interface is not "the WHOLE
point of having an interface".

There are examples of interfaces that are read-only as far as the client
is concerned. In those situations, it shouldn't be a breaking change to
add a member to the interface. For example, using an interface to control
accessibility (C# doesn't provide as fine-grained accessibility control as
some other languages, and so an interface might be used to keep an entire
class private except to some specific other class while allowing _some_ of
the members of the class to be public to the rest of the world).

Which is not the same as saying that doing so should be considered
lightly. Just that there are in fact scenarios in which changing the
interface after the fact wouldn't be disastrous.

Pete

Bill D

7/22/2008 5:43:00 PM

0

I understand Pavel's comments about if Microsoft added a method to
IEnumerable, and definately see how that would cause problems. From Peter's
perspective I guess I need to provide more background information on what we
are changing and why. Probably the most important piece to this is that we
are writing this strictly in house, not that this should allow us to bend the
rules and make changes we shouldn't. Secondly what I started off doing that
caused me to post this was add functionality to an existing wcf service. The
service currently has a method that returns a list of products a user can
see. The new method did the same thing but also limited the list by an
application name provided by the calling client. There are numerous
applications using the old code so they need to see the interface with the
current method. Meanwhile new applications need to see both methods. I didn't
want to create a second service because the functionality is very integrated
and people calling this wouldn't expect to look elsewhere for it. After doing
some testing I found that I could add the new method and the existing code
would work fine while the new code would get the additional method. I didn't
seem to have much choice here. My dilema arose when I got to the library the
service calls and how to handle this there. I originally added a new
interface but then decided that since there wasn't a new interface in the wcf
service that this was confusing. This led me to go back and add the method to
the existing interface. I guess the one caveat about this all being in house
code is that I know that the only code implementing the interface that was
added to is the class inside the library containing the interface. All other
references to the interface are to the return valeu of my factory class. Does
this change anyone's opinion?

"Peter Duniho" wrote:

> On Tue, 22 Jul 2008 09:34:45 -0700, Pavel Minaev <int19h@gmail.com> wrote:
>
> > The second approach is incorrect since the interface can be
> > implemented as well as used; in fact, it is the whole point of having
> > an interface! [...]
>
> While I agree with pretty much everything else you wrote, I'll point out
> that allowing the client to implement the interface is not "the WHOLE
> point of having an interface".
>
> There are examples of interfaces that are read-only as far as the client
> is concerned. In those situations, it shouldn't be a breaking change to
> add a member to the interface. For example, using an interface to control
> accessibility (C# doesn't provide as fine-grained accessibility control as
> some other languages, and so an interface might be used to keep an entire
> class private except to some specific other class while allowing _some_ of
> the members of the class to be public to the rest of the world).
>
> Which is not the same as saying that doing so should be considered
> lightly. Just that there are in fact scenarios in which changing the
> interface after the fact wouldn't be disastrous.
>
> Pete
>

Peter Duniho

7/22/2008 6:10:00 PM

0

On Tue, 22 Jul 2008 10:43:02 -0700, wdudek <wdudek@newsgroup.nospam> wrote:

> [...] Does this change anyone's opinion?

Not mine. And I think you could use an occasional paragraph break. :)

Basically, I think that there are times when you can get away with simply
modifying an existing interface. But I agree with Pavel in the sense that
I think one should consider those situations carefully.

The usual way to deal with versioning issues like this is actually to
create a second interface, either as a new version of the old interface
(so includes both methods) or as a whole new interface (including only the
new method). You can use casting or "is" and "as" (in C#) to convert a
reference to the old interface to one of the new interface.

I'm not aware of a better general-purpose versioning mechanism in .NET. I
wish there were one, but I'm not sure what it would look like :). If you
have a really good, compelling reason to avoid using the standard approach
and just modify the existing interface, there are (as I said) situations
in which that could be justified. But otherwise, I think it's better to
stick with the "tried and true", clunky though it might be. :)

Pete

Pavel Minaev

7/22/2008 7:15:00 PM

0

On Jul 22, 8:50 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:

> While I agree with pretty much everything else you wrote, I'll point out  
> that allowing the client to implement the interface is not "the WHOLE  
> point of having an interface".

I disagree, but do read on.

> There are examples of interfaces that are read-only as far as the client  
> is concerned.  In those situations, it shouldn't be a breaking change to  
> add a member to the interface.  For example, using an interface to control  
> accessibility (C# doesn't provide as fine-grained accessibility control as  
> some other languages, and so an interface might be used to keep an entire  
> class private except to some specific other class while allowing _some_ of  
> the members of the class to be public to the rest of the world).

That was precisely why I went on to explain how abstract classes can
be used for the same purpose. The reason being, you can't force the
client to avoid implementing an interface and passing it to your
methods which take arguments of corresponding types; and with abstract
classes, you have that option, and for the task you described (hiding
implementation classes, exposing only a limited surface), they work
just as well. Therefore, it would seem that using abstract classes for
that purpose is more appropriate.

Bill D

7/22/2008 8:05:00 PM

0

They really need a preview pane in here to prevent those run on paragraphs :)

Thanks though, in this case I did modify the existing interface, because
adding the second did seem a bit clunky to me but your argument for not doing
so does make sense and it's likely to be the direction I take going forward.

Bill

"Peter Duniho" wrote:

> On Tue, 22 Jul 2008 10:43:02 -0700, wdudek <wdudek@newsgroup.nospam> wrote:
>
> > [...] Does this change anyone's opinion?
>
> Not mine. And I think you could use an occasional paragraph break. :)
>
> Basically, I think that there are times when you can get away with simply
> modifying an existing interface. But I agree with Pavel in the sense that
> I think one should consider those situations carefully.
>
> The usual way to deal with versioning issues like this is actually to
> create a second interface, either as a new version of the old interface
> (so includes both methods) or as a whole new interface (including only the
> new method). You can use casting or "is" and "as" (in C#) to convert a
> reference to the old interface to one of the new interface.
>
> I'm not aware of a better general-purpose versioning mechanism in .NET. I
> wish there were one, but I'm not sure what it would look like :). If you
> have a really good, compelling reason to avoid using the standard approach
> and just modify the existing interface, there are (as I said) situations
> in which that could be justified. But otherwise, I think it's better to
> stick with the "tried and true", clunky though it might be. :)
>
> Pete
>

Peter Duniho

7/22/2008 9:05:00 PM

0

On Tue, 22 Jul 2008 12:15:24 -0700, Pavel Minaev <int19h@gmail.com> wrote:

> [...]
> That was precisely why I went on to explain how abstract classes can
> be used for the same purpose.

I don't really understand your comment. You recommended an abstract class
with an internal constructor, but that assumes (to start with) you are
satisfied with "internal" as an appropriate level of accessibility for the
purpose of hiding the members from other classes.

I'm not going to waste a lot of time debating the point though. The fact
is, there are exceptions to the rule "don't modify the interface". You
can disagree if you like, I don't mind.

Pete

Pavel Minaev

7/22/2008 9:53:00 PM

0

On Jul 23, 1:04 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
> On Tue, 22 Jul 2008 12:15:24 -0700, Pavel Minaev <int...@gmail.com> wrote:
> I don't really understand your comment.  You recommended an abstract class  
> with an internal constructor, but that assumes (to start with) you are  
> satisfied with "internal" as an appropriate level of accessibility for the  
> purpose of hiding the members from other classes.

Yes. I am treating this from a reusable library design perspective
here. Of course, it would be preferrable to have even more fine-
grained control than just "internal", but we have what we have
with .NET.

When considering interfaces that are only used within an assembly and
not outside it (or within a bunch of coupled assemblies which expose
public members just so that they can interoperate, and not intended to
be called from outside that group), the things are obviously different
- if only because you can immediately fix all the classes broken by a
refactored interface.

Peter Duniho

7/22/2008 9:59:00 PM

0

On Tue, 22 Jul 2008 14:53:23 -0700, Pavel Minaev <int19h@gmail.com> wrote:

> Yes. I am treating this from a reusable library design perspective
> here. Of course, it would be preferrable to have even more fine-
> grained control than just "internal", but we have what we have
> with .NET.

And that's my point. One exception to your statement is the use of
interfaces to get around the lack of fine-grained control of
accessibility. An abstract class does not necessarily address that issue
(it also assumes no need for multiple interface implementations, but I
don't think it's necessary to raise that as an issue to provide a useful
counter-example).

Pete

Alberto Gonzalez

4/5/2009 4:23:00 PM

0

"CB" <CB@PrayForMe.com> wrote in
news:49d7b2fb$0$32036$9a6e19ea@unlimited.newshosting.com:

>
> "Alberto Gonzalez" <torture.is.cool@bush.com> wrote in message
> news:Xns9BE3789FABC53tortureiscoolbushcom@85.214.105.209...
>> "CB" <CB@PrayForMe.com> wrote in
>> news:49d6a12c$0$8890$9a6e19ea@unlimited.newshosting.com:
>>
>>>
>>> "sid9" <sid9@bellsouth.net> wrote in message
>>> news:9JSdne1hx7mRH0_UnZ2dnUVZ_sjinZ2d@giganews.com...
>>>>
>>>> "Daniel" <sabot120mm@hotmail.com> wrote in message
>>>> news:6a860e5f-da3b-44d0-9b40-
>> 277c0be0b18e@g19g2000yql.googlegroups.com
>>>> ...
>>>>> On Mar 30, 5:22 pm, Alberto Gonzalez <torture.is.c...@bush.com>
>>>>> wrote:
>>>>>> Daniel <sabot12...@hotmail.com> wrote
>>>>>> innews:8a3e064a-0e3c-4b67-8ba1-103c0986d214
>> @z1g2000yqn.googlegroups.
>>>>>> com:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> > On Mar 28, 11:43 am, Alberto Gonzalez
>>>>>> > <torture.is.c...@bush.com> wrote:
>>>>>> >> Daniel <sabot12...@hotmail.com> wrote
>>>>>> >> innews:822dd6c2-3ba3-4be0-95ff-6f93
>>>>>> > 43bb2...@l38g2000vba.googlegroups.com:
>>>>>>
>>>>>> >> > On Mar 28, 9:29 am, "sid9" <s...@bellsouth.net> wrote:
>>>>>> >> >> "CB" <C...@PrayForMe.com> wrote in message
>>>>>>
>>>>>> >> >>news:49ce1faf$0$17071$9a6e19ea@unlimited.newshosting.com...
>>>>>>
>>>>>> >> >> > "sid9" <s...@bellsouth.net> wrote in message
>>>>>> >> >> >news:gqk824$kpd$1@reader.motzarella.org...
>>>>>>
>>>>>> >> >> >> "CB" <C...@PrayForMe.com> wrote in message
>>>>>> >> >> >>news:49cd8f30$0$4941
$9a6e19ea@unlimited.newshosting.com...
>>>>>>
>>>>>> >> >> >>> "Sid9" <s...@bellsouth.net> wrote in message
>>>>>> >> >> >>>news:-uCdnWFRpoc6-FDUnZ2dnUVZ_vadnZ2d@giganews.com...
>>>>>>
>>>>>> >> >> >>>> "Daniel" <sabot12...@hotmail.com> wrote in
>>>>>> >> >> >>>> message
>>>>>> >> >> >>>>news:4dc32710-c6de-4abc-abe2-dbb06ed4e3b4
>>>>>>
>>>>>> >> @g38g2000yqd.googlegroups
>>>>>>
>>>>>> >> >> >>>>.co
>>>>>> >> > m...
>>>>>> >> >> >>>>> On Mar 25, 12:39 am, RichTravsky
>>>>>> >> >> >>>>> <traRvE...@hotmMOVEail.com> wrote:
>>>>>> >> >> >>>>>> Paulie Walnutts wrote:
>>>>>> >> >> >>>>>> > On Mar 23, 6:29 pm, "sid9"
>>>>>> >> >> >>>>>> > <s...@bellsouth.net> wrote:
>>>>>> >> >> >>>>>> > > "CB" <C...@PrayForMe.com> wrote in
>>>>>> >> >> >>>>>> > > message
>>>>>> >> >> >>>>>> > > > "Lamont Cranston"
>>>>>> >> >> >>>>>> > > > <Lamont.Cranston@He_Who_Knows.com>
>>>>>> >> >> >>>>>> > > > wrote in
>>>>>> >> >> >>>>>> > > >> Daniel wrote:
>>>>>> >> >> >>>>>> > > >>> On Mar 22, 3:53 pm, "Jerky
>>>>>> >> >> >>>>>> > > >>> Fartwell"
>>>>>> >> >> >>>>>> > > >>> <limpball@drug_store.net> wrote:
>>>>>> >> >> >>>>>> > > >>> > "Daniel" <sabot12...@hotmail.com>
>>>>>> >> >> >>>>>> > > >>> > wrote in
>>>>>> >> >> >>>>>> > > >>> > obammy declared victory in his
>>>>>> >> >> >>>>>> > > >>> > speech
>>>>>> >> >> >>>>>> > > >>> > announcing the pullout of
>>>>>> >> >> >>>>>> > > >>> > troops. Next thing you know, dims
>>>>>> >> >> >>>>>> > > >>> > will try
>>>>>> >> >> >>>>>> > > >>> > to credit obammy for
>>>>>> >> >> >>>>>> > > >>> > winning the war.
>>>>>> >> >> >>>>>> > > >>> > =================
>>>>>>
>>>>>> >> >> >>>>>> > > >>> > Bush cut & ran to Crawford
>>>>>> >> >> >>>>>> > > >>> > leaving America
>>>>>> >> >> >>>>>> > > >>> > to sort out his
>>>>>> >> >> >>>>>> > > >>> > disasters one by one and you are
>>>>>> >> >> >>>>>> > > >>> > still
>>>>>> >> >> >>>>>> > > >>> > trying to DEFEND him?
>>>>>> >> >> >>>>>> > > >>> > Shove your Mammy, racist!
>>>>>>
>>>>>> >> >> >>>>>> > > >>> Poor baby. I'm sorry you cannot
>>>>>> >> >> >>>>>> > > >>> accept the
>>>>>> >> >> >>>>>> > > >>> fact that the surge worked
>>>>>> >> >> >>>>>> > > >>> and President Bush won the Iraq
>>>>>> >> >> >>>>>> > > >>> War.
>>>>>>
>>>>>> >> >> >>>>>> > > >> Won? Why are 150,000 troops still
>>>>>> >> >> >>>>>> > > >> there,
>>>>>> >> >> >>>>>> > > >> dumbfuck?
>>>>>>
>>>>>> >> >> >>>>>> > > > Because your buddies would come back
>>>>>> >> >> >>>>>> > > > and fill
>>>>>> >> >> >>>>>> > > > the void.
>>>>>>
>>>>>> >> >> >>>>>> > > > Just as when the grace of God
>>>>>> >> >> >>>>>> > > > departs, Evil
>>>>>> >> >> >>>>>> > > > fills the void
>>>>>>
>>>>>> >> >> >>>>>> > > $10 billion a month.....lost American
>>>>>> >> >> >>>>>> > > lives....and
>>>>>> >> >> >>>>>> > > not a US road or bridge fixed.
>>>>>>
>>>>>> >> >> >>>>>> > > What a waste.
>>>>>>
>>>>>> >> >> >>>>>> > > Eight years of bush,jr all wasted!-
>>>>>> >> >> >>>>>> > > Hide quoted text -
>>>>>>
>>>>>> >> >> >>>>>> > > - Show quoted text -
>>>>>>
>>>>>> >> >> >>>>>> > Sidney. The roads and bridges are getting
>>>>>> >> >> >>>>>> > fixed. You could sleep
>>>>>> >> >> >>>>>> > comfortably in your little singlewide
>>>>>> >> >> >>>>>> > because you knew Bush was
>>>>>> >> >> >>>>>> > keeping you safe. This spineless Jimmuh
>>>>>> >> >> >>>>>> > Cottuh wannabe will get us all
>>>>>> >> >> >>>>>> > killed.
>>>>>>
>>>>>> >> >> >>>>>> Safe? By invading a country that didn't
>>>>>> >> >> >>>>>> need invading, by spreading
>>>>>> >> >> >>>>>> our military thin, weakening it, and all
>>>>>> >> >> >>>>>> with no exit plan?????
>>>>>>
>>>>>> >> >> >>>>> If Iraq didn't need invading, then why did
>>>>>> >> >> >>>>> bj plan to invade Iraq?
>>>>>>
>>>>>> >> >> >>>> Presidents prepare many contingency plans.
>>>>>>
>>>>>> >> >> >>>> Few are acted upn.
>>>>>>
>>>>>> >> >> >>>> bush,jr, a liar, an incompetent, and a world
>>>>>> >> >> >>>> class loser dragged us into Iraq with his
>>>>>> >> >> >>>> lies and left the mess for his successor
>>>>>>
>>>>>> >> >> >>> Clinton told (Larry) King: "People can quarrel
>>>>>> >> >> >>> with whether we should have more troops in
>>>>>> >> >> >>> Afghanistan or internationalize Iraq or
>>>>>> >> >> >>> whatever, but it is incontestable that on the
>>>>>> >> >> >>> day I left office, there were unaccounted for
>>>>>> >> >> >>> stocks of biological and chemical weapons."
>>>>>>
>>>>>> >>
>> http://www.cnn.com/2003/ALLPOLITICS/07/23/clinton.iraq.....
>>>>>> >>h
>>>>>>
>>>>>> >> >> >>>tml
>>>>>>
>>>>>> >> >> >>> opps
>>>>>>
>>>>>> >> >> >> You're confused about dates (as usual)
>>>>>>
>>>>>> >> >> >> When bush,jr the liar attacked it was well
>>>>>> >> >> >> known that there were NO WMD
>>>>>>
>>>>>> >> >> > By gullible and naive Lefties who'd take the
>>>>>> >> >> > word of a mass murderer.
>>>>>>
>>>>>> >> >> > Even the UN Security Council which were mostly
>>>>>> >> >> > Muslim at the time thought knew Saddamn's stash
>>>>>> >> >> > was still in country. Saddamn, under Resolution
>>>>>> >> >> > 4114 was ordered to record the destruction of
>>>>>> >> >> > his known and inventoried VX, Mustard Gases,
>>>>>> >> >> > Anthrax, Risen and other bio-toxins. He did not.
>>>>>>
>>>>>> >> >> > Any sane/rational person would recognize that.
>>>>>> >> >> > Butt you're not, nor are the other commi fags on
>>>>>> >> >> > usenet
>>>>>>
>>>>>> >> >> You lie.
>>>>>>
>>>>>> >> >> When bush,jr went on his ego trip in Iraq it was
>>>>>> >> >> well known though open and unfettered inspection
>>>>>> >> >> that Saddam had nothing.
>>>>>>
>>>>>> >> > The U.N. And Saddam said othwerwise. Thanks for playing.
>>>>>>
>>>>>> >> What a total disconnect. CB says that lefties took Saddam's
>>>>>> >> word that he had no WMDs. And rightwing loopers usually detest
>>>>>> >> the UN. Now here you are holding them both up as reliable
>>>>>> >> sources of info?
>>>>>>
>>>>>> >> BTW, the UN most assuredly did not say that Saddam had WMDs
>>>>>> >> and as for Saddam, well, the fact that you cite him at all
>>>>>> >> shows that you will stoop to any level of hypocrisy.
>>>>>>
>>>>>> > Looks like you're lying again.
>>>>>>
>>>>>> >http://apwanaof.tribe.net/thread/5406c221-2e2a-...
>> 8b81c67962
>>>>>> >8f
>>>>>>
>>>>>> I see. Some guy named Frank posts a blog and you hold it up as
>>>>>> "proof." That's all we need to know about you, isn't it? Was that
>>>>>> really the best link you could find on google? How pathetic.
>>>>>>
>>>>>> Try this one
>>>>>> shit-for-brains:http://www.usatoday.com/news/world/ira...
02
>>>>>> -
>> u
>>>>>> n-wmd_x.htm
>>>>>>
>>>>>> "U.N.: Iraq had no WMD after 1994"
>>>>>
>>>>>
>>>>> Had you bothered to examine the cite, you would have seen that it
>>>>> contained news articles relevant to the post. Ergo, you're an
>>>>> idiot.
>>>>
>>>> Inspectors had found NO WMD when the incompetent bush,jr attacked
>>>> Iraq mired America in an expensive nightmare.
>>>>
>>>
>>> America's Army has and took them out of country so there
>>>
>>>
>>>
>>
>> You are either a scrupleless liar or simply dumber than dirt. Even
>> Bush himself admitted there were no WMDs, nukes or yellowcake. You
>> really do need people to pray for you. Or are you deliberately making
>> righties look bad?
>
> We've been through this, stupid. over 500 munitions have been found
> containing either mustard gas, VX, risen or Anthrax, 500.
>
> Yellow Cake was found, stupid, and moved to Canada
>
> Before you ax foe a 'cite', look it up your self. Hint: don't go to DU
> or the daily kook
>
http://www.snopes.com/politics/war/yell...

You are a tool. Try thinking for yourself once.