Re: OO solution?

kvnkrkptrck_at_gmail.com wrote:
> In keeping with other discussions in cdt, I can't help but wonder if it
> wouldn't be cleaner to use an OO solution.

No, it wouldn't. A cleaner solution simply would avoid trying to state facts about two mutually exclusive things in the same sentence. A cleaner solution would state facts about group permissions separately from facts about user permissions.

   Just create a Document
> class, and an abstract Viewer class extended by a Group class and a
> User class.

Already you have introduced a useless entity or concept: viewer.

   Each Document object can maintain a list of Viewers which
> can view it.

And yet another useless structural element: list.

   Each Viewer object can maintain a list of Documents which
> it can view;

Yet another list to hack together something to try to compensate for the symmetry you lost by doing something as stupid as using OO in the first place.

  each Group object can store a list of users that are a
> part of it;

Yet another list, but this was beyond the scope of the original example so it isn't relevant to the comparison.

  applicable monadic properties for User objects is left as
> an exercise.

The same would go for the monadic properties of any user-defined type in the relational model. Since a monadic property is really just a relation with degree 1, I find it amazing you would even bother suggesting that direct support for relations of any degree is somehow less clean than something supporting only relations of degree 1.

The relational model naturally deals with monadic properties as exactly what they are. OO necessarily has to kludge anything trying to deal with relations of other degrees.

> I'll bet the application code would all but write itself.

Meaningless bravado. Obviously, it won't.

   Plus, you
> can encapsulate these properties and then expose Document methods of
> canView(Viewer v) or Viewer methods of makeDocumentViewable(Document
> d)...

Or you could have two relations and be done with it. You would automatically get all of these predicates effortlessly using either the algebra or the calculus, whichever your rdbms offers.

   the cool thing is you can carefully change the underlying
> implementation of such methods without breaking any code that calls
> them.

But nowhere near as cool or as easily as changing a view or a physical mapping for a relation.

> Did I miss any other benefits of utilizing the OO paradigm?

Other than announcing yourself as a self-aggrandizing ignorant, why would you use the word 'paradigm' to mean an example, a verb declension, or a world-view when better words exist for each of these? Since OO is a computational model and none of the above, why would you use the word in reference to OO at all?

Did you enumerate any benefits? I didn't see any.

   Are there
> any cons?

Yes plenty. The more relevant question is: "Were there any pros?" Received on Mon Jun 26 2006 - 23:05:32 CEST