Andrew Binstock, a long time friend of Stelligent, principal analyst at Pacific Data Works, and SDTimes Columnist recently published an article dubbed “BDD Coming to a tool near you” in which he states behavior driven development enables
real communication with the user about the code. For example, you can sit down with the user and capture all the various requirements in a series of scenarios. Then, as you place the needed method calls into the requirements, you have a good sense that your code is indeed matching the stipulated requirements. Moreover, the user can also see that the requirements have been implemented, as each one has matching method calls. This last point is important because it gives the user or manager a way to look at code in a reader-friendly fashion.
Indeed, using the user’s language can facilitate avoiding impedance mismatch between what they ask for and what they receive– in essence, this practice can lead to executable documentation.
Check out Andrew Binstock’s article and don’t forget to check out easyb as well!
July 18th, 2008 at 9:19 am
Hi Andy,
I have been trying hard to post the following comment on your Disco Blog entry ‘Rethinking the traditional DAO pattern’ (http://thediscoblog.com/2008/06/17/rethinking-the-traditional-dao-pattern/), but I can’t get past the spam engine. I can’t find your e-mail address on the blog either. Can you please post the comment for me. Thanks. Here goes:
I have also been looking at the DAO pattern again recently, and so I was pleased to come across your blog entry.
While trying to decide what I thought about your approach, I looked at Core J2EE Patterns, where I first saw the DAO pattern back in 2001.
The book contains a pattern for a domain object: Business Object.
The pattern contains an implementation note on how to achieve persistence of the business object, and one of the options it proposes is uncannily like your approach (I used bold to emphasize one shortcoming of this approach):
You can use Data Access Object to provide your persistence mechanisms for your Business Objects. To do this, create a Business Object that delegates the storing and retrieving of the business data to the custom Data Access Object. Business Object creation is no different than creating any other object. However, when you want to persist a Business Object to the data store, you delegate to a Data Access Object rather than embedding persistence logic in the Business Object. You can also use Data Access Object to retrieve the state for existing Business Objects. While this separates the data access logic from business logic, it is still not a transparent way to implement Business Object persistence, because they have to have knowledge of Data Access Objects. A better alternative to use Data Access Object transparently is to use them via a Domain Store.
While the note does not explicitly say that when a domain object delegates to a DAO, it passes itself to the DAO, it seems implicit to me given that, as Design Patterns says (p20): …with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver.
As for your usage of the Strategy pattern to reduce the domain object’s coupling to DAOs by getting them to use DAO interfaces, it could be argued that even this was to some extent implicitly advocated by the design note in that if the DAOs were implemented following the Abstract Factory strategy, then the return type of DAO factory methods would have been abstract DAO classes, achieving the same effect as your DAO interfaces.