protected interface members

[Steven Livingstone]

I know this is not supported, but i'm just looking for some reasoning and
perhaps debate.
Is there are reason why this is not supported as in the words of manhy a
French poet "it's doing my head in".

I simply wish to break some concrete (and circular) dependencies into
interface dependences and decouple some of my classes. It is an internal
coupling (almost) as i don't want some of these methods exposed to the
outside world, only to derived classes.

However, it may span assemblies so internal interfaces don't work for me.
Public interfaces of course do the job, but i don't want to expose internals
to consumers of my services.

Basically, i want to create an interface for members that can be inherited
in derived classes. But i can't.

steven :: http://stevenR2.com

 

[Andy]

It sounds like you want an abstract class more than an interface.
There's no reason you can't delcare something 'protected abstract' in
your base class.

Is there a reason you need to have an interface over an abstract class?

HTH
Andy

 

[MuZZy]

It sounds like you want an abstract class more than an interface.
There's no reason you can't delcare something 'protected abstract' in
your base class.

Is there a reason you need to have an interface over an abstract class?

It will only be a problem in case of multiple inheritance

 

[Steven Livingstone]

I am "inheriting" from multiple base classes (i'm not of course, but that's
what i'm going for at the interface level) and so i need to use interfaces
(base entities plus some services interfaces). I do have a base abstract
class, but also some some interfaces that state what derived classes should
implement.

 

[Andy]

If you're using .Net 2.0, you may be able to take advantage of the
friend assemblies concept.

You can define an interface with scope internal, then define which
assemblies may see the internals of the assembly containing your
interface. Check out the InternalsVisibleTo assembly attribute.

If you're not in .Net 2, I don't think there's anything you can do at
compile time if you want to go down this route. I'd reconsider how the
classes are split between assemblies and the class design itself.

If your classes are so close that they all must implement the same
method, then they are probably very closely related and should be
decoupled. If your classes aren't that closely related, they shouldn't
care if another class implments a method internally or not.

Andy

 

[Andy]

Opps..

If your classes are so close that they all must implement the same
method, then they are probably very closely related and should be
decoupled.

Should be

If your classes are so close that they all must implement the same
method, then they are probably very closely related and should NOT be
decoupled.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,


The interface is a PUBLIC contract , it's a contract from a type of what it
assure to declare.

From this point of view it's intended to be used from a client perspective.
That's why you cannot declare a protected method, why declare a protected
member in something that is intented to assure the client code what it does
implement?

Now, if you see an interface as a kind of "lite" multiple inheritance, then
it does makes A LOT of sense to allow protected methods, and why not,
private too. in this case it would work as an pure abstract class.
No idea what the consequences this would have though ( I had never thought
about this until now ), once you go down that road you may conclude that is
easier to just implement multiple inheritance.

 

[Joanna Carter [TeamB]]

"Andy" <[email protected]> a écrit dans le message de (e-mail address removed)...

| You can define an interface with scope internal, then define which
| assemblies may see the internals of the assembly containing your
| interface. Check out the InternalsVisibleTo assembly attribute.

Wonderful, another tidbit I didn't know Thank you.

Joanna

 

[Steven Livingstone]

Thanks - decoupled them a bit more and did some extra framework stuff to get
what i needed - kind of.

Sometimes just thinking differently solves the problem, as opposed to my
"there MUST be a way to do this" initial approach

Best Wishes,
Steven

http://stevenR2.com