The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

vgendler (10) [Avatar] Offline
#1
Page 84, written:
To do this with jMock, however, we do need to at least define the PendingOrder-
Repository interface and write a stub implementation of PendingOrder.

Why in order to test for one you define an Interface and for another you define a stub Class?

Rod Johnson recomends always program to interfaces.
ceracm (113) [Avatar] Offline
#2
Re: Stub Class or Interface?
I think that it makes sense for services and repositories/daos to have interface+implementation.
* Services - its important to have a well-defined interface for the service's client.
* Repositories/DAOs - keeps the framework-specific DAO code out of the domain model/business logic
* Interfaces let you use regular proxies (instead of cglib) for transaction management etc.

IMHO I don't think its necessary to do this for entities unless the domain model design requires it, i.e. there are multiple implementations of the same interface. Ie. I wouldn't write IPerson and Person since that introduces unncessary complexity.

Are you sure that Rod said *always*?

Chris
vgendler (10) [Avatar] Offline
#3
Re: Stub Class or Interface?
Thank you very much for your explanations.

Rod, of course, used different wording than "always" but still expressed this strongly (good /best programming practice):

Several quotes from his book "Professional Java Development with the Spring Framework":

Chapter 1 / Spring's Values

Spring aims to facilitate good programming practice, such as programming to interfaces, rather than classes


Chapter 1 / Summary

We saw how Spring is designed to promote architectural good practice. A typical Spring architecture will be based on programming to interfaces rather than classes


Chapter 16 / Guidelines for Spring Development / Structuring Applications / Overall Issues

Practice good OO design. Spring is primarily an enabling technology from the design perspective. You are responsible for using a good OO design; Spring is less likely to get in your way than traditional J2EE APIs and the EJB component model. In particular:

Follow best practice by programming to interfaces rather than classes. While, unlike some IoC containers, Spring doesn't enforce this, doing so does make it easier to leverage the full power of Spring's AOP framework. But more importantly, programming to interfaces is an OO best practice that an IoC container such as Spring makes very much easier. You will no longer lose some of the value of using interfaces because you need to code singletons and factory objects; Spring eliminates the need for such code, and you should reap the full benefit

======================================================

Another (earlier) Rod's book "Expert One-on-One J2EE Development without EJB" contains even more repetitions of this his opinion to encourage always use this practice, with more detail explanations.
Here is one excerpt from this book (Chapter 2 / OO):

As well as avoiding non-OO idioms, we should practice OO principles where we can. For example, we
should program to interfaces, not classes. This frees code from dependence on how objects are implemented,
as opposed to the contracts they satisfy. I view concrete inheritance as essentially an implementation
convenience; an object’s concrete inheritance hierarchy is a matter for its implementation, and
normally shouldn’t be publicly known. Loose coupling through programming to interfaces has an enormous
benefit in enabling an alternative implementation of any application object to be dropped in without
affecting code using it. It also has many incidental benefits, such as easier testing and the ability to
use dynamic proxies.

Program to interfaces, not classes. This is a basic OO precept stressed in the classic
“Gang of Four” design patterns text. It’s hard to overestimate its importance.


Developers sometimes prefer classes to interfaces because of a belief that programming to interfaces
adds complexity. This is a fallacy
, so long as we use appropriate frameworks that address the problem of
locating the relevant implementation of each interface.

======================================================

As we can see from this quote Rod will definitely go for interface with your Person example because of other listed benefits.
ceracm (113) [Avatar] Offline
#4
Re: Stub Class or Interface?
Here is another thought.....

Spring is primarily concerned with wiring together components (i.e. statically created services and DAOs etc) and not domain model entities and value objects (i.e dynamically created objects).

Hence all those comments about interfaces pertain to component interfaces.

smilie

Ultimately, perhaps the issue of automatically defining interfaces for domain objects is a matter of personal taste...
vgendler (10) [Avatar] Offline
#5
Re: Stub Class or Interface?
I see. Probably we can do without interfaces for fine-grained domain objects.

Thank you very much - now I understand.