1

I had learned sometime ago that abstract classes should always abstract their functions to an interface. So instead of having something like this -

abstract class a{
    public int i;
    public int foo();
}

class b : a{
    public int foo(){return 42;}
}

we have something like this -

interface Ia{
    public int foo();
}

abstract class a : Ia{
    public int i;
}

class b : a{
    public int foo(){return 42;}
}

From my perspective, this is better because of single responsibility, modularity, and maintainability. My colleague disagrees though, and states that there is no perceivable advantage to this and that it only adds to complexity. I tried to find some writing on this topic, but I cant remember the pattern name and my googling hasn't turned anything up.

Is this pattern an actual thing? Was I right to abstract everything as much as I can, or is my colleague correct?

  • 1
  • Discussions like this without a real example tend to generate more heat than light. If one way really were better, some compiler option/warning wouldn't allow you both ways. Oops - maybe there is such an option? – Fuhrmanator Jul 24 '14 at 3:39
  • @Fuhrmanator I just gave an example... and compiler options don't tell you what the "better" way to program is, nor thould they. That would be absurd. – David Grinberg Jul 24 '14 at 11:01
  • By no example, I mean that a and b are not real classes. Telastyn's answer programmers.stackexchange.com/a/250909/51948 gets to the issue when you consider if there are traits or concreteness. With a real example, you could see. Also, regarding compiler options: Your question says "should it always" -- if there was a yes answer to "always", I'd write my compiler to enforce the rule. Good compilers do push us to do things a certain way when it's really better. Many warnings exist just for this reason. – Fuhrmanator Jul 24 '14 at 17:22
  • +1 @Travis comment-link. "abstract classes should always abstract their functions to an interface". By Grapthar's hammer, this shall not pass! It's object oriented Jim, but not as we (should) know it. Resistance is not futile! – radarbob Aug 11 '14 at 23:10
6

You both can be correct. In general, your approach falls under the purview of the Interface Segregation Principle and his falls under You Ain't Going to Need It.

In my experience, it depends on what the interface is. Does it represent a concrete thing, or does it represent a trait of a variety of things?

If it represents a concrete thing, then just leave it as the abstract class. Making it an interface tempts people to multiply implement it, violating the Single Responsibility Principle since you're then mixing your concrete thing and some other thing.

If it represents a trait that is held by a variety of things, then make it an interface. The interface better models the trait and lets a variety of things satisfy the interface.

Don't make interfaces because you're "supposed to". Make interfaces because they properly model your problem domain.

  • +1 Excellent point about making a situational choice based on a thing vs a trait (or perhaps a noun vs an adjective or adverb). All programming rules are situational to some extent. – Mike Jul 23 '14 at 20:19
1

Neither. Abstract classes and interfaces are not substitutable. If your class has a binary operation (that is, it inspects the private fields of another instance of its class), this simply can't be done from an interface (because an interface hides its implementation). This is why, for example, you don't see a union/merge operation in Java's Set interface.

However, if you do need multiple implementations of a type then using interfaces is definitely the better approach when applicable. You can't multiply-inherit classes, so as soon as you need something that has both foo and bar, you're sunk. You can always implement multiple interfaces and reuse behavior with composition.

  • Agreed. Abstract classes and interfaces have specific situations where they should be used. Using them together like this doesn't provide any advantage. If anything it creates code bloat. – Cameron McKay Jul 23 '14 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.