When should I create a base class and subclasses that work similarly, as opposed to a single class?

Question

So, a situation's come up at work today while refactoring my codebase. I have two classes that each derive from the same base class. The only significant difference between them is what they do at the beginning - one plays an array of audio files, while another plays just a single file. Each has a different set of audio files. The base class prescribes that some sort of auditory introduction is played at the beginning.

I could possibly just make an audio array and put it into the base class. The question is should I?

To be more generic, when should I create a base class and have classes that derive from it and that follow the Liskov substitution principle, as opposed to just having a single class that does whatever those subclasses would have done?

Answer 1

• Start with a common interface. The interface allows the caller to treat your class as an abstraction, meaning that you can change it without impacting the caller.
• Implement the interface in the simplest way possible that will work for you for now. Probably single class.
• If your needs change, refactor the class. You can even split it into two, or three, or five.
• Throughout the process, keep interface compatibility so the caller isn't impacted by your changes.

Answer 2

The spontaneous answer would be that "one audio file" is just a special case of "many audio files", and that the simplest solution would be to merge both classes with a collection, and perhaps an additional constructor to account for the case where there is only one file. So one and only one class.

However the difference may be more subtle. Maybe the class with one file is not allowed to have more than one file. Maybe it's not allowed to have no files. Maybe some behavior changes (e.g. looping on the single file, vs. playing the files successively and stopping). or there are additional responsibilities. In this case, you would opt for a base class and a derived one.

P.S: if your language has explicit interfaces or protocols, John Wu’s answer is the one to chose. If you’re in a language with only implicit interfaces (e.g. C++), creating a third pure abstract class to emulate an interface could be overkill in this specific case, where there seems to be a lot of common behavior

Answer 3

Having two classes instead of one is added complexity. Having one class that can be configured to do two different things is added complexity. You decide which is less costly.

If you have one class handling a list of objects, and another class handling one object - is there a difference if the first class has a list with one file only? If behaviour is the same, use that class only.