|
|
Posted by Jerry Stuckle on 07/23/07 18:38
Sanders Kaufman wrote:
> 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.
>
>
There are two ways to look at this. The more portable way would be to
have a class which just connects to a database but doesn't actually
define the database. Then you could have a derived class
"DefaultDatabase" which connects to your default.
Another way would be to have the database name as the default parameter
to the constructor for the Database class.
Both are "correct" implementations. Which I would use would depend on
other factors. For instance, if the only thing different were the
database name, chances are I'd take the default parameter route (and not
even create other database classes - just pass the database name when I
create the object). However, if I'm going to have different functions
for the databases, chances are I'd go the route of having multiple
derived classes.
>
>> 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?
>
Yes, abstract methods are a PHP 5 implementation (and in most other OO
languages). It means the base class has defined but not implemented the
method. This makes the base class an "abstract class", and you won't be
able to instantiate an object of that class.
Abstract classes are used for inheritance. A derived class must
implement all of the abstract methods in the base class (or it, too,
will be an abstract class). An abstract class with only abstract
methods would be an "interface", as Toby mentioned in another post.
>
>> 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.
>
You can override functions in PHP; it's very commonly done when the
derived class needs to do some work, also. But the derived class should
also be calling the function in the base class so the base class can
perform its work.
>
>> 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?!
>
No, $child->foo() would have to call parent::foo().
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|