• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using inheritance with EJB's - a bad idea?

 
Trailboss
Posts: 23778
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I thought I read something a month or two ago about how inserting your own inheritance into EJB's is a bad idea.
As an example, I might have a SessionEJB class that extends the SessionBean class and adds some convenience methods. And then I might have a HowdyBean that extends my SessionEJB class.
In the article/book/whatever it was just a quick sentence about how it has been agreed upon for some time by EJB experts that this sort of thing was a bad idea. Now I can't find that document and research it further, but the idea is bugging me cuz I've been using inheritance in this very way.
Anybody know why this kind of inheritance might be a bad idea?
 
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have also read about it, but 5 years ago.
It is not only for EJB or for Java, it is general OO "pure substitution principle" or "is-a" vs. "is-like-a" relationships dilemma/argument (for ADA, also).
Addition of additional functions to subclass extends its semantics that contradicts to the fact that subclass is a specialization/specification (of superclass as generalization):. subclass' objects universe is narrower than that of superclass, therefore breaking semantic, "is-a" , relationship. In order to avoid breaking "pure substitution principle", subclass should override only existing in superclass functions without adding its own ones. Otherwise prefer "has-a", i.e. "contains-a", container principle, approach.
Fear not if you are not going to defend your code before Bertrand Meyer!

From Bruce Eckel's "Thinking in Java", 2 ed. (www.bruceeckel.com)
There’s a certain debate that can occur about inheritance: Should inheritance override only base-class functions (and not add new member functions that aren’t in the base class)? This would mean that the derived type is exactly the same type as the base class since it has exactly the same interface. As a result, you can exactly substitute an object of the derived class for an object of the base class. This can be thought of as pure substitution, and it’s often referred to as the substitution principle. In a sense, this is the ideal way to treat inheritance. We often refer to the relationship between the base class and derived classes in this case as an is-a relationship, because you can say “a circle is a shape.” A test for inheritance is to determine whether you can state the is-a relationship about the classes and have it make sense.
There are times when you must add new interface elements to a derived type, thus extending the interface and creating a new type. The new type can still be substituted for the base type, but the substitution isn’t perfect because your new functions are not accessible from the base type. This can be described as an is-like-a relationship; the new type has the interface of the old type but it also contains other functions, so you can’t really say it’s exactly the same. For example, consider an air conditioner. Suppose your house is wired with all the controls for cooling; that is, it has an interface that allows you to control cooling. Imagine that the air conditioner breaks down and you replace it with a heat pump, which can both heat and cool. The heat pump is-like-an air conditioner, but it can do more. Because the control system of your house is designed only to control cooling, it is restricted to communication with the cooling part of the new object. The interface of the new object has been extended, and the existing system doesn’t know about anything except the original interface.
[Figure censored ]
Of course, once you see this design it becomes clear that the base class “cooling system” is not general enough, and should be renamed to “temperature control system” so that it can also include heating—at which point the substitution principle will work. However, the diagram above is an example of what can happen in design and in the real world.
When you see the substitution principle it’s easy to feel like this approach (pure substitution) is the only way to do things, and in fact it is nice if your design works out that way. But you’ll find that there are times when it’s equally clear that you must add new functions to the interface of a derived class. With inspection both cases should be reasonably obvious.


What is "Howdy"?
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have done that several times and haven't had any issues.
Per the FAQ section in EJB Spec 1.1. final release..


..the Bean Provider can take advantage of the Java programming language support for inheritance as follows:
Interface inheritance.
It is possible to use the Java programming language interface inheritance mechanism for inheritance of the home and remote interfaces. A component may derive its home and remote interfaces from some �parent� home and remote interfaces; the component then can be used anywhere where a component with the parent interfaces is expected. This is a Java language feature, and its use is transparent to the EJB Container.
Implementation class inheritance.
It is possible to take advantage of the Java class implementation inheritance mechanism for the enterprise bean class. For example, the class CheckingAccountBean class can extend the AccountBean class to inherit the implementation of
the business methods


So I guess it is not illegal at lest ...
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You may want to take a look at this article from the TheServerSide: Inheritance and EJB. It is focused on CMP, but I think it does a fair job of covering many people's complaints on EJB Inheritance in general.
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ajith,
for implementation class inheritance I agree to what you quoted.
But for interface inheritance like the said ...

Originally posted by Ajith Kallambella:
... in EJB Spec 1.1. final release..:
Interface inheritance.
It is possible to use the Java programming language interface inheritance mechanism for inheritance of the home and remote interfaces.


... only the compiler did well, but the deploytool insisted on _directly_ inheriting EJBHome and EJBObject.
Has there been a change on the way to EJB 2.0 spec? I don't know.
Thomas.
 
Happily living in the valley of the dried frogs with a few tiny ads.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic