|
|
Posted by Sanders Kaufman on 07/23/07 19:12
Jerry Stuckle wrote:
> Sanders Kaufman wrote:
>> 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.
Yeah, I started to go there - but that would have been one level of
complexity, too far for this architecture... or architect, anyway.
Better to just set a few properties and say "connect()".
> Another way would be to have the database name as the default parameter
> to the constructor for the Database class.
I'm not using parameters in my constructor.
I wasn't sure if I could have constructor parms at all when I started
this thing.
Also, the idea of doing this:
"$x = new MyObject($y, $z)"
instead of this:
"$x = new MyObject()"
just *feels* wrong to me.
I'm not sure why - but it's probably legacy cringing from some other
platform and package in my past.
>> 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.
Ooooh. That seems significant to my design - at least, for the next
iteration in PHP5, anyway.
My baseclass is not designed to be instantiated, and it kinda irked me
that it could be. I even added a bit of PHPDoc to warn the developer
not to try. But that's a lousy way to code!
> 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.
Saturation level reached.
Information overload in effect.
Commence spinning of room.
Let's continue THAT part of the conversation in a few months, eh?
>> 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.
This looks like something I'm going to have to HEAVILY consider in the
next iteration of the code - abstract classes, interfaces and function
overrides.
Navigation:
[Reply to this message]
|