Bad OOP to have lots of classes with only 1 or 2 methods

Question

Is it a sign of bad design where you have lots of classes with only 1 or 2 methods in them?

I am trying to learn OOP design and have created a small application (tiny).

It has ended up with quite a few classes implementing interfaces that contain only 1 or 2 methods.

It feels nicely seperated but it seems bad that the classes have so few methods.

I know each scenario will be different but is this bad from a general point of view?

A small part of the application determines schedules for feeding dogs (lame i know):

So i have tried to implement the strategy pattern here:

class DogFeedController
{
    protected $strategy = null;

    public function __construct(iDogFeedStrategy $strategy) {
        $this->strategy = $strategy;
    }

    public function getFeedingSchedule() {
        $morningFeeds = $this->strategy->generateMorningFeeds();
        $eveningFeeds = $this->strategy->generateEveningFeeds();       
    }

}


class GeneralFeedStrategy implements iDogFeedStrategy
{
    public function generateMorningFeeds() {
        //do stuff here
    }

    public function generateEveningFeeds() {
        //do stuff here
    }
}

Answer 1

You have to measure for yourself if it's too much. OOP is a great way to separate logic in a meaningful and real-world way, but it can also reach a point where it negatively affects maintainability, and at that point it is being applied incorrectly.

Think about where the application is going. Is it always going to be a small app? If so, you don't need to create a lot of very generic interfaces. Try to combine them, and if only one class is implementing the interface, you might be able to remove the interface entirely.

If you anticipate your application will grow substancially, the interfaces might actually help you maintain and add features in the future. For example if you created an application to manage a car lot that only has parking spaces for cars, you might want to create a generic automobile interface if you anticipate growth to different types of vehicles (e.g. motorcycles only take half a parking space). That said, you shouldn't try to cover every conceivable change in requirements at the onset of a project and make the code too abstract. Measuring the risk of change in requirements can help you predict what code needs to be abstracted.

If you're a software engineer on a team, diagram your design and show it to your colleagues to get their opinions too.

Finally, be careful of code smells.