Business Objects

ruby-talk
1

A business object is a Class that is unique to a business entity. For
example lets say we have a billing system then we could write an Invoice
business object (class), crude example below.

Invoice
----Date
----Account
----Total
----DeliveryNote
----PickSlipReference

An invoice will contain orders so we write an order business object (class)

Order

-----Date
-----ProductCode
-----Quantity
-----ProductName
-----UnitPrice

Now we could adapt our Invoice class to contain an Orders attribute which is
an array of Order business objects.

An interesting thing that may help you is to read up on the principle of
design by contract, Eiffel (www.eiffel.com) have some OO literature specific
to this. To summarise design by contract states that each business object
should be able to create contracts with each other just like the real
business world, for example Invoice has a business contract with Order. Ther
eis more to it but I wont babble …

Hope this helps …

Graeme Matthew
Analyst Programmer
Mercer Investment Consulting
Level 29, 101 Collins Street, Melbourne, VIC, 3001, Australia
Tel - 61 3 9245 5352 Fax - 61 3 9245 5330
visit http://www.merceric.com

···

-----Original Message-----
From: Yohanes Santoso [mailto:ysantoso@jenny-gnome.dyndns.org]
Sent: Friday, 20 September 2002 9:02
To: ruby-talk@ruby-lang.org
Subject: Re: Business Objects

This is Off Topic, but what’s a business object? Can someone describe
it in plain, programmer language?

TIA,
YS
__

This e-mail and any attachments may be confidential or legally privileged.
If you received this message in error or are not the intended recipient, you
should destroy the e-mail message and any attachments or copies, and you are
prohibited from retaining, distributing, disclosing or using any information
contained herein. Please inform us of the erroneous delivery by return
e-mail.

Thank you for your cooperation.

ec03/04

2

Now we could adapt our Invoice class to contain an Orders attribute which
is
an array of Order business objects.

I will not say this is necessarily the wrong approach, but it is a pitfall
in OO design: You have orders and invoices hence you necessarily have order
and invoice objects.

But it might be the orders and invoices were better off as database records
and what you really need is an order-processing object and an invoice
archiver object. The real inherent objects in the problem being solved are
not always obvious and it is an art to figure them out. There has been
written much litterature on how you can harvest good objects and weed out
bad objects using different strategies. I’m not convinced how well it works
following such strategies as written in a book - but one should seek to find
the nature of the problem somehow - and I guess the best approach is rather
individual.

Mikkel