Manage Dependencies not Aesthetics

The Single Responsibility Principle states that "a class should have one, and only one reason to change."

There is another definition that seems to float around which sounds more like what the name implies: "a class should do one thing" but I think that this definition is more about aesthetics than managing dependencies and leads us in the wrong direction. The "do one thing" definition leads us to things like this:

display.print(person.getAddress().getZipCode());

instead of this:

display.print(person.getZipCode());

//in Person
public String getZipCode()
{
	return address.getZipCode();
}

or even better, this (employing "Tell, don't ask"):

person.printZipCode(display);

//in Person
public void printZipCode(Display display)
{
	display.print(address.getZipCode());
}

Now wait a minute! The Person has a dependency on Display? That's NUTS, right?

---

Disclaimer:
Yes, dependency on Display IS Nuts. There is some talk of this in the comments below.

That said, a better solution with a similar approach would be to use the builder pattern:

public void export(Person exporter)
{
  exporter.setZipCode(zipCode);
} 

That solves the current problem, and solves it for any other representations of the Person's data.

This is really the direction I was headed w/ this article to begin with. I just hadn't put 2 and 2 together with this problem and the builder pattern. Live and learn!

Now, back to our regularly scheduled blog.

---

Well lets look at the implications of all of this.

Imagine that new stories for zip codes come in and we realize that a String representation of zipCode is not sufficient. So we introduce a ZipCode class. Now let's see what changes in the three examples:

In the "do one thing" example, there are two things that have to change:

* The Address class changes its zipCode from a String to a ZipCode, and
* the printing code changes to:

display.print(person.getAddress().getZipCode().toString());

And you can be certain that there are a lot of clients trying to print the zipCode.

In the second example, two things need to change also:
* the Address class changes its zipCode from a String to a ZipCode
* the Person class changes its getZipCode() method to this:

public String getZipCode()
{
	return address.getZipCode().toString();
}

but the likelihood is that there are fewer clients of Address than there are of Person, which means less code will have to change. But this still leaves us with another problem, which is that the zipCode concept is now represented by a String in the pre-existing code but it's represented by a ZipCode object in the newly introduced ZipCode management code.

Which leads us to the third scenario - the one with the crazy dependency from Person to Display. What has to change in that scenario?:
* the Address class changes its zipCode from a String to a ZipCode
* the Person class changes its printZipCode(Display display) method to this:

public void printZipCode(Display display)
{
	display.print(address.getZipCode().toString());
}

Still two things, but very isolated. No clients of Person who want to print its zipCode will have to change AND all the clients dealing with ZipCodes directly will treat them as ZipCode objects, not some as Strings and some as ZipCodes. So while the dendency appears to be an aesthetic violation, it is a lesser violation of SRP than the previous two examples.

Although the principles often seem like they are about aesthetics, they are not. They are about managing dependencies. And managing dependencies should not be driven by aesthetics like "a Person shouldn't know about a Display" but rather by more pragmatic issues like isolating changes.

---

!commentForm