隐藏污染代码的基类或接口

Question

this is an issue ive been faced with countless number of times.. consider..

[public/private] interface IBase
{
    void DoCore();
}

public interface IDerived_A : IBase
{
    void Do_A();
}
public interface IDerived_B : IBase
{
    void Do_B();
}

here i have 2 useful interfaces that provide some common functionality (provided by the IBase interface), plus some other functionality unique to either of them.. c# forces me to declare IBase as public (the same visibility as the inheriting interfaces).. however, the IBase interface is visible to everyone.. there is no need for anyone else to use this interface.. ppl only need to access the IDeriver_X interfaces.. how can i hide the IBase interface from the users of my code? there can be two kinds of users of my code..

1. code in the same namespace / assembly accessing IDerived_X..
2. code in a separate project referencing the assembly containing IDeriver_X..

ps.. i hate making more interfaces public than is neccessary (neccessary means only those interfaces that ppl will use directly).. ps2.. i face the same dilemma with classes..

EDIT:

i have a feeling that the question was misinterpreted a bit.. for that im posting a clarification.. the issue isnt just related to interfaces.. it bugs me about classes too.. consider the following code..

public abstract class Vehicle
{
    // generic vehicle functionality
}
public Car : Vehicle
{
    // functionality specific to cars
}
public Truck : Vehicle
{
    // functionality specific to trucks
}

Car and Truck are the ONLY two kinds of objects im allowing the users of my code to use.. to make my job easier, and to avoid dupilcation of code, ive moved the common code to the Vehicle abstract class.. but that doesnt mean its ok for the user to store references to cars or trucks in vehicle variables.. from the perspective of the users, my code should only expose cars and trucks (and not vehicles or engines or whatever base classes i used internally to avoid code duplication).. specifically, im looking for a technique that allows me to expose complete cars and trucks but not any other incomplete building blocks like vehicles or engines.. the problem is, c# doesnt let me make the base classes private if the derived class is public.. does that make more sense? =)

Answer 1

Well,

• either it makes sense that your child interfaces are derived from a base
• or user of child interfaces should not have access to API of a base

In first case, it is reasonable, that consumer of API IDerived_A has access to IBase. In the second do not dervie from the base IBase

Anything else, is tweating OOP.

As a consumer of your interface, I am provided with both IBase and IDerived_A, so it is reasonable that I do have access to IBase

Answer 2

I'm not sure what you're trying to express here(so maybe a description of your complete scenario may help). If your IDerived_A and IDerived_B interfaces ARE IBase s, your client code needs to be able to access DoCore . And having IBase public would allow you to generalize functionality that works the same on types inheriting either IDerived_A or IDerived_B .

If you just want to avoid repeating method definitions in IDerived_A and I_Derived_B but inheritance from your IBase is NOT modelling a IS A relationship (ie I_Derived_A and I_Derived_B don't need to be directly related in a hierarchy but are just sharing some functionality between them) you should probably just create separate interfaces with no hierarchical relation between them, like this:

public interface ICore 
{
    void DoCore()
}

public interface INonCore_A // no more inheritance
{
    void Do_A();
}

public interface INonCore_B 
{
    void Do_B();
}

now the classes in your library code can be requested to implement both ICore and INonCore_A/B . ICore itself may still need to be public (unless you want the DoCore method itself to be only visible to your library code) but you can sort of "hide" it in your classes by using an explicit interface implementation of ICore .

What you lose, in this second case, is a way to tell your client code that implementing INonCore_A requires you to also implement ICore . That functionality exists for instance in the scala programming language but not in C#. If it existed you could say:

// warning: non-existing c# syntax. Does not compile
    public interface INonCore_A {
        self: ICore => // this is scala syntax, does not work in c#
                       // it means "anyone who implements INonCore_A must 
                       // also implement ICore
            void Do_A();
    }

As said, since this does not work in c#, it is down to documentation and programmer's discipline to make sure that whoever implements INonCore_A and B also implements ICore