Tag: patterns

Interfaces with EJB3

Starting last October, we went through a process of upgrading the main application at Wotif to be running under Java EE 5 (not just Java SE 5). The biggest part of this was upgrading from EJB 2 to EJB 3.

One of the things I noticed was that EJB3 gives you a lot of choices for how to implement and configure EJBs and their associated interfaces. There’s a lot of “standards” on how to do it, many of them conflicting, but very little explanation of why. This is the set of standards I came up with (and was largely successful in getting implemented), and why I chose them.

Continue reading “Interfaces with EJB3”

ehcache dissected

At work, we are a heavy user of ehcache. Well, we would be… it was initially written at Wotif, to overcome problems with the Jakarta JCS project. I recently had to sit down and figure out exactly how it works, and thought I’d take a moment to write it up.

*Update*: I tested the Hibernate serialization behaviour. See below for more.

Continue reading “ehcache dissected”

It’s a bird, it’s a plane… it’s a super call?

Martin Fowler wrote about the Call Super smell. This occurs when you are allowed to override a method in a parent class, but you must (as opposed to can) call the parent implementation in your method.

Continue reading “It’s a bird, it’s a plane… it’s a super call?”

Testing pattern: don’t test too much at once

This has been said before, I know, but it’s worth re-iterating: a test should test one thing, and one thing only.

First, some scope definition. Using Kent Beck’s terminology, I’m talking about developer tests, not acceptance tests. Also, by one thing, I mean that there should be only one thing that breaks the test (which is very different from saying any failure should only break one test…). In addition, the one thing that breaks should provide diagnostic information – a test failure shouldn’t leave you scratching your head to determine the immediate cause

Continue reading “Testing pattern: don’t test too much at once”

Interfaces are interesting…

Cedric’s got an interesting post on obtaining extensibility via interfaces As usual, he makes a lot of very good points, and (again, as usual when I link to Cedric’s posts), there are a couple that I think could be elaborated on.
Continue reading “Interfaces are interesting…”

Testing patterns: don’t assert without cause

One thing that I see a lot of with JUnit tests are “cascade failures”. That is, one change causes lots of tests to break. This is often (not always) associated with tests that assert things they shouldn’t.

Continue reading “Testing patterns: don’t assert without cause”

Estimation Anti-Pattern

Name: Precision Estimation

AntiPattern Problem

Developers continually get asked to provide an estimate with a high degree of accuracy. They are expected to spend a fixed period of time to produce the estimate.

Continue reading “Estimation Anti-Pattern”

Creational vs access patterns, and other diversions

A little while back, I blogged about how static and singleton are not synonymous, and one of the things I mentioned in there was the concept of an “access pattern”. This is a term I’ve been kicking around for a while (in person, anyway… I think that was the first time I’d written about it), and I wanted to explore it a bit more here.
Continue reading “Creational vs access patterns, and other diversions”

%d bloggers like this: