PHP Classes & Inheritance

Hi All,

I am attempting to use classes in PHP with inheritance. So I have a class called "timetable", which is being constructed to complete all functions I would require when accessing timetable info.

timetable extends common. Common is a class providing common functions to all pages in the site.

common extends mysql. Mysql is a class containing all mysql functions such as connect(), close(), etc...
Mysql has a constructor "mysql()" which points to its explicit constructor "_constructor($host,$user,$pwd,$db)".

Common also has a constructor which points to mysql's constructor through "$this->_constructor(all vars)"

timetable also has its own constructor, which doesn't except any vars, and also points to mysql's constructor through "$this->_constructor(all vars)", passing global vars.

The problem is that I recieve an error informing me that I am missing all arguments required by the constructor of common. I guess this is triggered through the extends in timetable but am unaware how to rectify the problem...


BTW, the reason I want to do this is so that each starting class i.e. timetable, users, guestbook, etc. can encapsulate their own DB connection as they will each be on seperate DBs.

All help will be much appreciated.

Cheers,
Harvey

Sorry all,

The code I supplied actually works! and it was something else in my script. All Fixed!

Cheers anyways,
Harvey

For what it's worth, I don't know that I'd extend classes to do what you're wanting to do. Seems like that could cause debugging problems later and really sort of undermines the concepts behind OOP. I'd just instantiate a separate db class within whatever classes need it. I could be wrong, though. I'd be interested in hearing a defense (from anybody) for doing it the way you've done it.

...thanks for the reply dhouston and am very interested to hear opinions on the way I have chosen to implement inheritance.

The basis in which I chose to use inheritance was due to every page I create for this project to most likely require a function from the common class. As each page is going to reference the common class, do i really need another explicit decleration of a mysql class which has the basic function of creating a connection, and closing a connection.

The common class extending the mysql class allows me to create seperate connections per activity (an activity being timetable, users, guestbook, etc). Having each activity extend mysql would probably be the best OOP way of doing things, but the method used has one class that extends mysql rather than 20 classes that extend mysql individually.

The other reason for having class common between the activity (timetable) and mysql is because the connection could be altered at a later date, i.e. using Oracle instead. Once completed the common class will extend a class dependent on the connection statement in the project's config.ini. The code to pick up the connection from the ini would have to be placed in every class that extends the connection, so why not have it in the one place??

...I would be very interested in a pros and cons list to help in my further development.

...cheers for your help,
Harvey

Thanks for the follow-up. Incidentally, just to make it very clear, my intention isn't to attack your implementation. I'm just interested in the why behind it. (It's possible it's *my* usual method of implementation that doesn't make sense, after all.)

I'd like to address some of your points, again, not to try to prove you wrong, but to make sure I understand where you're coming from so that I can evaluate my own methods.

You're right that it's a decent idea to limit declarations of your mysql class. If you know all the classes in a given project are going to be using both the common and the mysql classes, it could make sense to do the declaration only once. My personal inclination would be to give the common object an instance of the mysql class rather than bothering with inheritance. Why bother with inheritance if you're always going to be interfacing with the methods through one class anyway? Just add methods to the class that's extending your mysql class; else there's no point to breaking it out into its own class. Inheritance to my mind is best used either to override base methods or to allow for a sort of hierarchy of related classes. So you might have a "Car" class that defines doors and methods for moving forward and backward common to all cars. But you might extend it with a "Hatchback" class that defines that other door/window combo. I see what you're doing as writing a class called "GasPump" and allowing "Car" to extend it.

And that might work well for your project. I suppose the angle I'm coming from is that I work on a lot of projects and have to reuse my tools a lot. The tasks common to one project might not be common to another. I suppose you address this by extending mysql rather than extending common. It makes more sense for me to have a detached database class and to create an instance of it in my common or other classes. Doing this affords me more modularity at no cost to the rest of the object hierarchy.

I typically create an instance of my database class and execute the connect method. Then I pass this connection around (usually by reference) to other classes as needed (sometimes to a Config or API class that I imagine serves essentially the same purpose as your Common class). This leaves me with one connection (I don't understand why you'd need separate connections per activity -- wouldn't that just add overhead?).

To address your last point, my solution has been to write not a mysql class, but a db class. When you instantiate it, you pass a parameter telling it which database interface to use. Each member function (connect, query, fetch, disconnect, and usedb being the most often-used) uses the db type attribute to figure out which PHP calls to make. Right now, I support mysql, sybase, and odbc connections. If I want to add oracle or postgres down the road, I alter the db class and still don't have to worry about altering calls to member objects in the projects that use the class.

We're really trying to reach pretty much the same goal -- we just have different ways of skinning the cat suited to our particular needs.