On 13 Apr 2011, at 16:53, Franklin, Matthew B. wrote:
> I envision model objects as simple containers for data, and IMO, making
> them interfaces over-complicates their use within the system. Scott has
> expressed that he prefers interfaces over POJOs, so this thread is
> intended to discuss the issue and build the community's consensus.
Thanks Matt,
>
> To clarify my thinking I present the following example pseudo code to
> demonstrate my preferred pattern:
>
> class Widget {
> String Title;
> String Author;
> ...
>
> //getters & setters
> }
>
> A Widget object is both retrieved from the persistence layer and created
> from data posted by the client. Coming from the client, the creation of a
> Widget instance is obvious and simple with the above approach. If we were
> to have a Widget interface defining the same getters & setters, object
> creation becomes more difficult, as you need a factory (or some other
> method of instantiation) to control what implementation gets created.
I think if its a case of interfaces vs POJOs then I also favour POJOs (I also
write a lot of Rails code...)
However, in Java server applications we rarely have POJOs, but instead have
heavily instrumented classes that interact with the persistence mechanisms and
other framework artefacts.
So a POJO is encumbered with JPA instrumentation such as annotations, queries,
table references and so on. We may as well call these "JPAJOs" rather than
"POJOs"
This instrumentation also makes it harder to understand the role of the class
as part of the domain model of the application. You have to "see through" the
thick layer of stuff obscuring the model. Interfaces are one way of doing this.
If we add another persistence framework - e.g. JCR or NoSQL - then the "JPAJO"
has to be recreated with new instrumentation, and we have to use interfaces and
factories anyway. (We've already discussed here how JPA is our number one
choice but there is a lot of interest in supporting other store types.) So
going with "JPAJOs" without interfaces may not bring much simplicity for very
long.
So that's my thinking here.
>
> On the other hand, I am a big advocate of interfaces for services,
> repositories and any other components that perform actions.
>
> -Matt
>
