This blog was first written in August 2007
A few years ago somebody came up to me in one of my classes and said, “you’re the CEO of a successful company, co-author of a successful book (Design Patterns Explained: A New Perspective on Object-Oriented Design), … you ought to have something named after yourself.” So I, of course, immediately like this guy and think – hmm, what should that be? I came up with this:
Shalloway’s Law:
“When N things need to change and N>1, Shalloway will find at most N-1 of these things.”
Hey, I didn’t say it was complimentary. It’s a law! I have to follow it. That’s the problem. BTW: They didn’t ask me about gravity either when I was born! I really would like to break that law at times too!
Eventually I came up with Shalloway’s Principle:
“Avoid situations w
Hey, I didn’t say it was complimentary. It’s a law! I have to follow it. That’s the problem. BTW: They didn’t ask me about gravity either when I was born! I really would like to break that law at times too!
So I came up with Shalloway’s Principle:
“Avoid situations where Shalloway’s Law applies”
Shaloway’s law applied when “N > 1″ and Shalloway has to find all of the things involved. In other words, avoid redundancy (make N=1) or make it so Shalloway doesn’t have to find the things. For example, I may have redundancy in my interfaces. But I also have a cool “to do list generator” (some people call it a compiler) that when I change a method’s interface it tells me what I need to update. Better not to have redundancy at all, but if you do, make sure Shalloway’s law does not apply.
For an in depth view of this, see Shalloway’s Law and Shalloway’s Principle from Essential Skills for the Agile Developer: A Guide to Better Programming and Design.