Re: OO solution?

Bob Badour wrote:
> 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.
>
>

Viewer has plenty of uses - it lets me create a list in each Document object that is flexible enough to hold either a Group or a User. In object orientation courses it is taught that this is a powerful feature of the OO paradigm.

> Each Document object can maintain a list of Viewers which
> > can view it.
>
> And yet another useless structural element: list.
>

If I didn't use a list, what pray tell would I use to maintain the Viewers that can view a document? Plus, in java, I can take advantage of the fact that pre-defined ArrayList objects have an already-built remove() method, so I can easily delete documents from the application, and then use the remove() function on all Viewers' lists that contain that document (naturally, I'd encapsulate this in a removeDocumnet(Document d) method of the Viewer class).

Plus, I can make my Viewers' ArrayLists of ViewableDocuments implement the Serializable interface, so I can store them to a disk in any format I choose for permanence. And since they are encapsulated, with probably less than a few hundred lines of carefully crafted code, I can ensure that the action of renaming a document gets propogated to all Viewers' lists that refer to that document, and that the data only gets serialized when all such propogations are complete. And if this were an application with many users, I could make my Viewers' Sieralizable ArrayLists of ViewableDocuments synchronized, allowing them to be maintained in a multi-threaded manner by sending asynchronous signals between objects (this would probably need to be coded and tested thoroughly by an experienced OO professional, of course). So we see another benefit of OO paradigmation: scalability.

>
> 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.
>

Sigh. It's not hacking - it's OO paradigm computer programming, and very skillful programming at that... see above for how this design might need some real expertise for a production implementation (not some cheap "hacker" that defines a couple of relational tables).

>
> 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.
>
>

Here, I'm just touting the extensible flexibilty of the OO paradigm. Did I mention each User could maintain a list of the groups of which they are a part? Of course, that was part of the exercise, but oh well. This, too, could be serializable and synchronized for consistency. The sky is the limit (and still we're probably only talking about needing a small team of skilled programmers to maintain what would probably be less than a thousand or two lines of code and still ensure all the components work together seemlessly).

> 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.

Okay, forget I used the word monadic. (Sheesh, can't a OO paradigmaniac use the right term every now and then?)

> 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 there are a dozen OO experts who could back me up here: as long as the kludge is encapsulated, it doesn't really matter - and if the kludge doesn't work, then it can be changed without breaking anything else that uses the interface. With rdbms, if you change the tables, you might have to adjust the interface to match the underlying model.

<snip more valid points>

> Other than announcing yourself as a self-aggrandizing ignorant

Mission accomplished. :-) Okay, end of the workday, I confess... I'm not the OO paradigm fan the initial post may have led one to believe.

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

I honest-to-god tried. I'm not sure I saw any, either. Any OO people care to tell me where I went awry? Received on Tue Jun 27 2006 - 00:05:55 CEST