Hi Kevin,
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin P. Monaghan
Sent: den 8 januari 2001 04:10
To: jBoss
Subject: RE: [jBoss-User] Inheritance in CMP beans - followup
Hi Per:
Two things: 1) CMP 1.1 and inheritance; and 2) your domain (business) object
model.
1) If memory serves, and please correct me if I am wrong, I believe CMP 1.1
does not handle inheritance relationships between persistent business
objects (Entity Beans) well (if at all). Or if it does, it is dependent on
the vendor of the EJB container/app server, i.e. some do and some don't. In
any event, BMP can definitely solve that problem at the price of introducing
more complexity, etc. So, check your JAWS documentation to see how they
implement it in CMP. Sorry I can not be more help here, I am mostly a BMP
guy given the current limitations of CMP 1.1.
Does this mean you would be using BMP to tie to the database and for Motor
specify all fields in the Motor and Product tables as properties for a Motor
EntityBean and then let the remote interface Motor extend Product so that
the getDetails() method would work polymorphically when dealing with a bunch
of various products for a similar situation?
2) (unsolicited advice) You should always design your business objects the
way they really exist in the problem domain. Inheritance is for the
generalization and specialization of both data (e.g. pushing general data up
the inheritance tree) and functionality (e.g. extending or specializing
functionality down the inheritance tree). Don't compromise your domain
(business) object model based on the type of persistence you are going to
use. While I fully admit to being a purist, compromising your domain model
because of a current technical limitation is a really bad idea. It is poor
design and will lead to major changes or forced limitations in your domain
object model when the type of persistence changes, and it will (e.g.
extending past a pure RDBMS solution to a hybrid of RDBMS and LDAP). This is
experience of doing it the wrong way talking...
Thanks for the advice on not compromising good design because of technical
limitations. It seems BMP would not force me to make as much compromising as
CMP in this case. When I started out i first made simple JDBC data objects.
Using these it is easy to call super from Motor and pass the generic
properties to Products but when trying to do the same with entity EJB's
using CMP it is does not seem like a good idea to think about it in this way
and that's why I was asking for other people's experience and suggestion on
this kind of situation.
Regards,
Per
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Per Nyfelt
Sent: Sunday, January 07, 2001 5:27 AM
To: jBoss
Subject: RE: [jBoss-User] Inheritance in CMP beans - followup
So how about a real Is-A situation?
I have motors and pumps that both are products. In the database there is a
Product table with generic attributes like id, serialNumber, price etc.
There is also a Motor and a Pump table with specific data such as
axelDiameter for Motor and length for Pump. The id in the pump table matches
id in the product table.
Conceptually i think of Motor and Pump as extending Product. I have a
business method called getDetails() in Product which returns a Properties
object with its data and override these in Pump and Motor to take advantage
of polymorphism so I can work with generic Products for most of the time in
the JSP's.
If i want to do CMP what would the best way of getting the Motor to also
contain its generic Product data?
I've created CMP entity beans for Product, Motor and Pump and let MotorBean
extend ProductBean and remote interfaces Motor extend Product (and the same
for Pump) but the when doing:
Motor myMotor = motorHome.findByPrimaryKey(key);
I only get Motor properties so I was trying to intercept the construction of
Product by doing super.findByPrimaryKey(key) in MotorBean but I'm running
into issues with finder v.s. create situations. I guess I can figure those
out but I'm not sure this is the way to go.
Any suggestions?
Best regards,
Per
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Shahar Solomianik
Sent: den 7 januari 2001 09: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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
