Error Tracking Reports - Part 3 - Strategy and Package Private

This is the third blog in a series that's loosely looking at tracking application errors. In this series I’m writing a lightweight, but industrial strength, application that periodically scans application log files, looking for errors and, if any are found, generates and publishes a report.

If you’ve read the first blog in the series you may remember that I initially said that I needed a Report class and that “if you look at the code, you won’t find a class named Report, it was renamed Results and refactored to create a Formatter interface, the TextFormatter and HtmlFormatter classes together with the Publisher interface and EmailPublisher class”. This blog covers the design process, highlighting the reasoning behind the refactoring and how I arrived at the final implementation.

If you read on, you may think that the design logic given below is somewhat contrived. That’s because it is. The actual process of getting from the Report class to the Results class, the Formatter and Publisher interfaces together with their implementations probably only took a few seconds to dream up; however, writing it all down took some time. The design story goes like this...

Tracking Exceptions With Spring - Part 2 - Delegate Pattern

In my last blog, I started to talk about the need to figure out whether or not your application is misbehaving in it's production environment. I said that one method of monitoring your application is by checking its log files for exceptions and taking appropriate action if one is found. Obviously, log files can take up hundreds of megabytes of disk space and it's impractical and really boring to monitor them by hand.

I also said that there were several ways of automatically monitoring log files and proposed a Spring based utility that combs log files daily and sends you an email if / when it finds any exceptions.

I only got as far as describing the first class: the FileLocator, which will search a directory and it's sub-directories for log files. When it finds one, it passes it to the FileValidator.

Producers and Consumers - Part 3 Poison Pills

A couple of weeks ago I wrote part 2 of a short series of blogs on the Producer Consumer pattern. This blog focused upon the need to close down my Teletype’s worker thread, fixing a bug in the original code from part 1 of the series.

The idea here is that the Teletype’s worker thread can be controlled by a command from the application’s main thread. This command tells the worker thread to shutdown thus allowing the app the gracefully shutdown as demonstrated by the code below:

Producers and Consumers - Part 2 - Interrupting Worker Threads

This blog isn’t really about Producers and Consumers, I covered all that in my last blog. If you’ve not seen it then to recap it demonstrates the Producer Consumer pattern using the scenario of commentators reporting on football (soccer) games by putting updates on a queue. These updates are then read back in the TV studio by a Teletype and displayed on the viewer’s TV screen.

Producers and Consumers - Part 1

The Producer Consumer pattern is an ideal way of separating work that needs to be done from the execution of that work. As you might guess from its name the Producer Consumer pattern contains two major components, which are usually linked by a queue. This means that the separation of the work that needs doing from the execution of that work is achieved by the Producer placing items of work on the queue for later processing instead of dealing with them the moment they are identified. The Consumer is then free to remove the work item from the queue for processing at any time in the future. This decoupling means that Producers don't care how each item of work will be processed, how many consumers will be processing it or how many other producers there are. It's a fire and forget world as far as they're concerned. Likewise consumers don't need to know where the work item came from, who put it in the queue, and how many other producers and consumers there are. All they need to do is to grab some work from the queue and process it.

In the Java world, the Producer Consumer pattern is often based around some kind of blocking queue and there are several to choose from. These include ArrayBlockingQueue, LinkedBlockingQueue and PriorityBlockingQueue. Each have slightly different characteristics.

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?

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.

Stuck with the The Inner Platform Anti-pattern?

Just recently our team has received some innocuous requests from the customers: “please can we have a configurable menu here?” or “...this would save us a lot of time”. These, on the face of it, should have been extremely easy to code, but have turned out to be a real nightmare. At first, I put this down to the massive technical debt¹ of the legacy code we’ve inherited, but more recently, after a comment from a colleague, I’ve come to realise that it’s more than that.

Software is Art

I perhaps shouldn’t mention this, but one of my colleagues sent around an email pointing to a very cool video made, I suspect, by a competitor, and saying how good it was. At about a minute or two in, they showed some code and bragged at about their digital services. So, as a diverting interlude, I did a tongue-in-cheek critic of the code in a screen shot....

Maintaining Separation of Concerns when using a JSP Front Strategy MVC Pattern.

My last MVC blog tried to add a little depth into exactly what the MVC pattern is in relation to web-applications, and in writing it I highlighted the problems and pitfalls of using a JSP Front Strategy as an MVC front controller pattern. To sum this up, although favoured by some organisations, it seems to me that using JSP Front Strategy makes it all too easy to mix the controller logic, view information together with the model in the wrong place, which results in nothing more than a plate of indecipherable spaghetti code.

So, I thought that I’d investigate a technique for implementing the JSP front strategy without creating a dog’s dinner and try to sort out a few rules that can be applied if you ever find yourself working on, what is after all, obsolete technology.

Everybody Knows About MVC...

From a recent blog, you may have gathered that I’ve recently been conducting some interviews and as they were for web application developers a question I asked was “can you explain what the MVC pattern is?”, and to their credit, every candidate knew the answer.

Top Trumps in God Objects

If we were playing the children’s game Top Trumps with Java interface definitions I think that I’d win every time. That’s because I’ve just found an interface, which is part of a prestigious company’s public API with with 167 methods. Trump that! Imagine, if the interface definition contains 167 methods, how big is the implementation class? In the words of a texting teenager “OMG”.

You’ll probably know that objects that are as out of control as this are usually called God Objects or Monster Objects and there’s an anti-pattern of the same name which explains it all. If you look on at various definitions of the God Object Anti-Pattern, they usually say a god object is an object that “knows too much or does too much”¹, words which seem to crop up all too often if you dig around the internet. In modern programming speak this generally means that 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.

Spring's Application Context Event System

Spring provides a simple and lightweight publish/subscribe or Observer mechanism built around the ApplicationContext. This is a synchronous mechanism in that the event listener code is called during the call to the publishing code.

If you’ve seen this before, you may not know that this system has been updated in the Spring 3 release to use Generics.

Implementing the Observer Pattern using Composition

When I previously discussed the Observer pattern I recommended following Joshua Bloch’s advice and “favor composition over inheritance” and suggested that the JDK’s implementation of the Observer, Observable, though convenient, was somewhat flawed. This blog demonstrates how to implement the Observer pattern using composition. The benefit of using this technique is that it clearly upholds the single responsibility principle broken in several places by my earlier news server examples.

The Observer Pattern

Having written two blogs that mentioned the Observer pattern, I thought that I’d talk about it more formally, mainly because the Wikipedia entry for this pattern is a bit rubbish: the Java example given doesn’t implement the class diagram shown and uses the flawed Observer, Observable classes instead. Looking back at my GOF Design Patterns book, the actual pattern should be something like this: