Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Bob Badour wrote:
> This 'domain logic' to which you refer. What does it do that is not
> entering, manipulating, reporting or deriving data? Of that which
> remains, what does not interface with the external world through some
> device or another?

I'm guessing a little here, but I reckon we're going to run into the "Business Logic Layer" here. You know, the one between the "User Interface Layer" and the "Persistence Layer".

Warning. Rant follows.

<rant>
I used to think it was me. I really couldn't figure out what I was missing with OO. What was the big deal, compared to abstract data types allied to modular programming ? I'm finally coming to the conclusion that the reason I couldn't figure out what I was missing is perhaps because *there's nothing to miss*. OO seems to be a complexity mill to take even the simplest requirement and turn it into a monster, and worse, a myopic monster that fails to take into account other world views than the "object model" the designer came up with that day, a monster with APIs here, layers there, an ORM lurking in the corner, maybe even an ORB hanging around somewhere, value objects for this'n'that, and hey, we need a configuration file so in lumbers XML, and all of this just to manage assignment statements nicer. Oh, and God help us if we ever have concurrent access to a non-synchronised variable.

And underneath all of this, what ? A formal model ? Anything we can reason about in strict, precise mathematical terms ? Don't be daft. OO is all about experimentation, throwing things at the wall to see what sticks ! I was struck in an earlier sub-thread by the difference between what some consider "object oriented" languages and "class oriented" languages. It reminded me fleetingly of the banter we have on c.d.t. - "Oracle isn't a relational database, it's an SQL database !" "Java isn't an object oriented language, it's a class oriented language !" The difference, the big difference, the huge difference that makes all the difference in the world, is that we have a formal, precise reason for our arguments - the OO community just have a pile of fuzzy lumps of contradicting prose, with no real hope of a formal, precise statement of principle or intent. Look at the work that's gone into the relational model over the last 30+ years - it's taken some missteps, things have been added - but the real trajectory of thinking in RM is to clarify and if anything prune back and remove supposed restrictions to a precise, simple (but not trivial), clear view on what the RM is and what it means. What hope for OO in following any similar path ? None, so far as I can see - even with "aspect oriented programming" looming into view.

I admit, it was embarrassing in the '90s to still admit that the majority of the world's code was in COBOL. But did we really have to try changing that ratio by generating mountains of boilerplate Java junk for even the simplest of applications ? </rant>

Ok, so I exaggerate. There's a bit of hyperbole in there. It was a bit of a vent. You know, I'd love the scales to fall from my eyes, to see the bright new future in OO programming. Enough people I know whose opinions I generally hold in some regard seem to look kindly on it. But I just can't get past that, as currently constituted, it all still revolves around managing variables and assignments. We don't need that stuff anymore. Not at the level of abstraction we should be working at. Leave the bits'n'bytes to the OS engineers, the DBMS engineers and their ilk. Let's get on with the "what", and leave them to the "how". Received on Fri Jun 02 2006 - 00:49:52 CEST