Is Programming the Art of Making the Right Decision?

If you’ve read my previous blog on using Explicit Locking, you may remember that I wrote some sample code that transferred cash between two random bank accounts using the following algorithm:

IF fromAccount is locked THEN
    IF toAccount is locked THEN
        withDraw money from the fromAccount
        deposit money into the toAccount
    END IF
END IF

You may also remember that this was multithreaded code originally written to create a deadlock. In order to demonstrate Explicit Locking’s Lock interface and ReentrantLock implementation I needed to add a thread locking mechanism to my straight-forward Account POJO and so, the question was: how should I do this?

Defining a Class’s Responsibility - Naming Part 4

Previously, I discussed CRC cards and revealed a big secret in that the crucial thing about a CRC card is that it forces you to explicitly think about and write down your class’s responsibility, and that being able to define a class’s intent in this way is crucial to creating a viable name. I strongly believe that well defined responsibility and a good name equals good software and so, this blog contains a few guidelines that may be helpful.

CRC Cards - Naming Part 3

Another way of specifying a class’s name is to use CRC cards. Proposed by Kent Beck and Ward Cunningham¹, I first came across these many years ago in Grady Booch’s book ‘OO Analysis and Design’. CRC initially stood for Class, Responsibilities and Collaborators, though in today’s single responsibility principal world, Responsibilities has been quietly renamed Responsibility.

Clues from Classification: Naming Part 2

My last blog took a quick look at the fundamental OO rule that states that class names must be a noun. It highlighted the problem that even if you apply it correctly you can still end up with badly named classes and is partly a result of trying to apply the flimsy and lax rules of the English language to the need for precision in software development.

The question is, what are we trying to achieve when we name an object?

What's in a Name? Part 1

One of the things that we all do on a daily basis in our work is to name objects. It’s an activity that we take for granted without ever giving it much thought. It’s also something that we often get wrong and sometimes do badly and there are a couple of reasons for this

Implementing the State Machine Pattern as a Stream Processor

In my last blog, I said that I really thought that some of the Gang Of Four (GOF) patterns were becoming somewhat obsolete, and if not obsolete then certainly unpopular. In particular I said that StateMachine wasn’t that useful as you can usually think of another, simpler way of doing whatever it is you’re doing rather than using it. In order to make amends, both for preaching obsolescence and for the hideous ‘C’ code that I attached to the end of my last blog, I thought that I’d demonstrate the use of StateMachine in converting Twitter tweets into HTML.

The Importance of Questioning

One of the comments my about my last blog Design Patterns, The Emperor’s New Clothes and Catch 22 was that “one of the most valuable things these patterns offer is vocabulary. They give something a name.”, which is an important point that I think I missed. The idea is that once something has a name then it’s something you can easily communicate about. For example, it’s easier to say “I’ve used a Singleton” rather than “I’ve created this class where there’s only ever one instance and that instance is available to all other classes in the application”

Design Patterns, The Emperor’s New Clothes and Catch 22

When writing this blog one of the things I do before I metaphorically put pen to paper is to verify what I’m going to write is correct and I usually do that by either checking a text book or looking on the Internet. Now, my last blog described the Strategy Pattern and, of course I double checked that I wasn’t presenting the Bridge Pattern which has a UML diagram that’s very similarl to Strategy. In doing this it occurred to me that the Gang Of Four (GOF) design patterns have been around a few years (again I double checked Design Patterns: Elements of ReusableObject-Oriented Software by the Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides was first published in 1994) and that over the years these ideas have been copied and republished in numerous blogs and on a multitude of web sites. It then occurred to me that if these patterns have been around for such a long time, then why is it that they aren’t that well known and more widely used on a daily basis?

The Strategy Pattern

In a recent blog on I received a comment from Wojciech Soczyński about how the “strategy” pattern can be used to enforce the Single Responsibility Principle (SRP) when using Tell Don't Ask (TDA). At some point I plan to discuss this further, but first thought that it would be a good idea to define the Strategy Pattern using the ShoppingCart example that I used a couple of weeks ago in my Tell Don’t Ask and its follow up Disassembling Tell Don’t Ask blogs:

Integrating Spring Into Legacy Applications

One of the things that all Spring developers like to do is to shoehorn Spring into any application they work on - it’s one of my guilty pleasures in life: you see some code, think it’s rubbish because it contains several well known anti-patterns and then think how cool it would be if this app was a Spring app.

When working with legacy code, you can’t convert it into a fully fledged Spring app over night, that takes time. What you need to do is to add Spring code a little at a time: piece by piece and there’s one good way of doing that.

Disassembling Tell Don't Ask

In my last blog I defined Tell Don’t Ask (TDA) using a simple shopping cart example. In it the shopping cart was responsible for working out the total cost of the items in the cart as opposed to the client asking for a list of items and then calculating the total cost itself. The TDA example is shown below:

Defining Tell Don't Ask... well almost...

I’ve been wanting to write about ‘Tell Don’t Ask’ for some time now, mainly because it’s often espoused as the ‘right’ way to design a program and I've seen lots of Java code that doesn't use it. ‘Tell Don’t Ask’ isn’t a new idea, it’s been around for some time under other guises: in the OO world I’ve seen it called “Objects Do Things” and a long time ago when I was a Windows SDK C++ programmer it was called “Objects Aren’t structs”.

The big idea is that object A tells object B what to do and object B tells C as shown in the diagram below:

Is Java's String Class a God Object?

In October I wrote a blog entitled Top Trumps in God Objects where I talked about the discovery of an object I’d found with 167 disparate methods that linked this object with all other parts of the application and, as you’d expect, followed the general criteria for a God or Monster Object. It was recently pointed out to me that method count alone isn’t an indication that an object is a God Object

Weasel Words

The other day I had to look into a project’s source code and shocked by the state it was in. I can, hand on heart, say I haven’t seen code like it for 10 years... which made it interesting.

When Object Design Goes Wrong...

There are a good many well documented 'code smells' and 'anti-patterns', but I've always found the following couple of items useful...

OO Revision - a blast from the past

I recently came across this object revision list, taken from Booch's Object Oriented Analysis and Design which I bought in 1995 and referencing OMT. It was written using my previous first language of C++, something I've not used in a good while. It was good to read through it after all these years, giving the critic of time, just to figure out what's changed over the years.