David Bolton Strikes Again

While I applaud the general move towards pragmatic over all encompassing architectures (e.g. REST over WS-DeathStar), it’s worth noting that the often invoked acronym YAGNI, You Ain’t Gonna Need It, does not mean You Shouldn’t Consider It.

That is, when deciding that a particular part of the architecture doesn’t need to be as complicated as some might think, you need to at least justify in detail your reasoning on this point — It’s NOT enough to just say YAGNI and be done with it. In architecture documents I want to see that the ramifications of certain decisions have at least been considered and can be explained, rather than seemingly deemed to hard and thus not worthy of even any thought.

A good quote from Code Complete (Steve McConnell, p.45 of 2nd edition): “One review of design practices found that the design rationale is at least as important for maintenance as the design itself”. That is to say, we want to know why you thought it wasn’t worth spending more time on a particular part of the system, and then we don’t have to assume you’re an idiot!

With a longstanding interest in the architecture and design worlds (as well as an obvious interest in software versions of each), a fashion director fiance, and many creatively rich friends, it hasn’t surprised me to find that I’ve got some level visual sensitivity. But I’d never really pushed myself to appreciate design in the technology world. I’ve owned many boring beige boxes, and the closest I got to design was the beautiful black ThinkPad I had a couple of years ago — though even that was only aesthetically pleasing the same way an army tank is.

Since I switched to a MacBook Pro in the middle of last year, I’ve been increasingly exposed to sensible design. While I’ve owned an iPod for a couple of years, it wasn’t really till I also had the laptop in my clutches that the quality of Apple’s design really became evident to me, and the dearth of good design in the PC world, from the hardware to the software, and in Microsoft’s software in particular, was made clear. Jeff Atwood writes an excellent piece on this: There Are No Design Leaders in the PC World. Then old friend Andre Pang came up with this: Design and Taste in Open-Source Software.

After reading these, I realised that the quality of the experience has become very important to me. I’d always tried to distance myself from enjoying the aesthetics of technology — as a programmer I felt that I should be able to separate the function from the design — but then obviously, if I enjoy programming to a clean API, why shouldn’t I enjoy programming on a beautiful laptop? Or why shouldn’t I enjoy a user interface? My previous stance of “function over form” seems more than a little limiting in my new world view. Now I want function AND form.

(Could be time to update the look of this blog then!)

Found in Renaud Wildura’s excellent guide to the use of Java’s final keyword, a quote from Design Patterns:

Aggregation implies that one object owns or is responsible for another object. Generally we speak of an object having or being part of another object. Aggregation implies that an aggregate object and its owner have identical lifetimes.

Acquaintance implies that an object merely knows of another object. Sometimes acquaintance is called “association” or the “using” relationship. Acquainted objects may request operations of each other, but they aren’t responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects.

It’s easy to confuse aggregation and acquaintance, because they are often implemented in the same way. Ultimately, acquaintance and aggregation are determined more by intent than by explicit language mechanisms. Aggregation relationships tend to be fewer and more permanent than acquaintance. Acquaintance, in contrast, are made and remade more frequently, sometimes existing only for the duration of an operation. Acquaintances are more dynamic as well, making them more difficult to discern in the source code.

A great paragraph from Refactoring To Patterns (italics are mine):

Refactoring embellishments out of a class can produce a design that is simple to those who are comfortable with object composition. To those who aren’t, code that used to be in one class is now spread out across many classes. Such a separation may make code harder to understand since because it no longer resides in one place. In addition, having code reside in different objects can make it harder to debug because debugging sessions must go through one or more Decorators before getting to a decorated object. In short, if a team isn’t comfortable with using object composition to “decorate” objects, the team may not be ready for this pattern.

Its great to see acknowledgement that some teams just aren’t ready for some object oriented designs.  Part of being pragmatic means acknowledging the strengths of your team, not being clever for the sake of showing off.  By all means seek to improve your teams skills, but realise that you can’t force them to understand.  In such cases you need to go with a design that is easily understood, in order for it to be maintainable.

Was reading “Refactoring To Patterns” and came across a great definition for the often misused term “Factory”.

A class that implements one or more Creation Methods is a Factory.

This leads to needing a few more definitions:

• Creation Method – any method (static or non-static) that creates an instance of an object.
• Factory Method – non-static method that returns a base class/interface type for the purposes of facilitating polymorphism.  Implemented by class and one or more subclasses.  Factory Method is NOT a Factory however.
• Abstract Factory – interface for creating related or dependent objects without specifying their concrete classes.  Designed to be substitutable at run-time.  Abstract Factories are Factories.