|
|
Posted by Sanders Kaufman on 07/23/07 17:13
Jerry Stuckle wrote:
> Sanders Kaufman wrote:
>> 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.
I probably used the phrase "different way" poorly.
What I mean is that my database class, by default, connects to my
primary database server. But other classes in my architecture,
extending that one, may need to contact a different server.
So, by having the child modify the parent connection parameters, it can
talk to whoever it needs to... not just my primary.
> 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.
It's ALL good - although every answer seems to beg another question!
In this case - abstract methods?
Is this another OOP thing that PHP4 doesn't do?
> 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.
Word.
Fortunately, I didn't fall into that trap.
In fact, in designing my project, I (wrongly) presumed that I could not
overrride functions in PHP.
> 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 if the parent has "$parent->foo",
And the child overrides that with "$child->foo",
BOTH functions will fire when the child does?!
... but only sometimes?
Wassat about?!
Navigation:
[Reply to this message]
|