Posted by Jerry Stuckle on 07/23/07 16:26

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.
>
> Cool.
> Thanks.
>
>
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]