Why do we need to separate classes which have different functionality? [closed]

Question

Why do we need to separate classes which have different functionality? For example, why should we separate a car class from a paint class. What would be the OOD concept behind this? Is there anything else apart from code reuse and modularity?

Answer 1

The principle is that of Separation Of Concerns.

Bob Martin would say - a class should have only one reason to change. That would mean it has a single concern - a single thing it does.

This is a design principle that when followed means that code is easier to change and understand.

In your example of car and paint, it is difficult to say whether they need to be separate or not because there isn't enough context. If you are modelling a car and are also modelling paints, then there would be little sense in having one class having both - would you need to have a car that knows how to mix colors? Or a color that has 4 wheels?

Answer 2

The primary benefit of a good software design (OO or otherwise) is not to save effort through reuse, or to allow a nicer architecture diagram with more modules. Those can be positive side-effects, but they are not the point. The point of having programming constructs that correspond to the real world (or at least to your model of the real world) is to allow the developers to work with the code in the most efficient way possible.

Consider that every program, even the best-designed one in the world, is eventually converted into machine code with no class structure, and even without identifiers. As long as it does exactly what it should, it doesn't matter how well-designed the source code was - the deliverable works, and everyone is happy. But inevitably, the program doesn't quite do what it should, or requirements actually change, and people have to look at the source and change it in a constructive way. The second that happens, a program that has an understandable design is better value than one that works but cannot be easily understood. In other words: good software design practices are mainly for humans - the computer doesn't care whether the opcode stream it executes comes from one class, or from 1000.

(There are also aspects of design that influence the value of software in a more indirect way. A good design can also lead to solving the same task with less resource usage, or with greater robustness to inputs outside the specifically allowed range. But mainly it's about allowing further work to be done on the source code more easily. Highly speed-optimized code can even be much harder to understand, so that those two goals conflict - but usually they should align, and human workability should be way more important.)

Answer 3

The ultimate reason for all software engineering practice is because human intellect is finite. We have to break large software systems into small, relatively independent components because we can only keep so much detail in mind at a time.

Answer 4

It's about cost of maintenance. Difficult to maintain code costs lots of time and resources to maintain.

Small, short, concise, concern-separated code is easier to maintain, hence saving lots of effort ( hence money ) in the mid term.

All applications begin small. But the will grow. And when they do, it's better they do so in an orderly manner.

Answer 5

Well sure. There's also readability and the ability to reason about the code. OOP is often used to model "the real world" which makes it easy for you and I to reason and communicate about objects. If we talk about a car object and a paint object in the abstract, we already both have a pretty good head start on knowing what they're going to do. This isn't true of an "everything" object or a "Car-Paint" object.

Answer 6

I don't think we do. I'm not sure I understand what you are saying, but all the other answers so far talk about modularity and encapsulation. All this is very important and you ignore it at your peril.

But I think what you are considering is Polymorphism. This is where the real power of OOP is. The idea is that an object can be many different things, and you can treat it as any one of them without regard to what the others might be. (I was going to provide a reference, but all that I could find were rather limiting: your question and comment makes a better reference.) Usually this works through interfaces (but don't limit yourself). As you say in a commment, if something implements IPaintable, you can pass it to a Painter regardless of what other interfaces and methods (and properties and ...) it has.

I think you're also talking about "dependency injection" (which I put in quotes because it can have slightly different meanings in different places). This means (at times) changing an object's characteristic by adding or replacing the object that handles that characteristic. Drop in wheels and its a car, replace that with a rotor and it's a helicopter, replace that with a wing/propeller combination and its a plane.

Okay, maybe we do need to separate classes with different functionality, but most of the time classes that look different aren't really different at all, and if you can spot them you can do a lot with very little effort.

Answer 7

Separation of Change.

Really.

It's all about change.

While you will hear others telling you that good OO design is about encapsulation, modularity or even "modeling the real world"—at the end of the day, it's all about change. If things would never change, programming were so much less complex. We'd just write huge monolithic blocks in one go and never come back to edit them. Everything in designing and building software eventually boils down to capturing and managing change. A well designed program localizes changes.

We're speaking of two kinds of change here

• Change at runtime. Well designed objects decompose a system into parts that change often and parts that change rarely. If a domain class has 12 fields and only one of them changes frequently at runtime, chances are you'd better refactor it in two. Same for database tables, whatever.

• Change at an evolutionary scale. As your software evolves, for each new issue, ideally, you'd want to have to apply a very local change only. So again the same rule of thumb, if you have a class of 36 methods and 3 need be updated much more frequently, changes are you'd better refactor it in two. If each of your changes touches the same small spots on the same two dozen flies, again, changes are you'd better refactor all those spot into a new class.

So watch the change velocity of your code and redesign it accordingly as you go.

Answer 8

This link has a possible design:

http://www.cs.brown.edu/courses/csci0150/labs/lab3/index.html

The same stuff has already been summed up by Caffgeek in his comment.