Specify member scope in Interface Classes

[aaronh64]

Have you ever noticed that when you look at an Interface Class
definition (ie IDisposable), the methods or properties belonging to the
class are defined as abstract (C#) or overridable (vb)?

How can this be? When I create an Interface class and try to give
methods any signature at all, I receive compile errors. In terms of
scope, all that I can define for method implementation is the return
type, method name, and arguments. I cannot define a method as
public/private, abstract/virtual (C#), overridable (VB), etc.
How did Microsoft accomplish this? You'll notice that pretty much all
Interface classes in the .NET framework have this kind of scope.

Why do I care you might ask? I would like to create an Interface class
and have classes that implement it hide the methods, so that the
interface method(s) implementation is private. A good example of how
the framework is doing this is in the
System.Web.UI.WebControls.WebControl class.

Notice that the class implements the IAttributeAccessor interface,
which defines 2 methods (SetAttribute and GetAttribute). Also notice
that these methods are NOT accessible from WebControl or any inheriting
control, such as TextBox, Button, etc. How did they accomplish this
behavior? As of now, I'm thinking that the 2 methods are marked with
an attribute, but which one?

Any thoughts or ideas as to how they accomplished this would be great!
Aaron Hanusa

 

[Marina]

But, if you cast the WebControl to IAttributeAccessor, then you can call
SetAttribute and GetAttribute.

So, the methods are not really inaccessible after all.

The point of making an interface, is so that someone can cast your object to
the interface class, and call the method, without knowing or caring what the
actual type is.

If the method is private, then no one would ever need to do this - so at
that point, who cares if the method is in the interface? No one but the
class itself could ever call it. Why would it matter in the slightest if it
was in the interface in this case?

 

[Mattias Sjögren]

Aaron,

Have you ever noticed that when you look at an Interface Class
definition (ie IDisposable), the methods or properties belonging to the
class are defined as abstract (C#) or overridable (vb)?

Well the methods are implicitly virtual, and some API browsers may
incorrectly include such modifiers on the methods even though you're
not allowed to explicitly write them yourself.

How did Microsoft accomplish this?

They didn't.

Notice that the class implements the IAttributeAccessor interface,
which defines 2 methods (SetAttribute and GetAttribute). Also notice
that these methods are NOT accessible from WebControl or any inheriting
control, such as TextBox, Button, etc. How did they accomplish this
behavior?

In VB you simply make the implementing method Private.

Private Sub Foo() Implements IBar.Foo

In C# you use explicit implementation

void IBar.Foo() {}



Mattias

 

[Marina]

As to how they did it, I believe this works the way you describe (except
that of course you can still cast the object to ITest, and call the method):

Public Class MyTestClass
Implements ITest
Private Shadows Sub MyTestSub() Implements ITest.MyTestSub
End Sub
End Class

Public Interface ITest
Sub MyTestSub()
End Interface

 

[aaronh64]

Thanks for your reply Marina,

Yes, you are correct, I could cast the object and access the methods
then, but I think you are missing my point. Microsoft achieved the
behavior that I originally posted, and that's what I'm after. How did
they do it? They were somehow able to define the methods as abstract,
or at least have the WebControl define the methods and then hide them.
Furthermore, what if you want inheriting classes that implement the
interface to be able to override that functionality?