Hi All,
Although I am not so new to PHP (not expert either), this is the first time
for me to use PHP class.
I am starting a project, and plan to use partially OOP and partially
traditional programming. I use PHP/MySQL. I have one class, DB_Do, which does every thing to do with database, and several other classes. When I start my design, I realized that very often, other classes need to access database, eg. I have an "Access_Control" class which controls all accesses to pages in the application. One of methods in this class is to
authenticate the user login via user name and password stored in the
database. I am not sure if I should use an object of DB_Do within the
method of Access_Control or write separate code to access the database for the user name and password. It seems that I loose purpose of OOP if I write the separate code. However, I am not sure if creating the object within other class is efficient?
I would appreciate if some one there could give me some suggestions about this.
Thanks in advance.
Ruth
PHP classes
Moderator: General Moderators
I understand your concern, but after you completely wrap your mind around OOP your worries about doing something wrong or invalid in your classes will drift away. 
It's perfectly fine to use objects within other objects. This is the beauty of objects... they can be referenced with a pointer pretty much every where.
The fact you have seemingly created a database abstraction (anal edit) layer is a good place to start. Piping all DB interaction through an object handler makes it leap years easier for your code to support multiple DB types.
Once you go OOP you can never go back... and you will not want to.
It's perfectly fine to use objects within other objects. This is the beauty of objects... they can be referenced with a pointer pretty much every where.
The fact you have seemingly created a database abstraction (anal edit) layer is a good place to start. Piping all DB interaction through an object handler makes it leap years easier for your code to support multiple DB types.
Once you go OOP you can never go back... and you will not want to.
Last edited by rev on Tue Oct 08, 2002 11:11 am, edited 1 time in total.
I don't agree with this. OOP is cool, but it certainly is not "1 size fits all"! The performance penalty alone makes it very unsuitable for many types of applications.Once you go OOP you can never go back... and you will not want to.
That said, you need to create your classes very carefully to avoid unwarranted overhead. There is a very, VERY good OOP lib called Eclipse created by a guy named Vincent O(something or other). It's extremely lightweight and simple to use. For much of the database abstraction (not extraction
Conversley, there are many classes that force you to create another connection for each query. That's not smart is it?
I just at looked the mysql class from Pear (which is a joke!) and it has 26 methods in it! Now let me ask: what are the chance of you using every single one of those methods each time you instantiate the class? It's not likely, so why generate the overhead in the first place? A better idea would be to create small classes that do ONLY what you want them to do, then extend those classes when you need things that aren't often used.
You could call this specailization. The only job of an F-15 (except for the E variants) is as an air superiority fighter. It doesn't haul troops or cargo or do Spec Ops insertions. Objects should be given the same consideration in the design phase.
Anyways, check out the Eclipse library here at http://www.students.cs.uu.nl/people/voo ... /index.php.
Cheers,
BDKR