Internal interfaces?

  • Thread starter Thread starter Anders Borum
  • Start date Start date
A

Anders Borum

Hello!

I was wondering why we're allowed to define interfaces as internal, when all
the members of the interface, when implemented in a class, are made public?

I know that interfaces serve as contracts, but why wouldn't you be allowed
to have internal contracts also, not necessarily exposing the members
publicly? You're not allowed to cast an object to the internal interface,
but I'm unable to keep the members internal.

It's quite annoying as I'll have to introduce extra abstract classes to
achieve the hidden interface members.

internal interface IXml
{
string ToXml();
}

public class CmsObject : IXml
{
.. other members / constructors

public string ToXml() { return null; }
}

... and in another project (assembly):

CmsObject o = new CmsObject();
string s = o.ToXml();
 
Just implement the interface explcitly, then its members are only accessible via an inerface based reference which is only possible if you have access to the interace itself

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

Hello!

I was wondering why we're allowed to define interfaces as internal, when all
the members of the interface, when implemented in a class, are made public?

I know that interfaces serve as contracts, but why wouldn't you be allowed
to have internal contracts also, not necessarily exposing the members
publicly? You're not allowed to cast an object to the internal interface,
but I'm unable to keep the members internal.

It's quite annoying as I'll have to introduce extra abstract classes to
achieve the hidden interface members.
 
Hello!

I understand what you're saying, but could you give me a short example a'la
the one I presented?

Thanks Richard!
 
I think he means this:

public class CmsObject : IXml
{
.. other members / constructors

// Change is here (added IXml and removed public)
string IXml.ToXml() { return null; }
}
 
Hi Rene

Thanks for the example. I was probably thinking about something else, but it
makes sense.
 
internal interface IFoo
{
void Spong();
}

public class Bar : IFoo
{
public void Quux()
{
}
void IFoo.Spong()
{
}
}

inside the assembly I can do this:
Bar b = new Bar();
b.Quux();
IFoo f = b;
f = Spong();

outside the assembly I can only do this:
Bar b = new Bar();
b.Quux();
IFoo f = b; // this won't compile as IFoo is marked as internal

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hello!

I understand what you're saying, but could you give me a short example a'la
the one I presented?

Thanks Richard!
 
Hello!

I follow your implementation, but this means I'll have to cast the reference
each time I'm looking to access the members of the internal interface. Why
this is necessary doesn't make sense to me.
 
Well, you don't have to make the cast all the time, you can add Internal
methods that map to the hidden interfaces such as:

public class CmsObject : IXml
{
.. other members / constructors

// Change is here (added IXml and removed public)
string IXml.ToXml() { return null; }

// Add maping here.
internal string ToXml()
{
return ToXml();
}
}
 
Hello!

Thanks for the example. I think it kind of defeats the whole idea of having
internal interfaces, if you have to provide a duplicate (redundant) internal
method for each of the interface members. Ideally, one would expect the
members to be available internally only..

I don't know if I'm the only one who think this is odd?

I have a concrete situation where I was thinking about replacing a abstract
class (named CmsContext) with an ICmsContext interface. The abstract
CmsContext provides public as well as internal abstract members. I have been
looking a lot on the object model and it seems like I will have to introduce
extra abstract classes instead of the interface approach ..
 
I see your point, unfortunately I think this is a necessary evil, for
example, if you ever have to inherit from multiple interfaces and say that a
method signature repeat on two of the interfaces. How would you tell them
apart? The only way will be to implement the interface explicitly (Fully
qualified: The interface name plus the method name). Not doing so will
create a compile error. This will also mean that you will have to cast the
object to the interface to get a hold of the method, there is no other way.



If the compilers allow you to do what you want to do, and if you ever
inherit two or more interfaces with members having the same name, there
would be no way to resolve the name conflict.
 
Hello!
I see your point, unfortunately I think this is a necessary evil, for
example, if you ever have to inherit from multiple interfaces and say that a
method signature repeat on two of the interfaces. How would you tell them
apart?
Click to expand...

If you have a method signature repeat on two interfaces, you're only asked
to implement the method once (thus covering both interfaces).

interface a
{
string c();
}

interface b
{
string c();
}

public class d : a, b
{
string c() { return null; }
}

The above compiles perfectly. I see your point though, in the case where you
have different access modifiers on the two interfaces. In my case, however,
there are no conflicts as I am 100% in charge of the design.

Maybe I should have asked this to Anders Hejlsberg from the Microsoft C#
design team, when he guested Denmark a few weeks ago.
The only way will be to implement the interface explicitly (Fully
qualified: The interface name plus the method name). Not doing so will
create a compile error. This will also mean that you will have to cast the
object to the interface to get a hold of the method, there is no other
Click to expand...
way.

What would be wrong about the following:

interface a
{
internal string c();
}

public class d : a
{
internal string c() { return null; }
}

I have asked google the same question with little luck and am quite sure
there is an answer to this - I'd like to see it.
 
Good question, other than the typical "Because that's the way it is" answer,
I have no idea. Maybe they didn't want to bother since it is possible to
archive the functionality that you require through other methods?



Personally, the thing that rally ticks me is not having different access
modifiers in a Property, there are times when having a public "get" and an
internal "set" would be kind of nice but did they add that functionality
Noooooooooooooooo.



Cheers
 
Hello!
Personally, the thing that rally ticks me is not having different access
modifiers in a Property, there are times when having a public "get" and an
internal "set" would be kind of nice but did they add that functionality
Noooooooooooooooo.
Click to expand...

You'll be pleased to work with C# 2.0. From what I know, there will be
different access modifiers on the get/set parts of a field. I'm looking
forward to that as well!
 
Back
Top