Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

share|improve this question

closed as not a real question by Jim G., Eric King, Walter, Yusubov, GlenH7 Nov 26 '12 at 1:32

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.

What if you want to apply paint to something that isn't a car? –  GordonM Aug 15 '12 at 14:26
@GordonM, exactly. The car and anything else paintable could implement the IPaintable interface. And the car (or other IPaintable object) would be passed into the Painter class. –  CaffGeek Aug 15 '12 at 14:28
also check this practical-ways-to-implement-the-srp –  Songo Aug 16 '12 at 8:13

8 Answers 8

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?

share|improve this answer
+1 for mentioning change. –  akuhn Nov 25 '12 at 13:01

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.)

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Separation of Change.


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.

share|improve this answer

This link has a possible design:


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

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.