OO solution?

From: <kvnkrkptrck_at_gmail.com>
Date: 26 Jun 2006 13:40:15 -0700
Message-ID: <1151354414.969989.298900_at_r2g2000cwb.googlegroups.com>

In keeping with other discussions in cdt, I can't help but wonder if it wouldn't be cleaner to use an OO solution. Just create a Document class, and an abstract Viewer class extended by a Group class and a User class. Each Document object can maintain a list of Viewers which can view it. Each Viewer object can maintain a list of Documents which it can view; each Group object can store a list of users that are a part of it; applicable monadic properties for User objects is left as an exercise.

I'll bet the application code would all but write itself. Plus, you can encapsulate these properties and then expose Document methods of canView(Viewer v) or Viewer methods of makeDocumentViewable(Document d)... the cool thing is you can carefully change the underlying implementation of such methods without breaking any code that calls them.

Did I miss any other benefits of utilizing the OO paradigm? Are there any cons?

sreedhardasi_at_gmail.com wrote:
> I have a database design questions. How can we specify one of two
> columns in a table should be not null? In other words, if one column is
> null then another column should not be null. Here is an example. Let's
> say we have document and we need to specify permissions to the
> document. The document has either individual or group level
> permissions.
> Document table
> doc_id int primary,
> doc_name varchar(50) not null
> User table
> user_id varchar(50) primary,
> user_name varchar(100) not null
> Group table
> group_id int primary,
> group_name varchar(50) not null
> UserGroup table
> user_group_id int primary,
> group_id int not null,
> user_id varchar(50) not null
> DocumentPermission table
> doc_id int,
> group_id int,
> user_id varchar(50)
> So, either group_id or user_id should not be null in the
> DocumentPermission table. Is there anyway we can have constraint like
> this on the table? Is creating another group for that user the only
> solution (Involves more administration)? Any help would be appreciated.
> Thanks,
> Sreedhar
Received on Mon Jun 26 2006 - 22:40:15 CEST

Original text of this message