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:

A Ranking Order for Coding Priorities

In my previous blog I light-heartedly asked whether or not you should tailor your coding style to suit the business domain that you’re working in. The idea is that different business domains will demand different things from their software in terms of coding style. For example, software written for the defence market must be robust as a crash my cost lives, whilst software written for a market that under goes constant legislative changes, such as taxation, must be written for maintainability, and in advertising, where the projects and software lifespan are short then software should be written to be reusable.

Horses For Courses

Over the years I've worked on projects in various problem domains including electricity metering, defence, taxation and banking and, if you've followed my blog over the last year or more then you may have realised that I currently work for an advertising company. In working in the advertising domain the main thing that I've noticed about projects is that they usually have shorter development timescales for a given set of functionality and, once completed, the software's natural lifespan is also fairly short. All of this got me thinking...

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.