[RESOLVED] Class Inheritance Programming problem.

[Chris_96_WS6]

Not a coding problem, but an architecture issue...

I develop on an enterprise-scale web application that mainly handles MySQL transactional data...create, edit, delete, view various records for work that goes on in our department.

To simplify things a bit, lets just say that there are 4 unique types of work being captured Report A, Report B, Report C, and Report D.

Each type of report shares a common set of properties, such as author, title, ref #, etc.

But each report also includes unique properties that are not shared among the other types.

This has all been handles procedurally before, in a single table.

I am now writing classes for this and replacing the single table with a parent table (for the common vars) and child tables for each report type.

So far so good, I have completed the parent class and the Report A child class. However, I've hit a snag.

For displaying records, etc, how am I going to know which child class to call for a given record?

I'd like to have a way that I could call one class, and have it decide which report type the current object belongs to, then call the correct child class (each child class extends the parent class already).

[laserlight]

Chris 96 WS6 wrote:

For displaying records, etc, how am I going to know which child class to call for a given record?

I'd like to have a way that I could call one class, and have it decide which report type the current object belongs to, then call the correct child class (each child class extends the parent class already).

If feasible, instead of trying to find out the exact type and then calling the respective member functions, define (possibly abstract) methods that allow you to take advantage of polymorphism. This way, the PHP interpreter automatically invokes the desired method depending on the actual type of the object without you needing to check for the subtype. One advantage here is that you can then add and remove derived classes without needing to change the code that calls these polymorphic methods.

A situation may arise where this is infeasible, e.g., you really need to access members of the derived classes that are specific to each derived class. In such a case the use of the [man]instanceof[/man] operator is appropriate. The bad part is that you then have to update the code that performs this type checking whenever you add or remove a derived class (although you can sometimes specify some default behaviour for the case when the object is an instance of a derived class that is not in the list).

[Chris_96_WS6]

Thank you, I think this gets me pointed in the right direction.

I've only been writing classes for about 6 months (vs. PHP in general for about 3 yrs), and this is the most complex OOP project I've done so far.

[Chris_96_WS6]

In case anyone is curious, here's what I ended up doing.

1. Use polymorphism across child classes

2. Parent class is an abstract class

3. Created a "definer" class that does a quick lookup to see what sub-class should be implemented on the given object, and it instantiates the appropriate sub class through a switch.

	function instantiate_child_class() {

	switch ($this->_type) {
		case '1':
			$item = & new items_typeA_class();
			break;
		case '2':
			$item = & new items_typeB_class();
			break;
		case '3':
			$item = & new items_typeC_class();
			break;
		case '4':
			$item = & new items_typeD_class();
			break;
	}
	return $item;

The appropriate object is then called by first instantiating the definer class then calling the child instantiator method, which returns the correct $item object.

$definer = & new items_definer_class($id);
$item = $definer->instantiate_child_class();
$item->get_sub_item_vars($id);

[laserlight]

Chris 96 WS6 wrote:

The appropriate object is then called by first instantiating the definer class then calling the child instantiator method, which returns the correct $item object.

A better design would turn instantiate_child_class() into a non-member function or static member function to serve as a simple factory function.

By the way, assigning a newly created instance by reference is no longer useful in PHP5.

[Chris_96_WS6]

But, what do you mean "no longer useful"? It apparently works.

I agree it would probably be better to just create a factory function rather than yet another class to do the defining. Simpler and probably easier on the server.

[laserlight]

Chris 96 WS6 wrote:

But, what do you mean "no longer useful"? It apparently works.

As in it no longer results in a performance boost, so you might as well just write:

$item = new items_typeA_class();

[Chris_96_WS6]

I think you're missing the point of my problem.

I don't know up front whether I need to instantiate typeA, typeB, typeC, or typeD, so I can't hard-code $item = new item_typeA_class(); because I really don't know if I need typeA or one of the other three.

All I have to start is the record ID. The definer class takes the ID, does a table lookup to determine the record type, and then calls the appropriate child class and returns the object which will now contain as properties all the fields from the parent table record and the specific child type table record.

[laserlight]

Chris 96 WS6 wrote:

I think you're missing the point of my problem.

I don't know up front whether I need to instantiate typeA, typeB, typeC, or typeD, so I can't hard-code $item = new item_typeA_class(); because I really don't know if I need typeA or one of the other three.

No, I am talking about changing this:

$item = & new items_typeA_class();

to this:

$item = new items_typeA_class();

Likewise, you would apply the same change to the lines involving the instantiation of items_typeB_class, items_typeC_class, etc.

Chris 96 WS6 wrote:

All I have to start is the record ID. The definer class takes the ID, does a table lookup to determine the record type, and then calls the appropriate child class and returns the object which will now contain as properties all the fields from the parent table record and the specific child type table record.

Yeah, so as I mentioned you do not need the definer class, much less have it as a base class. Your simple factory non-member function or non-static member function can take the id as an argument, perform a table lookup and then instantiate an object of the correct type, and from then on it is just polymorphism.

[Chris_96_WS6]

Thanks, I didn't realize "&" was outmoded.

Very helpful discussion.

[Chris_96_WS6]

OK, so I converted the definer to a factory function and now am getting

"Fatal error: Call to a member function get_sub_item_vars() on a non-object "

after this:

$item = items_child_class_definer($id);
$item->get_sub_item_vars();

It looks like my function isn't returning an object as I expected. Obviously I'm missing something due to my OPP novice-ness.

function items_child_class_definer($id) {

$sql = "SELECT type FROM Items WHERE id = '$id' LIMIT 1 ";
$result = mysql_query($sql);
$row = mysql_fetch_object($result);

	switch ($row->type) {
		case '1':
			$item = new items_typeA_class();
			break;
		case '2':
			$item = new items_typeB_class();
			break;
		case '3':
			$item = new items_typeC_class();
			break;
		case '4':
			$item = new items_typeD_class();
			break;
	}
	return $item;	
}

[laserlight]

I suggest doing something like this:

function items_child_class_definer($id) {
    $sql = sprintf("SELECT type FROM Items WHERE id = '%d' LIMIT 1", $id);
    $result = mysql_query($sql);
    if (mysql_num_rows($result) == 0) {
        throw new Exception("No such object");
    }
    $row = mysql_fetch_object($result);

$item = null;
switch ($row->type) {
case '1':
    $item = new items_typeA_class();
    break;
case '2':
    $item = new items_typeB_class();
    break;
case '3':
    $item = new items_typeC_class();
    break;
case '4':
    $item = new items_typeD_class();
    break;
default:
    throw new Exception("Invalid type id");
}
return $item;
}

You would need to try/catch the possible exception at some point, and perhaps translate it into a better error message.