File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark ""A class should change for only 1 reason"" Watch ""A class should change for only 1 reason"" New topic
Author

"A class should change for only 1 reason"

Dan Silva
Ranch Hand

Joined: Sep 05, 2007
Posts: 86
I'm reading the HF OOA&D book, and it said that a class should have only one reason to change. I'm not sure I understand what this means. Does that mean, that in an address book app that I should have a separate class for my 'search' code, and then another one to 'add' an address? Thanks.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi Dan,

this doesn't mean that you should go so far and create a separate class for each method of a program The "one reason to change" means that a class should have one major task. It's methods and the purpose of the class should focus on a small distinct part of you application and not take care about many different things which don't have anything in common.

So for your example it would be surely OK to put the code to search for, add or remove an address in the same class because all these methods are concerned about managing addresses in some way.

Marco
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Marco Ehrentreich:

So for your example it would be surely OK to put the code to search for, add or remove an address in the same class because all these methods are concerned about managing addresses in some way.


"Managing" as a verb is so general that it is a very bad indicator for responsibilities - it can mean virtually anything, all a program does can be described as "managing" something.

I would actually say that adding, removing and accessing addresses is a different responsibility for searching. The former is concerned with how addresses are stored, the latter is concerned with ways to identify whether an address is the one you want to access. So it might be a good idea to actually put the code in different classes. Try it, and see what happens!

What we are talking about here is actually called the Single Responsibility Principle. A good article on that principle is http://www.objectmentor.com/resources/articles/srp.pdf - if you google for the principle, you will find many more resources and discussions of the principle.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

"Managing" as a verb is so general that it is a very bad indicator for responsibilities - it can mean virtually anything, all a program does can be described as "managing" something.


Of course "managing" is a vague description for the functionality of a software. But that was not the point of my answer. I just tried to explain the single responsibility problem like you already said.

Moreover I think it's not possible to reason or discuss about an exact requirements specification with a small description of the problem in two sentences. Questions regarding the perfect design can't be answered in a few words in my opinion. As I said it could be OK to put add(), remove() or search() in the same class of an application but like so often it depends and everybody could argue which is better. But it wasn't my intention to state that these methods essentially have to be in one class. This should be clear for Dan, I hope.

Marco
Dan Silva
Ranch Hand

Joined: Sep 05, 2007
Posts: 86
Thanks guys. I'm founding out why the SCJP leaves design principles pretty ambiguous; There are tons of different opinions, and I guess I have to just find what works best for me.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

That's exactly the point, Dan! It takes some time to learn and despite all experience there will probably be no situation when you can definitely say that you've found the one and only perfect solution regarding the design of an application. Anyway you can always try to reach near perfect

Marco
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
That's actually why they are *principles*, not *rules*. Some of the principles actually are contradicting each other and need to be weighted against each other. Their goal is not give you simple rules, but to inspire your thinking.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: "A class should change for only 1 reason"