Bad OOP has many classes with 1 or 2 ways

Question

Is this a sign of poor design in which you have many classes that have only 1 or 2 methods?

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

As a result, quite a few classes appeared that implement interfaces that contain only 1 or 2 methods.

It feels perfectly separated, but it seems bad that classes have so few methods.

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

A small part of the application defines schedules for feeding dogs (the llamas that I know):

So, I tried to implement the strategy template 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 must measure for yourself if this is too much. OOP is a great way to separate logic in a meaningful and real way, but it can also reach the point where it negatively affects maintainability, and at that point it is not applied correctly.

Think about where the application is going. Will it always be a small application? If so, you do not need to create many very common interfaces. Try combining them, and if only one class implements an interface, you can completely remove the interface.

If you expect your application to grow substantially, interfaces can actually help you maintain and add features in the future. For example, if you created a car fleet management application that has only parking spaces for cars, you might need to create a common car interface if you expect growth to various types of vehicles (for example, motorcycles occupy half of the parking space). However, you should not try to cover all possible changes in requirements at the beginning of the project and make the code too abstract. Measuring the risk of changing requirements can help you predict which code to abstract.

If you are a software engineer on a team, draw your design and show it to your colleagues to find out their opinions.

Finally, be careful with the code smells .

Answer 2

From a general point of view, both too large and vice versa too small are considered bad practice and are called the so-called code smells . I mean the Big Class (aka God object) and the Lazy Class (also known as Freeloader).

Here are the definitions from Wikipedia and Coding Horror :

Big class: a class that has become too big.

Large classes, such as long methods, are difficult to read, understand, and troubleshoot. Are there too many responsibilities in the class? Can a large class be restructured or broken down into smaller classes?

and

Lazy class: a class that does too little.

Classes must pull their weight. Each additional class increases the complexity of the project. If you have a class that is not enough to pay for itself, can it be collapsed or merged into another class?

On the other hand, there is the Object-Oriented Design Principle , called the Interface Segregation Principle , which states that "Clients should not depend on methods that they do not use." In your case, interfaces with fewer methods really comply with this Principle.

To summarize the above, your design is pretty much true. Interfaces with fewer methods are good, so classes that implement these interfaces do not have to implement all the methods along with those that they do not use. As for classes, I believe that they will eventually grow. Just remember that implementing an interface does not mean that you cannot have more methods than defined in the implemented interface. That is, try to add more logic there.

More information on SOLID , object-oriented design principles, can be found on Wikipedia .

PS. The Odor Codex is a symptom of poor design, and SOLID is a cure.

Answer 3

I think the question you should ask yourself. Is this class responsible for what it does? The ability to identify and share responsibility is the cornerstone of OOP. You can have a Security class with only one method that creates a random password, for example.

I think (and this is my opinion) that if a random password is used only in the register, instead of creating a private method of this class, I would separate this method from the new Security class, because I do not think that this is the responsibility of the Register class.

Also, since your application is small, it's okay to have several methods for each class.

---

Edit: Having seen your code, I could do some advice, but keep in mind that I do not see the whole picture.

If you haven’t done this, you should read the MVC pattern ; you may not have a view in the application, but sharing controllers with models is good practice.

Your DogFeedController is represented by the controller and GeneralFeedStrategy model. I like to end the names of my classes with what they are. For example, UserController , UserView and UserModel . I think this is all clear, but then again, this is my opinion.

I see no reason to have iDogFeedStrategy , but then again, I have not seen the whole picutre. The main applications of the interface are to ensure that a group of classes, regardless of how different they are from them, will have the same API and encapsulate the details of each class that implements the interface.

Answer 4

Another important aspect of OOP, besides the separation of problems, is class cohesion. A class should “pull its own weight” and not have many other things calling it “getters” and do something with information. Create interfaces if you want polymorphic behavior, or plan to extend your application in the future. Do not create interfaces just for the sake of separation. if the interfaces are not implemented by two or more subclasses, get rid of them. (you can also use interfaces to apply the principle of dependency inversion, to break dependency cycles)

Design decisions in OOP should always be made to consciously solve a particular problem. Otherwise, keep it simple.

Answer 5

Prefer many small objects with complex relationships over several large objects with simple relationships, as this contributes to maintainability and is more prepared for future changes.

Your design looks very good to me, especially since you start programming now, and beginners always do the opposite.