This is not really an subject which should be posted in an RPG list,
however I'll try to pitch my view on this subject.
First of all: OO design is (or rather, should be) independant of the
implementing language (Java, .Net, SmallTalk, C++, etc.).
Secondly: Helper frameworks like Hibernate, how to use them? As I
understand Hibernate, you set up the base classes (the actual pieces of
information you may like to store) as low as possible. No business logic
in there, just basic classes; are also known as POJO's. Depending on
your language you can configure Hibernate in your language (in Java SE
5.0 for instance with annotations looking like this: @one-to-one,
@many-to-one, etc.) alternatively (which should work for all languages)
in XML somewhere in the classpath/application path. Then you make sure
that the DAO requests the objects through the correct Hibernate classes
transaction object API and Bob's you're uncle.
The basic question was how to incorporate things like addresses into
other objects, how to setup the inheritance tree for this? The thing to
remember here is that as soon as you are trying to mix up objects
through the inheritance tree you run the risk of creating dual (triple,
quadruple) inheritance constructions which is not always supported in
all languages (e.g. Java only supports single inheritance). So although
designing a multiple inheritance tree is not formally forbidden by
OO-design, it can limit you in the implementation phase.
So what to do then: well, don't inherit. By setting up address, phone
and what have you objects and not inheriting but incorporating it into
your object and having the incorporating objects implement certain
interfaces (Java for a fact allows an object to implement interfaces
unlimited) you can force an object to implement the API for the
address-, phone-, or whatever other methods. This lets the incorporating
object act as a facade (allthough I might be mixing up design patterns
here) to a multitude of other objects which are contained in it.
So the tree could look like this:
+-------------------+
| addressobject |---------has a---+
+-------------------+ |
|
+-------------------+ |
| phone object |---------has a---|
+-------------------+ |
| +----------------+
+-------------------+ |---| customer |
| addressable I |-----implements--| | object |
| interface | | +----------------+
+-------------------+ |
|
+-------------------+ |
| phonable I | |
| interface |-----implements--+
+-------------------+
Now that sort of solve a situation where a customer object has a single
address and a single phone. What if the customer object has more than
one address or more than one phone number? What if a customer has a
delivery address, a postal address and a visitors address?
In that case you will need an additional 3 objects which all implement
the addressable interface called a "delivery address object", a "postal
address object" and a "vistors address object". And all of these three
objects will be contained in the customer object. In that case the
customer object no longer implements the addressable interface; this
responsability (of implementing that interface) is delegated to the
objects which are contained in the customer object. Effectively you'll
end up writing the following code: (in Java in this case)
customer.getDeliveryAddress() which will give you a reference to the
delivery Address Object and you can do the addressable things with that.
Using Hibernate you will not be bothered with how and when to store it
in the database, since Hibernate will keep track of the fact that the
object is changed or not (assuming all has been set up correctly).
Now the question "where are the business rule stored?". That depends on
what you call the business rules, the fact that a customer has 3
different addresses could be seen as part of the business rules. That
however is up to the designer, but by keeping the previous approach, you
are pretty close to a business rule layer, where the database layer (or
persistance layer) is completely delegated to the Hibernate
framework/layer. Notice that I have not even touched the presentation of
the objects to a document or screen... so well, I hope I can conclude
that I have just scraped the surface of the business rules layer setup.
It all boils down to not trying to use inheritance too much. Of course,
my customer object as described above may have appeared much too soon in
the inheritance tree, there might be one or two abstract objects
appearing in the tree before a customer, supplier, employee object
appears, but for the sake of giving an example (and my view) quickly and
simply I think this will do.
Kind regards,
Cor
-----Original Message-----
From: rpg400-l-bounces+cor.takken=logicacmg.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+cor.takken=logicacmg.com@xxxxxxxxxxxx] On
Behalf Of Walden H. Leverich
Sent: vrijdag 26 oktober 2007 1:37
To: RPG programming on the AS400 / iSeries
Subject: RE: Objects and such
Paul,
Well, our experience applies more to .net than Java, but regardless the
same issues apply. As I understand POJOs, there is no functionality in
the POJO, it's more like a struct than a class. :) All functionality is
offloaded to other helper classes, be they things like Hibernate, or
custom-built class factories. If I understand it correctly, then we're
not really using POJOs, as our businessobject base class handles
database io and we've got business methods on the classes.
What you're describing isn't really a class as much as a collection of
fields. It's much closer to the Associative Data Model described by
Simon Williams (a founder of the venerable AS/400 case tool company
Synon, BTW), see (
http://www.lazysoft.com/_preface.htm)
How do you put business rules into your objects? Say something like:
Database db = Database.GetDatabase("DBName"); //Loads database
definition from SQL table DBBackup backup = db.NewBackup(); //Gets me a
new backup.
backup.Type = DBBackupType.Full; //I want to do a full backup
backup.Run(); // So do the backup already if (backup.IsSuccessful) //Did
it go well?
//send a nice email
Else
//Set off alarms.
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
midrange.com
