[RESOLVED] Best way to organizes these objects?

haste

I'm working on a project, but I would like others' opinions on how to organize my classes / objects.

I have three main objects: Volume, Issue and Article.

Articles are "contained" inside of an Issue. Issues are "contained" in a Volume. The relationships are made through a foreign key in the database.

If I want to retrieve a single record of either an Article, Issue or Volume, that's fine.

$ArticleObj->GetData($article_id);

But what if I want to retrieve all Articles are that belong to a specific Issue? Would I do this?

$IssueObj->GetArticles($issue_id)

The problem I'm running into is this: What happens when I get to Volume? The Volume object is only supposed to contain the information for one volume. But what if I want to retrieve ALL of the volumes? Would I have to do that outside of the Volume class? And when I return single records (such as a single article), should I return the information as an assoc array or as an Article Object?

Any help is much appreciated.

mouloud2001

I'm not an expert, but i think it highly depends on how you want to use the data, and what data are contained in each class.
Do you need to access data of different volume at the same time ?
I my classes, I usualy have a propertie which is an array containing the list of the differente objects selected. But just the ID of the object. And there is only one which is "selected", and have the data loaded in the other properties. And I have some function to move inside the selection. Basicly, it would look like this :

class cVolume
{
var $tVolume; // the list of the volumes selected
var $volume; // the "loaded" one
var $prop1;
var $prop2;
//etc...
function cVolume // constructor
{
// select the volumes and fill the tArray properties with the id of the selected volumes
// By default, the first volume of the selection becomes the loaded one. So :
$this->select($this->tVolume[0]);
}
function select($id)
{
// load the data for the volume which id is in the parameter
$this->volume = $id;
$this->prop1 = "whatever";
//etc.
}
function next()
{
// select the next volume in the tVolume list
}
function prev()
// select the previous volume in the tVolume list
}
// etc.
}

and did you read this part of the manual :
http://www.php.net/manual/en/keyword.extends.php
I think in your case, it could be usefull

Again, i'm not an expert, and I could be wrong. But it works fine for me 🆒

Shrike

I'd say that the loading and saving of objects should be separate to the class itself anyway. A common pattern used is the Data Mapper pattern, which defines the methods for saving and retrieving data for a particular object. The Mapper class returns a resource from the data source, and instances of the object which represents the data are created from the resource. When it comes to save an object you simply pass it to the mapper, which has the necessary functionality to save the object back to the data source. This is the basic principle of Object Relational Mapping.

haste

Thank you both for your reply.

Shrike, would a Collection class would achieve the same thing?

Shrike

What do you mean by collection class? A class which contains instances of objects? I prefer not instantiating them until they are actually needed.

haste

Shrike wrote:
What do you mean by collection class? A class which contains instances of objects? I prefer not instantiating them until they are actually needed.

I mean something like a VolumeSet class. It would be responsible for retrieving all Issues belonging to a particular volume (results as an array, not as object).

Shrike

That would be equivalent to a data mapper for volume objects. Imagine the following:

// A simple value object for a volume
class Volume
{
  var $id;
  var $date;
  function volume( $data )
  {
    $this->id = $data['id'];
    $this->date = $data['date'];
  }
  function getId()
  {
    return $this->id;
  }
  function getDate()
  {
    return $this->date;
  }
}
// The Volume mapper responsible for database work
class VolumeMapper
{
  var $db;
  function volumeMapper( &$db )
  {
    $this->db =& $db; // A database abstraction object
  }
  // This method finds volumes in the database by their primary key
  function findVolumeById( $id )
  {
    return $this->db->query(
      "SELECT id, date FROM volumes
      WHERE id = '$id'
    )";
  }
  // This function saves volume objects
  function save( &$volume )
  {
    return $this->db->query("
      UPDATE volumes SET
      date = '$volume->getDate()'
      WHERE id = '$volume->getId()'
    ");
  }
}
// Some client code
// $_POST & $_GET used for brevity - in a real world situation you would check them first
$mapper = new VolumeMapper( $query_handler );
// Load a form if $_POST not present
if( !isset( $_POST['submit'] ))
{
  $resource = $mapper->findVolumeById( $_GET['id'] );
  $vol = new Volume( $query_handler->fetch( $resource ));
  /* Display an HTML form using $vol for fields */
}
// Otherwise save the object back to the database
else
{
  $vol = new Volume( $_POST );
  $mapper->save( $vol );
}

It makes sense to have the SQL needed for saving and retrieval of objects in one place, rather than repeated throughout the code. In addition keeping the Volume object solely responsible for knowing about Volumes makes sense in terms of reusability. The Volume object doesn't care that the volume data comes from a database, in fact you could swap it for a file system, or web service, or whatever so long as it delivered an array in the constructor. To quote Martin Fowler:

The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema.

Hope this helps a bit.

haste

Thank you, Shrike. Your input was extremely helpful and very much appreciated. I think I have a direction to head toward now.

Shrike wrote:
That would be equivalent to a data mapper for volume objects. Imagine the following:
// A simple value object for a volume
class Volume
{
  var $id;
  var $date;
  function volume( $data )
  {
    $this->id = $data['id'];
    $this->date = $data['date'];
  }
  function getId()
  {
    return $this->id;
  }
  function getDate()
  {
    return $this->date;
  }
}
// The Volume mapper responsible for database work
class VolumeMapper
{
  var $db;
  function volumeMapper( &$db )
  {
    $this->db =& $db; // A database abstraction object
  }
  // This method finds volumes in the database by their primary key
  function findVolumeById( $id )
  {
    return $this->db->query(
      "SELECT id, date FROM volumes
      WHERE id = '$id'
    )";
  }
  // This function saves volume objects
  function save( &$volume )
  {
    return $this->db->query("
      UPDATE volumes SET
      date = '$volume->getDate()'
      WHERE id = '$volume->getId()'
    ");
  }
}
// Some client code
// $_POST & $_GET used for brevity - in a real world situation you would check them first
$mapper = new VolumeMapper( $query_handler );
// Load a form if $_POST not present
if( !isset( $_POST['submit'] ))
{
  $resource = $mapper->findVolumeById( $_GET['id'] );
  $vol = new Volume( $query_handler->fetch( $resource ));
  /* Display an HTML form using $vol for fields */
}
// Otherwise save the object back to the database
else
{
  $vol = new Volume( $_POST );
  $mapper->save( $vol );
}
It makes sense to have the SQL needed for saving and retrieval of objects in one place, rather than repeated throughout the code. In addition keeping the Volume object solely responsible for knowing about Volumes makes sense in terms of reusability. The Volume object doesn't care that the volume data comes from a database, in fact you could swap it for a file system, or web service, or whatever so long as it delivered an array in the constructor. To quote Martin Fowler:

Hope this helps a bit.