How can I determine the relationship of a class to properties (Abstract and Interface)

Question

according to Aamir in When to use an interface instead of an abstract class and vice versa?

When you derive an Abstract class, the relationship between the derived class and the base class is 'is a' relationship. e.g., a Dog is an Animal, a Sheep is an Animal which means that a Derived class is inheriting some properties from the base class.

Whereas for implementation of interfaces, the relationship is "can be". e.g., a Dog can be a spy dog. A dog can be a circus dog. A dog can be a race dog. Which means that you implement certain methods to acquire something.

But how about the abilities? Like, "A dog can bark", "a cat can jump", "a snake can slither", where will I put these, in an abstract or an interface?

Memfisto · Accepted Answer · 2016-07-24T20:04:26.500

If you have some common abilities, like move, you can have an interface of those and have the abstract class implement those methods (if animals are the only thing you'll work with, then you wouldn't really gain much by having that interface I believe). If you are having specific abilities that would apply only on certain derived classes, have them implement the interface.

Dog barking seems to be an ability only for a single derived class, why not leave it be implemented by that derived class? Having it in the abstract class would mean all animals would be able to bark, but then again having a dog class implement an interface that has bark in it seem a bit weird if dog is your only animal capable of barking.

Side note: interfaces don't necessarily have to be defined as "can be" relationship.

score 0 · Answer 2 · answered Jul 24 '16 at 19:19

0

The ability to do something would probably be best suited to an interface, unless you are looking to provide some default behaviour if the method is not implemented.

Keep in mind that C# does not support inheriting from multiple classes, but does support implementing multiple interfaces. This allows for some flexibility. Such as this:

interface IBreathes()
{
    void Breathe();
}

interface IMoveable()
{
    void Move(int x, int y);
}

class Snake : Animal, IBreathes, IMoveable
{
    void Breathe()
    {
        ...
    }

    void Move(int x, int y)
    {
        ...
    }
}

For the above example use of abstract classes would be fine, but with large, complex projects it may become quite frustrating to work around the single-inheritance issue.

answered Jul 24 '16 at 19:19

toneo

111
7

Wouldn't it be better to have common things to all animals (such as breathe and move), be a part of the abstract class they are derived from? That way you won't have to have all the derived implement the same interface. – Memfisto Jul 24 '16 at 20:06
This crossed my mind and you could probably argue either way. The main issue is that if you wanted to not include a method in something which derives from *Animal*, you would have to either refactor the entire *Animal* class or write a second *Animal* class. This is trivial with interfaces: you just don't use that interface. – toneo Jul 24 '16 at 20:20
Of course, but some essentials are not likely to change. If they do, you can just re-implement them with a blank method as a worst case scenario. But I agree, adding/removing an interface is an easier solution when it comes to changing the code. – Memfisto Jul 25 '16 at 06:13

score 0 · Answer 3 · answered Jul 24 '16 at 19:25

There's another thing to consider: Your implementation class can implement as many interfaces as you want but you can inherit from only one class directly, abstract or concrete. To put things short: Use interfaces when you can and abstract classes when you have to.

How can I determine the relationship of a class to properties (Abstract and Interface)

3 Answers3