CODEWITHSUNDEEP
c#.netinterface
Y.S
Y.S

Reputation: 1862

Prevent implementation of method that is not an interface method

Is it possible to prevent implementation of public non interface methods in a class that implements an interface?

E.g.

    public interface ICanDoSomething
    {
        void CanDoA();

        void CanDoB();
    }

    public class Doer : ICanDoSomething
    {
        public void CanDoA()
        {
            //Do A
        }

        public void CanDoB()
        {
            //Do B
        }

        public void CanDoC()
        {
            //Don't do this!!! it's not defined in the interface!!!
        }
    }

Just to clarify, I would like to prevent it at compilation time, not at run time.

Upvotes: 3

Views: 2173

Answers (2)

Dmitrii Bychenko
Dmitrii Bychenko

Reputation: 186688

Technically, you can't prevent CanDoC() declaration, but you can do it useless via factory method and internal implementation:

// interface is public when its implementation is internal
internal class Doer : ICanDoSomething {
  // To prevent creating Doer as Doer
  protected internal Doer() { // or internal
    //Some staff if required
  }

  public void CanDoA() {... }

  public void CanDoB() {... }

  // Technically possible
  public void CanDoC() {... }
}

public static class DoerFactory {
  // ... create instead Doer as ICanDoSomething instance
  // (factory method)
  public static ICanDoSomething Create() {
    return new Doer();
  } 
}

...

ICanDoSomething test = DoerFactory.Create();

test.CanDoA(); // OK

test.CanDoC(); // Compile time error

(test as Doer).CanDoC(); // Compile time error when called in an assembly other than Doer

Upvotes: 3

Matías Fidemraizer
Matías Fidemraizer

Reputation: 64923

If C# would be able to do what you want to achieve, the language itself would destroy one of object-oriented programming features: encapsulation.

Let implementers implement your interfaces their own way and focus on quality of interface implementations rather than putting your effort on don't implement more methods than ones defined by the interface (i.e. implement an unit/integration test that implementers should pass to certify that black boxes actually work as you expect).

When you use interfaces you get black boxes: you don't care about how an implementation does the job, but you care about if it does the job right.

Taken from some comment you added in your own question:

No specific use case, just want to direct those who use libraries to component oriented functionality and avoid god objects.

You want to avoid god objects but you want god methods. Everyone will always prefer a class which has a good separation of concerns and segmentation rather than see 3 methods with 1k code lines each one.

OP said...

What about breaking the single responsibility principle? If a class implementing an interface suddenly starts doing stuff which can easily be a responsibility of other class, isn't it breaking OOP as well?

No, single responsibility principle isn't tied to the definition of object-oriented programming (i.e. inheritance, polymorphism and encapsulation) but it's about code quality.

Code quality can't be ensured with interfaces nor using any own programming language construct. This is the mission of code review.

Of course, automated testing ensures that code will run with quality, which is different than coded with quality.

Upvotes: 5

Related Questions