Re: Long Life Objects

On Mar 28, 3:37 am, timeisfi...@xxxxxxxxxxx wrote:
Well, you have been taught bullsh8t from excessive OOP zealots. And
RDB's are not just about "persistence". They standardize and package
common attribute-management and collection-oriented idioms, AKA
"reuse".

Thank you for your post topmind. I enjoyed reading your website and
these two extracts in particular are what triggered my original post:

-----Quoted from oop.ismad.com
"Also note that in many cases classifications are given by the users
via an interface, and not done by programmers via programming code.
Accountants build and maintain actual accounting code categories for
example, and not the programmers, except in special cases."

"Users often maintain real-world hierarchies, such as product
categories and accounting codes, via hierarchy edit interfaces, and
not programmers writing subclasses. In other words, the hierarchy
nodes are stored in a database, and not in program code."
-----End quotes

My AddressType and Service categories are indeed given by the users
via an interface and I am struggling to find the 'correct' OO way to
handle them.

I believe that databases are usually a superior tool for user-manged
and/or dynamic "domain things" classification systems (via trees,
sets, graphs, etc.). You can do it in OOP, but often you just end up
reinventing a lot of database-like idioms from scratch. I would rather
focus on domain-specific issues (the user's needs) rather than have to
worry about hand-coding mechanisms for concurrency, indexing,
persistence, searching, sorting, cross-referencing, exporting,
logging, reporting, etc.

If your boss says you must use OO and only OO, then I guess you have
to follow orders. Sometimes reinventing something from scratch is a
fun exercise. I once hand-coded a charting engine (line and bar
charts) because I couldn't get permission to buy an add-on for it and
my work-load was light at the time. Reinvent the wheel I did.

Take Care and Good Luck, -T-

.

Relevant Pages