On Performance

Vlad commented:

You mentioned that performance could be improved with this approach, but I'm not
sure how - since this approach involves asking the database for all the records
and then filtering them usig the specs. Using toplink expressions, one can take
advantage of indexes on the database tables and the syntax is quite similar to
specs, so one gets the same kinds of benefits in terms of code duplication. I'd
love to see a posting about performance tuning these spec objects.

Performance for us was not over the database, but the number of times we were looping over the MeasurementPointCollection. Many of our common calls would loop over the measurement point collections two to three times. We saw about a 5% speed up in the tests using the Specification. Not a lot, but something.

Earlier in the project we used Home (Repository Pattern) calls to load the measurement points from the database. We found loading them once and reusing them much faster than using the database. (I think we halved the time the tests took). This is fairly common. (See Fowler PoEAA p.40, Toplink performance http://www.javaperformancetuning.com/news/interview030.shtml. In particular, read the question: What are the most common performance related mistakes that you have seen projects make when developing TopLink applications?)

Specification Objects

Domain Driven Design by Eric Evans has several patterns mixed in it, among the ideas about how to leverage the domain in development.

One of the patterns is the Specification pattern. For me, it's primary benefit has been to reduce code duplication when you're using collections, and need to find subsets of the objects in those collections, depending on various Criteria.

For our project we have this problem in spades, with contracts and measurement points.

Sometimes we want to find all Sales contracts. Sometime we want to find an Oil Contract. Sometimes we want to find Oil contracts that are also Sales contracts. We have many many dimension on our contracts, and need to slice and dice them many different ways.

Our original implementation looked like this:

findAllSalesContracts
List results = new List
foreach contract in getContracts()
if contract.isSales
results.add(contract)
return results

findAllOilContracts
List results = new List
foreach contract in getContracts()
if contract.isOil
results.add(contract)
return results

findAllOilSalesContracts
List results = new List
foreach contract in findAllOilContracts()
if contract.isOil
results.add(contract)
return results

See the duplication, the repeated code? Imagine 4 or 5 conditions. This gets unmanagable.

Now here's a Specification Implementation:

class OilSpecification
isSatisfiedBy aContract
return aContract.isOil

class SalesSpecification
isSatisfiedBy aContract
return aContract.isSales

class ContractFinder
findAll(Collection, Specification)
List results = new List
foreach element in collection
if Specification.isSatisfiedBy(element)
results.add(element)
return results

findAllSalesContracts
return ContractFinder.findAll(getContracts, SalesSpecification)

findAllOilContractsList
return ContractFinder.findAll(getContracts, OilSpecification)

findAllOilSalesContracts
return ContractFinder.findAll(getContracts, SalesSpecification.and(OilSpecification))

Removed several hundred lines of code from our application.

Denis and ClearStream

ClearStream was one of the companies I have seen where the words the "we're a family" was true.

Denis has taken care of his employees through thick and thin, and they have been good friends to him. When he spoke of them to me it was always with fondness and pride. Those who had left he always appeared to have hope they might return, while proud of their current successes.

My sympathies go out to Greg, Gerard, Jennitta, Ralph and Shaun who all form part of the ClearStream family.

Denis and Calgary

A few years ago Tom and Mary Poppendick came to Calgary and in one of my conversations with them, they marvelled at what an agile community we had. It was unusual.

One of the reasons for that community is Denis. Denis created a business in new ideas and new ways of doing things. ClearStream is not a body shop, it is more. Denis' business sense made it possible to assemble some of the best people in the city and introduce innovative ways of developing on many different projects.

In the past he has helped his company introduce Smalltalk, Objective-C, object oriented development and now Agile development to the community. He brought the people together with the ability and turned it into a viable business. His companies innovation has pushed other bigger companies like IBM, Telus, CGI to adopt new techniques and practices faster than they normally would.

Denis helped form our agile community. Thanks.

Denis Clelland

Denis was a great friend. If you knew him you very quickly thought the same thing.

My own relationship with Denis began as a business relationship. It very quickly became warm and friendly. Denis was genuinely interested in me personally. He did that with many people.

Denis was easy to trust. I could tell him lots and bounce ideas off him. He'd tell you about his experiences. Not "condescending" or "teaching", sharing. He was interested in my ideas, thoughts, family. He shared his with me. It was a friendship.

Friendship and business went hand in hand with Denis I don't think he could have one without the other.

I miss my friend deeply.