Prefer Delegation to Inheritance

Benjamin Nortier at 21st Century Code Works has a great post exploring of the Liskov Substititution Principle in which he tries to determine if Square “is-a” Rectangle. He rightly concludes that a Square is not a Rectangle as far as development is concerned, whatever may be true in mathematics. (HT: Bob Koss)

I think the improper subclassing that Benjamin discusses usually stems from a commendable effort to reuse code, rather than abstract ontological considerations. Square and Rectangle share a lot of code, so it’s pretty tempting to extend Rectangle. A better way to do this is through delegation.

Let’s assume you have this class:

public class Rectangle {
  public void setWidth(int width) { this.width = width; }
  public void setHeight(int height) { this.height = height; }
  public int getArea(return width * height; }
  public int getPerimeter(return (width + height) * 2; }

Now you need to implement class Square, and it’s pretty tempting to simply extend Rectangle and change the definition of setWidth() and setHeight(). But there is a better way.

public class Square {
  private Rectangle r;
  public void setSide(int side) { r.setWidth(side); r.setHeight(side); }
  public int getArea() { return r.getArea(); }
  public int getPerimeter() { return r.getPerimeter(); }

This approach is superior because it does not violate the Liskov Substitution Principle, yet it still achieves about the same level of code reuse. But that reuse no longer comes at the cost of violating encapsulation.

5 Reasons Standardizing Your Process is a Great Idea

I recently wrote about some reasons that standardizing your development process is a terrible idea. But I’ll admit there are a few reasons that it might be a great idea instead.

Depending on the company you work for, you might need to comply with certain external regulations. At a minimum, you’re going to have to write down what your process is and adhere to that process, which will require some level of standardization. This doesn’t mean you need to document and control every part of your development process; less is probably better in these cases.

I’m sure we’ve all seen the teams where the “Scrum Master” dishes out assignments and treats the daily standups like a status meeting. Whatever that is, it ain’t agile. But as long as they’re using the right words, and in the absence of any standard, what’s to stop them? A standardized process is objective and can be assessed. Standardization will force an organization to actually flesh out what kind of environment and processes the people will use. With some level of standardization, at least there are some rules that teams can go back to when faced with various situations – the temptation to blow off unit tests, pressure to work at an unsustainable pace, etc.

Along these lines, a standardized process can help keep a team from slouching toward mediocrity. It’s nice to think that all developers are highly disciplined and will stick to the best practices they have mastered. But it doesn’t tend to work out that way, and before too long you’ve blown off pair programming, the daily standup takes half an hour, the end of the iteration slips now and then, and nothing is ever “done done”. Woops. A standardized process shows us what the standard actually is, and can be enforced when needed to keep us from mediocrity.

A standardized process also allows certain organizational efficiencies that would be hard to achieve with multiple, constantly varying, processes. For instance, if managers can count on getting the same metrics from each team, each iteration, it will help them be able to recognize problems and respond appropriately. When the system adminstrators know just what to expect from the development teams, and when, it will help deployments go more smoothly. If IPMs, retros, and demos, can be coordinated, it can help stakeholders get to those meetings and avoid scheduling conflicts.

Ultimately, though, the best reason to standardize your process – and the reason most people want to do it anyway – is that it allows the organization to grow and learn. Each team doesn’t have to re-learn each lesson. Newbies can come up to speed on the practices before they’ve really mastered the philosophy. Understanding is important, but it’s not everything. It’s OK to learn by seeing what was successful for others. The danger here, of course, is that the growth and learning never come, and good practices simply become tradition with no underlying comprehension of the motivations or forces involved.

In conclusion, I think some minimal standardization is probably a net good, although I’m not sure it needs to be formalized. Certainly you want a default process for teams to start out with. Any level of standardization must leave room for experimentation and innovation within that process, and can never be a substitute for learning and understanding.

Manifesto for Software Craftsmanship

The Manifesto for Software Craftsmanship has been published. Go read it and sign it!

I’m thrilled to see something like this come out. I know from my own experience the tendency to just hack it and go on, and then the abuse/distortion of agile ideas to justify such sloppiness. Or the atitude that “I’m just a code monkey” that disavows any ultimate responsibility for the overall success of the project.

I look forward to the time when professionalism and craftsmanship are the norm in our profession, just as they are among lawyers, doctors, architects, engineers, musicians, etc.