OOP - good practices?

[nightowl]

Just a general OOP question:

when you have a general setup table A, table B and table C with A 1->n B n <- 1 C relationships (e.g. to store groupmemberships, with table A == persons, table C == groups and table B storing the membership-relationship via the ID's of A and C)

It's obvious that we'll create at least 2 classes: one for objects which are stored in table A ("class person") and one for objects stored in table C ("class group"). Should we create an other class ("class memebship") to store the membership-data or should those functions be included in the table A ("person->addToGroup") class and in the table C ("group->addPerson") class?

What's the best practice?

[ZibingsCoder]

You might just try using two classes. Since groups are the ones that have the actual users as members, you might as well just make the user class something that you use to store the information of each of the members in a group. Lets see if this kind of makes sense... (this is PHP4, if you're using PHP 5, lemme know and I can change it around)

Oh, and before you read this, keep in mind that you might want to switch your table structure around a little bit. Instead of storing the id relationships in a seperate table, you'd really only need to put a 'groupId' field into the 'person' table. But, either way, you can do this general class structure below.

class group
{
   //array of all the members
   var $members = array();
   var $groupName;
   //put whatever other information about the group you need

   //constructor
   function group ( )
   {
      //go through your data, then get a list of all members with the group ID
      foreach ( $member as $person )
      {
         $this->members[] =& new person($person);
      }
   }
}

//now the person class
class person
{
   //put whatever variables you need here
   var $userId;

   //constructor
   function person ( $array )
   {
      //use the array to populate the properties for the class
   }
}

If this was entirely off base as to what you were looking for...I'm sorry. However, if it helped, or if it kind of helps and you need more explanation, let me know, I'm glad to continue.

[nightowl]

it sure was useful - though the code is not a problem as such. I was more wondering about the general structure and where to place the methods to add people to a group, even independent of PHP.

From your post I get you are suggesting placing the "add" function in the group-class and not in the person-class (like person->addToGroup()) ? Any reason for this?

Would you change your reasoning (instead of 2 classes, create 3 of them) if we were storing more information about the membership of the group (e.g. group membership has a status, it must be requested and approved) ? Would this situation better be handled by 3 instead of 2 classes?

Since relations between persons and groups are n <-> n (person can belong to multiple groups), I defenitely need that intermediate table AFAIK.

I'm actually using PHP5 for this.

[tomhath]

Designing classes around the persistent data store (in this case the database tables) is a trap people often fall into.

Try to break out of thinking in terms of how the data is stored and design around how the data will be used.

What entities are you modelling with the classes? Obviously people are members of groups, but what entity does that membership list represent? In other words, once you have the list of people in a group what are you going to do with it?

[nightowl]

Allright, I can understand your reasoning. I was not trying to model my classes after my tables but indeed, most of the time they are very much related. I hope you can point me towards a better solution. Here's the complete situation:

People (e.g. we want to store first name, last name, email) belong to groups (e.g. groups have a name, a single e-mailaddress and some other properties ). One person can be a member of multiple groups. The membership has a status (approved or not yet) and a time untill when it's valid.

In my database, I would map this to 3 tables: persons (personID, firstname, lastname, email), groups (groupID, name, email) and memberships (personID, groupID, status, validuntill).

Now is the question: what classes would you define? 2 or 3? And if you only take two: how would you handle the membership of groups?

Logically, you could choose for 2 classes: person and group.

class person {

function addToGroup($group) {

   /* this function would take a group object to know to what group we want to add the person */

  $sql = "insert into memberships (...) values ($this->id, $group->id, 'REQUESTED')";

 ... exec query ...

   }


function changeMembershipStatus($group, $newStatus) {


       $sql = "update memberships set status = '$newStatus' where groupID=$group->id and personID=$this->id";

     ... exec query ...


}


}

class group {

 function addPerson($person) {
      /* this function would take a person object to store */

     $sql = "insert into memberships (...) values ($person->id, $this->id, 'REQUEST'";

     ... exec query ...        


 }

function changeMembershipStatus($person, $newStatus) {


       $sql = "update memberships set status = '$newStatus' where groupID=$this->id and personID=$person->id";

     ... exec query ...


}

}

What I'm afraid of is the doubling of the code you start to see here ... I'm writing exactly the same funcitons for the group class as for the person class. though logically more correct, I figured this could not be the purpose. So I fell back to 3 classes:

class membership {

function membership (or __construct in PHP5) ($person = false, $group=false) {

       if ($person) { $this->person = $person; }
       if ($group) { $this->group = $group; }



}

 function create () {

     /* this function takes a person and a group object */

    $sql = "insert into memberships (...) values ($this->person->id, $this->group->id, 'REQUEST'";

     ... exec query ...


 } 


 function update ($newStatus) {


       $sql = "update memberships set status = '$newStatus' where groupID=$this->group->id and personID=$this->person->id";

     ... exec query ...


 }



}

What do you think? Looks better? How would you solve this problem?

As to what I would like to do with my group membership: I obviously want to list the groups a person belongs to and the persons which belong to a particular group. I want to list the persons who have requested a groupmembership. I want to list those persons whose membership is about to expire. And per person: I want to list the groups requiring attention (membership about to expire) and the one awaiting approval of membership, ...

[tomhath]

It looks like you have three entities: person, group, and membership.

I'd make make membership a Decorator http://encyclopedia.thefreedictionary.com/Decorator%20pattern of both the person and group classes. That gives you the two main classes you started with, and gives them the functionality they need without the code doubling you're trying to avoid.

[nightowl]

thx for pointing this out to me but I honestly have no clue on how to get started.I've read and re-read the link you gave me and even found some (maybe more interesting info, since related to PHP) on

http://www.phppatterns.com/index.php/article/articleview/92/1/1/

but don't understand how to get started. What would my "membership" class look like generally? What should it inherit from? What should I pass in the constructor? Should there be one or one for person and one for group ?

Could you please elaborate this for me?

[nightowl]

I've been re-reading the whole article again and I've been thinking about this all too - It's still unclear to me what the difference between the decorator pattern and a simple inheritance is. Also, why would someone create a class, next a decorator-class and then inherit from that decorator-class which just mimics the orignal class (see article I mentioned)?