Architecture Question - Interfaces

[David R]

I have been using gwt for about a year, and I'm new to Spring and
Hibernate.

I got your gwt-ant project to deploy successfully - now I'm trying to
wrap my head around everything that's going on here. Is there a
particular reason (other than leaving open the possibility for
different Customer types) for creating the CustomerInterface and
CustomerDao interfaces?

[Jeremy Przasnyski]

There are two (probably many more) good reasons for using interfaces for objects that are going to have some underlying complexity (Customer is not a good example... I'll talk about this later). CustomerDao is a Data Access Object, which is responsible for persisting Customer objects to whatever back end you want. DAOs typically are something I'd consider to be 'complex objects', which might be a facade to some other system, or proxy, or whatever. The two reasons that I know for creating interfaces for 'complex objects' are: testability (or Test Driven Development / TDD), and aspect oriented programming (AOP).

Test Driven Development (TDD) / Testability:
Let's say you had some object in the system that you want to test. Let's also say that that object has a dependency of a CustomerDao. Rather than have a database-backed CustomerDao, you might want to make a CustomerDaoMock, which implements all methods for a single mock Customer object. You could inject the mock implementation on the object you want to test & not have it use the DB as a back end. The CustomerDaoMock would not require hibernate, a J2EE container, or anything else that the CustomerDaoImpl would require. Interfaces allow you to implement specialized versions of the interface for specific purposes; in the case of Test Driven Development the specialized version would be a 'mock' version.

Aspect Oriented Programming (AOP):
The way I used AOP ( http://en.wikipedia.org/wiki/Aspect-oriented_programming ) in this project is with Hibernate database transactions. You might not realize it, but there are two implementations of CustomerDao. There's CustomerDaoImpl, but there's also an auto-generated proxy created by Spring. The proxy generated by Spring takes care of starting and committing database transactions when the methods on the CustomerDao interface are called. Take a look at Spring's configuration & you'll see what I'm talking about (see applicationContext-dao_template.xml, specifically autoProxyCreator, txInterceptor, and txAttributeSource bean definitions).

Why Customer is currently an interface:
The short-short version is: Customer should not be an interface.
The long version is: The Customer interface was put in place because I was attempting to try and figure out a way not to have to use DTOs (Data Transfer Objects), which are POJOs (plain old Java objects) that are essentially bare-bones versions of the objects they represent. The reason they exist is so that systems like GWT can serialize, deserialize, & make simple client-side JavaScript versions of the objects. I really don't like having to use DTOs, but they are a 'necessary evil' in the case of GWT (at least with a persistence-aware object like Customer is supposed to be). Anyway... I was making an attempt at one point to NOT use DTOs by dealing with Customers using an interface, however none of my efforts succeeded.

Hopefully that answered your questions... or at least gave you some insight into why I recommend using interfaces for complex objects.

Jeremy

--
Jeremy Przasnyski
AIM:jpskiii | Y!:jpskii | GTalk:jeremy.prz