2

I have an abstract base class with an interface.

interface ISubmit {
    bool SubmitFile();
}

public abstract class SubmitMaster : ISubmit {
    public abstract bool SubmitFile();
}

public class SubmitRoute : SubmitMaster {
    public override bool SubmitFile() {
        //...
    }
}

The base class has some other implemented methods used by the child classes, but I need to ensure that each child class has the SubmitFile() method and each one needs its own block for it. Currently, its working just fine, but I feel that what I've done is rather redundant. Do I even need the interface? Or is making the base class and SubmitFile() abstract the wrong move?

What is the best practice in this case?

autowaaagh
  • 123
  • 2
  • 7
  • 1
    http://stackoverflow.com/questions/17278333/abstract-base-classes-that-implement-an-interface May be a good read. It doesn't explicitly answer your question, but it might be something good to help you make a decision. – Jeff.Clark Mar 18 '16 at 22:07

2 Answers2

1

In your case that interface is absolutely redundant.

Perhaps I would still maintain an interface like this if it should be implemented by other classes not necessarily being derived from SubmitMaster abstract class.

Or if the interface is part of your API and you don't need to expose all members of SubmitMaster abstract class wherever you need to use SubmitFile method.

In fact, I could throw here tons of reasons where the interface would be useful, but if you're just defining an interface to implement it in an abstract class, and you never type your references as the so-called interface, then, again, it's absolutely redundant.

Further reading:

Community
  • 1
  • 1
Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
1

What is the best practice in this case? Do I even need the interface?

Are you planning on making, lets say at least three types that have no relation to each other whatsoever, but nevertheless all can be used as ISubmit?

For example, suppose we have an interface that represents a sequence. I can give you a dozen completely unrelated classes that are all sequences. Arrays, lists, dictionaries, trees, blah blah blah, they are all sequences. So we make an interface that represents a sequence, IEnumerable.

If you are not planning on making a bunch of unrelated things that have a usage case in common then don't use an interface.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • I know you don't like it, however Dependency Injection could be a reason for defining an interface even if you don't have "a bunch of unrelated things". – Luca Cremonesi Mar 18 '16 at 23:17
  • @LucaCremonesi: Well if you are not planning on having different implementations of dependencies to inject then what are you fooling around with dependency injection for? That seems like an unwarranted expense. – Eric Lippert Mar 18 '16 at 23:29
  • @LucaCremonesi, why would DI require an interface? Are you talkning about a specific framework? I inject services into classes all the time without using interfaces when there is only one possible implementation. (virtual members solves potential mocking requirements). I know I can use a service factory and I sometimes do but in many cases it is not worth the effort. – adrianm Mar 19 '16 at 07:40
  • @adrianm: I use DI especially for Unit Testing, so that it is easier to test a class that contains dependencies. In this case, having interfaces instead of concrete classes makes the mocking more effective and flexible using a framework such as NSubstitute. – Luca Cremonesi Mar 22 '16 at 18:25
  • "what are you fooling around with dependency injection for?" - As I wrote in my last comment, I use Dependency Injection for Unit Testing with the help of the NSubstitute framework. In this case, it is easier to effectively mock an interface than a concrete class. – Luca Cremonesi Mar 22 '16 at 18:28