Re: Using a Resource as a Class Property

Sanders Kaufman wrote:
Sanders Kaufman wrote:
Toby A Inkster wrote:

So to correct my statement:

In OOP (not just PHP) the constructor of the grandest child :) will be called when a class is instantiated as an object.

Wow, now that I've done it that way, I can see why it's the better way.
By having to call the parent constructor from within the child object, It gives the child better control.

For example, my parent has a "database" object, and a built-in default way of talking to it; while the child has another way of talking to it - each established in the constructor, and each running a verification process to ensure it still works

Probably an incorrect implementation of OO, depending on exactly what you're trying to do.

The purpose of OO is to allow the child object to use the parent object's methods (functions) and to not have to write its own.

In the case of a Database object, the main purpose of the object is to perform the communications. Another class which does it a different way would be a different class.

Now that doesn't mean you shouldn't have a database object which doesn't have children. For instance, as a simple example, you might have:

class Database
member database name
abstract methods open (connect), close (disconnect), query

class MySQL_Database extends Database
methods open, close, query

class PostGres_Database extends Database
methods open, close query

But you should not have:

class MySQL_Database
member database name
methods open, close, query

class PostGres_Database extends MySQL_Database
methods open, close query (which override MySQL Database)

I know this isn't exactly what you're saying - but I wanted to make it more extreme to be more obvious.

If you're basically creating a MySQL_Database class then overriding most of the methods in the child class, you should look at whether your design is appropriate or not. In most cases I would argue it would not be. But you could have a third class as the parent with the appropriate shared methods, and two other classes derived from the original parent.

That's not to say overriding is *never* appropriate - in many cases it is. But as part of the overriding, you generally end up calling the parent class method, also.

So now I can have the child set the values for the conversation before the parent .... blah, blah, blah.

Bottom line - I talk to the DBMS once, instead of twice during initialization.


Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.