Software Craftsmen, Laws and Principles, Oh My

Posted by Jason Smith - 25/03/10 at 12:03:48 pm

Many software developers have written about various Principles and Laws of software development. We talk about things like SOLID, OCP, SRP, LSP, DRY, LoD, and whether these things help or hinder. To outsiders it seems we spend a lot of time arguing the software equivalent of how many angels can dance on the head of a pin.

On the surface Derick Bailey’s blog post and subsequent discussion is a case in point.

There is a reason we believe these things are important. The largest, to me, is that software changes. And anything we can do to make successful change easier is, to a working software developer, the right thing to do.

Derick is a really sharp guy, and I’ve been reading his and other Los Techie’s blogs for some time. In this particular blog, he suggest a particular software technique is exempt from one of our more misunderstood laws: The Law of Demeter (LoD). If I correctly grasp what he’s saying, then I disagree (I’ll be the first to admit I might be misreading him, though).

The LoD is one of those “Laws” or Principles that keeps our code adaptable. It does so by reducing the set of types a body of code is dependent on.

Analogy Time

Think of software as a piece of soft cloth. Like cloth, software with minimal dependencies is extremely flexible — it can be taken from operating system to operating system. It can be built on different architectures. Similarly, cloth is flexible: It can be laid flat to cover a large area. It can be folded to cover a small area. It can be draped over something. Adding a dependency to software is like driving a nail through the cloth into the surface below. The cloth becomes anchored. The cloth can still be laid flat. It can be folded. But it can’t be moved to another area unless we move what it’s been anchored to. Add another nail. Now the cloth can only be laid flat, and can only be folded small enough to include the space between the nails. As we add nails, the ways we can use the cloth decrease. As we add dependencies, the way we can use our software also decreases.

To keep software supple, the LoD seeks to strictly control dependencies — to control the places software is “anchored” to another type. To say the law is exempt because of the syntactic sugar it adds misses the point (and here’s where I may have missed Derick’s point). His example provides the extension methods that give us the following: 

var asset = assets.FirstOrDefault().As<RecordUniqueAsset>();

This is intended to be (roughly) equivalent to the more wordy:

var asset = null;

// I assume some intervening code happens here

if (assets != null && assets.Count > 0)
{
    asset = assets[0] as RecordUniqueAsset;
}

As far as concision goes, the former code is a win. Nothing in the change touches on the LoD though. The determining factor about whether the extension method violates the LoD is almost entirely dependent on whether the original code violates it.

One might argue that the static type that “contains” the extension methods are an additional type (which would violate LoD). I’m not one of those folks. The reason they aren’t an additional type, is (correctly written) extension methods are part of the interface or type they extend.

If you’re willing to read a bit of C++, a great examination on why this is the case can be found in an article written by Scott Meyer (of Effective C++ fame).

That said, any fool can tell you the right number of angels is 42. It’s always 42.

Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds. Valid XHTML and CSS.