This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Specification doesn't mandate any design patterns to be used in general. It may be up to the vendor to decide which pattern to be used (there can be the same pattern used by all vendors to solve a similar problem or not). Specification describes standard which is to be used by the developers and is implemented by the vendors.
I agree with you. But what i wanted to know is , How Interface based programming is related with EJB. I know EJB uses Interface based programming. But what really matters for me is how it is being achieved?
Now no more Interfaces required in EJB 3.1.
the idea of interface-based programming which is clearly a useful technique in writing Object Oriented, unit-testable applications.
However, having to replicate the interface methods in the class is often an annoyance; moreover, it takes more time to review your applications because using any IDE you need to climb from the Client view to the EJB interface and then to the implementation class.
reference :- http://www.mastertheboss.com/java-ee-16-articles/219-ejb-31-tutorial.html
and can be accessed this way
@EJB(mappedName = "TestEJB /no-interface")
Mr sujeet khandelwal
Joined: Dec 21, 2011
For your question "what really matters for me is how it is being achieved?"
See there are 3 things... Business Interface, Business class which implements Business Interface and Client code.
- In interface based programming... advantage is Client code is not changed whenever we change code of business class (business logic)...
Once interface is created it is just used for implementation and it is never changed.
Client uses only interface to access EJB's method so client code is also never changed as interface is never changed.
Now class which implements Business interface, business logic can be changed in this class and that will not impact client code as we are can not change method definition.
- Now consider the case where only 2 things we have Business class and client code...
Client uses business class to access methods.
As Business class developer is not aware of client code and while doing changes in business logic if he makes any changes in business method's definition that will surely harm the client code.