Hehe lazy is good when it comes to code re-use.

However. Two things you have to remember (and this is also a response to a
later post of yours).

1) EJB is not Java (yeah I know that sounds silly). By that I mean, because
it works in "normal" Java doesn't mean it works with EJB. EJB either
explicitly disallows something (eg manipulating threads) or simply doesn't
specify it at all. Inheritance between EJB's falls into the latter category.
This means that appservers either don't support it or support it in an
entirely proprietary way.

2) Lazy is bad if it means you do it wrong ;-) Java inheritance is *not*
about code re-use (regardless of whether what you do works or not) it's
about "IsA" behaviour (which I know someone has already explained). Java
doesn't have the notion of inheritance for code re-use (in C++ this would be
private inheritance). The problem is that if you use inheritance for code
re-use (and *not* IsA behaviour) then anyone else looking at your code will
assume it was done to express an isa relationship. It would be like taking
the Java Vector class and sub-classing it to give you your class simply
because your class maintains collections of things. Other people will assume
they can use your class to substitute for a Vector if they want... The
better way is to compose the class you want to re-use eg have a member
attribute of your class be of the required type and then delegate to it. Eg

NOT

public class MyClass extends Vector
{
}

but rather

public class MyClass
{
        Vector _myList = new Vector();

        public AnotherClass getSomethingfromMyList(int index)
        {
                return (AnotherClass)_myList.get(index);
        }
}

(Simplified to get the point across).

Also, don't forget that Java only supports single inheritance of classes so
by "using up" your one inheritance.

Finally :-)

Why do you need to implement anything on your remote *interface* anyway ?
That's the container's job.

Edward

-----Original Message-----
From: Shahar Solomianik [mailto:[EMAIL PROTECTED]]
Sent: 07 January 2001 08:49
To: 'jBoss'
Subject: RE: [jBoss-User] Inheritance in CMP beans - followup


Hi Kevin.
Thanks for the detailed, well explained reply.
I thought IsA is initials for something like "Inehritance Structure
Architecture" or something like...

Well, the inheritance discussed is not a IsA...
I just have some entities with same attributes ... (and I am lazy...)

Cheers
Shahar

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin P. Monaghan
Sent: Sunday, January 07, 2001 9:47 AM
To: jBoss
Subject: RE: [jBoss-User] Inheritance in CMP beans - followup


Hi Shahar:

The "Is-A" relationship is all about inheritance, also called a gen-spec
relationship or "generalization-specialization" relationship between
classes. If you are using inheritance correctly, a subclass (the
"specialization") "is a" kind of it's super class (the "generalization").
For example - and I really hate this example but anyone can understand it -
a CheckingAccount is a ("is-a") kind of Account, a SavingsAccount is a
("is-a") kind of account. So, in theory, this is a good candidacy for
inheritance. There is a "is-a" relationship between CheckingAccount and
Account as well as between SavingsAccount and Account.

WRT your comments about OO, real live code reuse (outside of within the
constructs of a framework or architecture-level / system-level components)
may occur but in very small amounts. You have to look at amounts of reuse in
different areas. For example, how much reuse do you get in the arena of
business objects? Maybe not too much. I have been developing OO apps for 10
years now and anything more than a trivial amount of code reuse at the
business object level is rare. Originally, OO was touted as being all about
code reuse, but in reality it is about complexity reduction, flexibility and
extensibility (at the least).

Good luck,


Kevin

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Shahar Solomianik
Sent: Sunday, January 07, 2001 1:57 AM
To: 'jBoss'
Subject: RE: [jBoss-User] Inheritance in CMP beans - followup


Hi all.
Sorry for not being here while you discuss this issue...
I DO want it just for code reuse, nothing else...
The ancestor remote interface will never be deployed as a remote interface,
it will only be derived from.
Could you please explain "inheritance in Java is about IsA behaviour not
code re-use" ? (what is IsA ?)
Object Oriented was originally thought of as a code reuse method, wasnt it ?
(I mean, components and stuff came later, didnt they ?)

Shahar
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kenworthy, Edward
Sent: Friday, January 05, 2001 10:03 AM
To: 'jBoss'
Subject: RE: [jBoss-User] Inheritance in CMP beans - followup


Hi Shahar

Don't do it.

If you have remote interface A and create remote interface B by extending A
then you are saying "I can use an instance of B to substitue for an instance
A". THIS IS NOT TRUE !

EJB does not properly support inheriting of one bean from another. By which
I mean, you can do it, BUT it will not behave as it should. (eg IsA doesn't
work!).

If you don't care about this, ie you are using the inheritance for code
re-use then I would do it in a different way because otherwise you would
confuse people (inheritance in Java is about IsA behaviour not code re-use).
I would do it by factoring out a common base (which is NOT a remote
interface) which both A and B extend.

Edward

-----Original Message-----
From: Shahar [mailto:[EMAIL PROTECTED]]
Sent: 03 January 2001 17:12
To: [EMAIL PROTECTED]
Subject: [jBoss-User] Inheritance in CMP beans - followup


[Hi again]
off course, I also intend to extend the remote interface. Possible ?



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
List Help?:          [EMAIL PROTECTED]


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
List Help?:          [EMAIL PROTECTED]



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
List Help?:          [EMAIL PROTECTED]




--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
List Help?:          [EMAIL PROTECTED]



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
List Help?:          [EMAIL PROTECTED]


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
List Help?:          [EMAIL PROTECTED]

Reply via email to