I Built His Cage

Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!

• The indemniable Martin Fowler has casted forth a technical debt quadrant. The most interesting part of the post is the final quadrant discussed: prudent-inadvertent technical debt, characterized by the sentiment: “Now we know how we should have done it”.

  I think this is by far the most common form of technical debt I experience. In fact, prudent-inadvertent technical debt is the petroleum that fuels this blog. This blog is the relentless pursuit of paying off prudent, inadvertent technical debt. Fowler makes the Brooks-esqe suggestion that teams should plan to throw one away; you will, anyhow.

• Lee Dumond has a superb walkthrough on exception handling in .NET, but the principle applies everywhere. If anything should be taken from the article, it is that you should not handle exceptions that you can’t handle. Log them, sure, but at that point, your application has blown up, and as Lee points out, you are delaying the inevitable if you swallow the exception and act like everything went swell.

  Notifying the user is another issue, and I believe it should be done in as user-friendly a way as possible. My blogging progenitor, Jeff Atwood, authored a model example on how to do this.

• Parts one and two of Helltime-repeatant Giorgio Sironi‘s Invisible To The Eye series on object-oriented myths is largely solid except for the first myth: “You should not expose public fields. Write getters and setters instead”. To wit:
  

  There are some classes which only responsibility is to maintain state. We encounter them in every project, being their names User, Post, CreditCard, String, Regex and so on. It is correct for this type of classes to have getters and setters to change their internal state and fulfill their requirements.

  Sigh. Really? Really? This again?

  OK, technically, this is correct, but for a post that says OO should be explained in context, this excerpt is summarily short. Let’s see if I can explain this quickly enough: yes, some classes do nothing but maintain internal state and have little or no actual business logic, but no, this does not give you blanket license to use getters and setters for everything and reduce your object to a C-style struct.

  Getters are fine as long as they do not couple the callers of these getters to the internal representation of that piece of data. This is the point Allen Holub was trying to make with his flame-bait article on why getters and setters are evil: type-hiding. The same thing goes for setters, except only expose the setters for data fields that can actually change. The other properties should be set via constructors.

  Finally, if you prefer (and you should), the naming of these getters and setters should make your code read as much as an English sentence as you can and make as much sense to a business expert as it can.

  If you have any more questions, please refer to the first year of this blog. Thank you.

  Announcer: You’re reading the EIP web-ring.

  • Share this:
  • StumbleUpon
  • Digg
  • Reddit