"Abstract" interface ?

[Steve B.]

Hi,

I have 3 interfaces in my app in order to allow my app to be extensible.

INode,
IDestination : INode
ISource : INode

I do not want developpers to implement INode, but at least IDestination or
ISource.
The keyword "abstract" is not allowed for interfaces. Is there any way to
reach my goal ?

Thanks,
Steve

 

[jan.bannister]

mark it 'internal'

 

[Steve B.]

No it does not works :

"Error 1 Inconsistent accessibility: base interface 'Core.INode' is less
accessible than interface 'Core.IDest' "

namespace Core

{

internal interface INode

{

string ParentProperty { get;}

}

public interface IDest : INode

{

string DestProperty { get;}

}

public interface ISrc : INode

{

string DestProperty { get;}

}

}

 

[Guest]

None that I can think of.

Interfaces represent contracts. By their very nature, you must expose all
"parent" contracts in an inheritance chain with the same level of exposure.
It is possible to go this direciton:

public interface INode
{
}

internal interface IDestination : INode
{
}

internal interface ISource : INode
{
}

but not this direction:

internal interface INode
{
//Methods
bool Method1();
}

public interface IDestination : INode
{
}

public interface ISource : INode
{
}

There is no abstract keyword for interfaces as interfaces are abstract by
nature (ie, no implementation).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[ernesto bascón pantoja]

I think you should provide abstract implementation of your interfaces like

public abstract class DestinationBase : IDestination;

public abstract class SourceBase : ISource;

and to expose only DestinationBase and SourceBase in your APIs.

Best regards,



Ernesto

 

[Steve B.]

thanks for these answers.... I 'm a little disappointed

 

[larrylard]

Hi,

I have 3 interfaces in my app in order to allow my app to be extensible.

INode,
IDestination : INode
ISource : INode

I do not want developpers to implement INode, but at least IDestination or
ISource.

Any class that implements IDestination or ISource *must* implement
INode. Why does it matter to you if someone implements INode but not a
subinterface? Make your other procedures require IDestination's or
ISource's (with overloading), and you will never be passed a 'plain'
INode.