[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/)
Re: [PHP] OOP methodology
Hi Chris, Sounds to me like you are pretty much on the right track bearing in mind that PHP is not the bes language to learn OOP. Even your taskmanager sounds good, i wouldn't bother with reading up on design patterns just yet. They are indeed very important and you should definitely study them, however having spent an year or more doing OOP helps you understand them better. (others will disagree). Don't worry about classes become too big either if all the code belongs in one class it can't be helped. If you look at a fairly large java program you will find classes that range from 20-30 lines to 2000+ lines. Chris Neale wrote: 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). -- Raditha Dissanayake. http://www.radinks.com/sftp/ | http://www.raditha.com/megaupload Lean and mean Secure FTP applet with | Mega Upload - PHP file uploader Graphical User Inteface. Just 150 KB | with progress bar. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology
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
RE: [PHP] OOP methodology
Yes i think java would be the best to learn proper OO, i've nevr done it, but coming the other way knowing php OO, java became more familiar to me, i'm gonna do it this year. With PHP5 coming out that all may change slightly. May i ask though, what is the point of a destructor and is it really good to add it in, does it work in php4 ? -Original Message- From: Raditha Dissanayake [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 9:19 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PHP] OOP methodology Hi Chris, Sounds to me like you are pretty much on the right track bearing in mind that PHP is not the bes language to learn OOP. Even your taskmanager sounds good, i wouldn't bother with reading up on design patterns just yet. They are indeed very important and you should definitely study them, however having spent an year or more doing OOP helps you understand them better. (others will disagree). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology{O|T} kinda'
[snip] Yes i think java would be the best to learn proper OO, i've nevr done it, but coming the other way knowing php OO, java became more familiar to me, i'm gonna do it this year. [/snip] Why not start with the king of OOP, C++? Currently C++ is the most robust implementor of OOP design issues. From there it is easier to come to grips with PHP, JAVA and any other language in which you may need or want to use OOP. I heartily recommend that JAVA is NOT the way to learn OOP. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP methodology{O|T} kinda'
Jay Blanchard wrote: [snip] Yes i think java would be the best to learn proper OO, i've nevr done it, but coming the other way knowing php OO, java became more familiar to me, i'm gonna do it this year. [/snip] Why not start with the king of OOP, C++? Currently C++ is the most robust implementor of OOP design issues. From there it is easier to come to grips with PHP, JAVA and any other language in which you may need or want to use OOP. I heartily recommend that JAVA is NOT the way to learn OOP. Hehe, and here is where we start a holy war. I would have to disagree. While it may be possible to implement good OOP in C++, it does not nearly implement OOP as well as many other languages. It also has many other design problems that hinder the learning of OOP. However, if you know C++ already it may be easier to learn good OOP in C++ (it has much more full OOP than PHP4). -- paperCrane Justin Patrin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology{O|T} kinda'
[snip] Hehe, and here is where we start a holy war. [/snip] Bring it. [snip] I would have to disagree. While it may be possible to implement good OOP in C++, it does not nearly implement OOP as well as many other languages. It also has many other design problems that hinder the learning of OOP. [/snip] I respect your opinion and all, but how do you come to this conclusion? Which of the many other languages implement OOP better? And what other design problems do you speak of? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP methodology{O|T} kinda'
Which of the many other languages implement OOP better? Smalltalk, for one. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology{O|T} kinda'
On Fri, 30 Jan 2004, Jay Blanchard wrote: I would have to disagree. While it may be possible to implement good OOP in C++, it does not nearly implement OOP as well as many other languages. It also has many other design problems that hinder the learning of OOP. I respect your opinion and all, but how do you come to this conclusion? Which of the many other languages implement OOP better? Python, Ruby...? Of course, I've never done any OOP in C++. My guess is part of the reason he said this is because you've got to learn C++ before you're going to do much successful OOP with it. Not exactly a small learning curve. Other languages dispense with a lot of the formalities found in C++ (a good or bad thing, depending on your perspective). I found Python to be a great language to learn OOP, since it forces good habits on you. -- Kelly Hallman // Ultrafancy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology{O|T} kinda'
On Fri, 30 Jan 2004, Kelly Hallman wrote: Other languages dispense with a lot of the formalities found in C++ (a good or bad thing, depending on your perspective). I found Python to be a great language to learn OOP, since it forces good habits on you. C++ is a very large unwieldly language - it has too many constructs and too much syntax. Experience has chown that smaller simpler languages are easier to learn and apply than larger ones. This is why C is still the language of choice for a lot of systems coding (among other reasons). While purists will no doubt damn me to hell, I know a lot of people would put C++ at the bottom of their list of OOP coding languages of choice. -- Aj. Sys. Admin / Developer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology{O|T} kinda'
[snip] Experience has chown that smaller simpler languages are easier to learn and apply than larger ones. [/snip] Obviously. :) I'd be curious as to how many cam to PHP from a programming background? Likewise, how many start with PHP and go on to other languages? And what those languages are either direction? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP methodology{O|T} kinda'
On Jan 30, 2004, at 2:19 PM, Jay Blanchard wrote: I'd be curious as to how many cam to PHP from a programming background? Likewise, how many start with PHP and go on to other languages? And what those languages are either direction? Probably a strange mix, but... I came to PHP from an AppleScript/JavaScript/very-basi-C background. While I was beginning to learn PHP, I took 2 C++ classes at college (this was beginning over a year ago), and have since moved on to Objective-C. -- Chris Garaffa [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology{O|T} kinda'
On Fri, 30 Jan 2004, Jay Blanchard wrote: I'd be curious as to how many cam to PHP from a programming background? Likewise, how many start with PHP and go on to other languages? And what those languages are either direction? I started serious coding in perl. When I found PHP, I realized I was killing myself trying to do CGI with perl, and quickly migrated. That transition was easy, and my life got better. After a couple of years coding in PHP I made a foray into Python. I learned OOP with Python and was able to work that knowledge into my PHP programming easily. Using OO with PHP simplified a lot of problems I'd had trying to do more complex tasks with a procedural/functional approach. I still use perl to whip up a sysadmin script here and there, but after using Python I began to regard perl as a syntactic mess. -- Kelly Hallman // Ultrafancy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP methodology{O|T} kinda'
Jay Blanchard wrote: [snip] Experience has chown that smaller simpler languages are easier to learn and apply than larger ones. [/snip] Obviously. :) I'd be curious as to how many cam to PHP from a programming background? Likewise, how many start with PHP and go on to other languages? And what those languages are either direction? Here's my progression: BASIC - Turbo Pascal - C - C++ - PHP. Yes, I came to PHP from C++, having learned OO in C++. But honestly, I've learned a lot more good OO practices in PHP than I ever did in C++. -- paperCrane Justin Patrin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP methodology
On Fri, 2004-01-30 at 04:41, Chris Neale wrote:
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.
Others have already commented on the OO structure and I agree that this
approach looks sound. I do have a comment about the code you
illustrated. I noticed you are passing the iterator to the
HTMLGenerator on instantiation, then afterwords processing through the
iterator and calling methods on the HTMLGenerator. Since the
HTMLGenerator has a copy of the iterator it could theoretically do this
itself. For example:
$q = new dbObj;
$x = new iterator;
$y = new HTMLGenerator($q)
$y-processIterator($x);
And then create the processIterator method like so:
HTMLGenerator::processIterator($iterator) {
while ($data = $iterator-next()) {
$this-MakeHTML($data);
$this-outputToFile();
}
}
This will logically allow you to do more things with your HTMLGenerator
(like generate HTML that is not tied to the iterator) as well as use
different iterators in the same HTMLGenerator instance, etc. Also, if
the iterator is what is using the dbObj class (to iterate through the
database data) then consider passing it to the iterator instead.
Regards,
Adam
--
Adam Bregenzer
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOP methodology{O|T} kinda'
Ok sorry, c++ then, yes thats another kettle of fish, i'm going to be doing
some c++ to learn how to make vst plugins :D
-Original Message-
From: Jay Blanchard [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 10:51 PM
To: electroteque; [EMAIL PROTECTED]
Subject: RE: [PHP] OOP methodology{O|T} kinda'
[snip]
Yes i think java would be the best to learn proper OO, i've nevr done
it,
but coming the other way knowing php OO, java became more familiar to
me,
i'm gonna do it this year.
[/snip]
Why not start with the king of OOP, C++? Currently C++ is the most
robust implementor of OOP design issues. From there it is easier to come
to grips with PHP, JAVA and any other language in which you may need or
want to use OOP. I heartily recommend that JAVA is NOT the way to learn
OOP.
--
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
