Here is my advice, check out the pear code, it will help you dearly get the grips of how to setup classes. IMHO i feel pear is a standard, i use most of the standard but i dont particularly write classes for pear but structure it similar, but am thinking of porting my error code around pear. Classes are purely packages which are reusable within projects, try not to get simple functions with complete classes mixed up, it may not be needed to make a class at all. Hope this helps.
-----Original Message----- From: Chris Neale [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 8:42 PM To: [EMAIL PROTECTED] Subject: [PHP] OOP methodology This is a long one - I'm trying to get to grips with my understanding of OOP. I'm not sure that I understand object oriented programming as well as I could to benefit from using it in PHP. Although I've used it to produce working applications, of the few objects I've produced nearly all have carried too much weight and functionality (one object for both HTML generation and DB interaction etc) and several have been extensions of the others. I was hoping someone might be able to check my logic. One of the main functions of the application I'm working on at the moment, my first use of OOP in PHP, is to iterate through a hierarchy of retail outlets and extract information from a database based on each location in the hierarchy. A template SQL statement is parsed and parts are replaced with information from the hierarchy. This query is then executed, and the results are placed in a table within a static HTML file stored in a directory structure which mirrors the structure of the retail outlet hierarchy. I've done it this way because the traffic to the site is expected to be high and the information changes infrequently, so static pages will ensure good performance. The way I've written the application isn't up to much IMO, using objects in a primitive way akin to a PC newbie using the CD ROM drive as a coffee cup holder - ie. does the job but it's not quite how it was intended to be used. I've got one big object (treeMapper) that does everything, which includes (over and above the database functions, file input and output, HTML generation and string formatting). It has two main methods. Process() and taskMaster(). The first method iterates one unit through the hierarchy and then calls taskMaster() which takes values Process() has changed in the object and uses them to query the database and to format the results into an HTML table and output to a file (as described above). In the code for the class, taskmaster() is empty. When I want to use the class, I create a new class which extends treeMapper and then overrides the taskMaster function. In this way I get an object which I can reuse for any report which needs to be made for every store. It works and it's fast, but this method seems really WRONG! I started developing this six months ago as a first project in OOP in PHP, and am starting to see it's limitations - for instance, I need to use the DB functions for other small tasks on the site, which involves instantiating a new treeMapper (which is highly inefficient as I won't need the other 20 methods.). I've also got some handy string manipulation routines which can't be used without instantiating a treeMapper. So I want to break it up into smaller chunks, smaller objects which can talk to each other. >From what I've read, I think I should be using an iterator pattern to design an object which JUST does the iteration, a database object which JUST does queries from the database, another iterator object which JUST does iteration through database results and another object which draws graphs based on results from the database. My question is (I know you've been waiting) how best to connect up these objects, as I only really need one instance of each object for my application. PHP 5 objects seem easier to deal with (none of this incomprehensible & notation) and I want to know whether the following is a good way of doing it and how other people might go about this. class dbObj { var $results; function dbObj() {//set up DB con} function execQuery() {//ODBC query exec - results put in $this->results} } class iterator { var $currentPos function iterator() {//loads data into iterator} function reset() {//Resets pointer} function next() {//steps forward one item, changes $this->currentPos to whatever.} } class HTMLGenerator { function HTMLGenerator($dbObj, $iterator) { $this->dbObj = $dbObj; $this->iterator = $iterator; } function MakeHTML() {// as you'd expect. // refers to $dbObj and $iterator (objects passed by reference in // PHP 5) // $iterator->currentPos used to parse SQL query // eg. $dbObj->execQuery("select..."); // eg. $dbObj->results used to make HTML; // } function outputToFile() {//Saves to File} } The main application would then do this: $q = new dbObj; $x = new iterator; $y = new HTMLGenerator($q, $x) while ($x->next()) { $y->MakeHTML(); $y->outputToFile(); } Anyone got any thoughts about whether this is a good way to do it? I was wondering whether instantiating objects should be done within other objects that need them - if this can be done - but I would only do that in cases where (for instance) an HTMLGenerator object is instantiated without any parameters, in which case some logic could be added to do this. Thanks! Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
