Announcement Announcement Module
No announcement yet.
Spring Tutorial Apparent Contradiction Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Tutorial Apparent Contradiction

    Can someone please clarify this:

    This section seems to contradict itself right off the bat which is confusing, because the Inventory system could not be much easier. Look at the Class diagram and you will see an interface being implemented (PublicManager). Another confusing part of this is that somehow not using frameworks (with implementing interfaces) makes OOP possible once again. Not only does the example have an interface, it seems to be an important part of OO Java programming. The Java language and the Spring framework heavily depend upon interfaces.

    "POJOs are essentially plain old Java classes free from any contract usually enforced by a framework or component architecture through subclassing or the implementation of interfaces. POJOs are plain old objects that are free from such constraints, making object-oriented programming possible once again. When you are working with Spring, the domain objects and services you implement will be POJOs. In fact, almost everything you implement should be a POJO. If it's not, you should be sure to ask yourself why that is. In this section, we will begin to see the simplicity and power of Spring."

    If Services are easier to test when they are interfaces, why make statements that they are usually POJOs? It seems that there will nearly always be a good reason not to implement them as concrete classes.

    "We have chosen to make it an interface instead of a concrete class for an number of reasons. First of all, it makes writing unit tests for Controllers easier (as we'll see in the next chapter). Secondly, the use of interfaces means JDK proxying (a Java language feature) can be used to make the service transactional instead of CGLIB (a code generation library).

  • #2
    There is no contradiction there.

    What is meant here that it frees you from the shackles of implementing interfaces or subclasses from a certain framework, like for instance RMI, EJB, Struts. If you use RMI you cannot reuse the same class for for instance Hessian exposure.

    So the objects are still POJO's because they aren't depending on any framework/infrastructure classes/interfaces to be extended and basically allowing you all the flexibility needed.

    Creating an interface for your service is nothing but good OOD/OOP as it simply states the outside contract of your class (and it doesn't leak anything about the implementation or framework or technology used into the client using that interface).


    • #3
      Thank you for the clarification and for the very quick response!