mentis vulgaris
simple thoughts | jason smith
Software Craftsmen, Laws and Principles, Oh My
Posted by Jason Smith - 25/03/10 at 12:03:48 pmMany 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.
4 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds.
Valid XHTML and CSS.
you definitely understood my point
you’re right about the point of LoD and that the code within the extension methods is what we are concerned with, not the fact that we have an extension method. I kinda-sort-of-almost hinted at what you’re saying when I said “There probably are scenarios where the implementation of an extension method would violate LoD and thus the extension itself would”… having read the responses of others, and your response here, it’s obvious that i left out some of the more important aspects of the principle and made some sweeping generalizations based on one specific circumstance, again.
great response! it got me thinking more about _why_ i said what i said, and provided some new ideas in understanding LoD.
Comment by Derick Bailey — March 25, 2010 #
“The reason they aren’t an additional type, is (correctly written) extension methods are part of the interface or type they extend.”
I’m struggling to understand what you are trying to convey here. Technically, extension methods are an additional type and are not part of the interface or type they extend. Since I assume you understand this, I’m guessing you mean they are part of the interface or type in the sense that they are part of the overall API available for working with the type.
Comment by Derek Greer — March 25, 2010 #
@Derek –
That’s exactly what I mean.
Much like the free functions of C++ in Meyer’s article, extension methods can be seen as an optional part of a type’s API. And is a technique that improve’s a type’s encapsulation. The reason I don’t call the class in which extension methods are defined “a type”, is because it effectively isn’t — at least, not in a way that matters to a C# (or VB) programmer — it’s neither instantiable, nor inheritable. Instead, it’s a bit of a “language trick” that gives us the ability to define free functions and procedures (the static class is how you define a C# equivalent of a VB Module).
When I say extension methods should be “correctly written”, I mean all the methods in the static class in which we define extensions must only use types available in the api of the type it extends. If we want to introduce extension methods that interact with a type our original class doesn’t already know about, we should create new extension methods in a new static class. By partitioning things this way, we keep our dependencies focused, tight and flexible.
Comment by jason — March 25, 2010 #
@Derick
I thought so — thanks for clearing me up.
–Jason
Comment by jason — March 25, 2010 #