[thelist] php design question

Andrew Forsberg andrew at thepander.co.nz
Mon Nov 18 20:49:01 CST 2002


> thanks andrew, i do see somewhat more now
>

yay.

>> classes are normally included via ...
>
> stop right there
>
> includes are normally included, too
>
> what's the difference?
>

in your CF app, like a php app, you'd might do something like this

// get your db connection

// work out what the page is meant to do
// (e.g., parse GET variables to see what the user wants)

// retrieve your data

// format it

// output it

everything is done one step after the other. that's the 'procedural'
method. the other method which is still fairly fashionable (and,
arguably, unsuited to PHP's object model) is the 'object oriented'
method (OOP). that's where you do something like this:

// make a db connection

// make a page object -- let it work out what info's required by the
user
// -- let it work out how to get info from the db
// -- let it retrieve the data
// -- let it format it
// -- let it output it

what's the difference? well, nothing to the end user. to the developer
it's important if the language is java, or c++, or python, or
whatever-else. to a php developer it could get right messy after the
second version of the zend engine is released (when php becomes a bit
more sensible as an OOP language, imho, no flames please).

the primary advantage of using objects is, as Andy Warwick pointed out,
encapsulation -- all that page info, all the stuff that page does, is
internal. say in your CF app you had an include that had a variable
called pageID -- and you include that on every page. you use it to
retrieve your page from a db. now say your menu is dynamically
generated in a loop where there are many pageIDs floating around... it
could get messy. it shouldn't if everything is well designed, but it
can. under the OOP model your page object has its own ID and nothing
can alter it without asking it first (again, if everything is well
designed).

perhaps a slightly better example is the case of APIs -- say you're
building group of functions which extend on the provided PHP db
functions, and you want to support more than one vendor's db. a
class/object system is great in this situation --

$db = new db('mysql','localhost','whatever'....)
$db->query = "UPDATE WHATEVER .....";
$db->runQuery();

so you can have several objects with different queries, or even
database servers, running concurrently, and they're all grouped in
easily identifiable spaces (each object holds inside itself all the
stuff it needs).

i don't think there's anything one can *do* with the OOP model that
isn't possible with a procedural model, and i prefer the latter (that's
probably obvious by now), but i guess the point is the response to the
original post was encouraging Tom to reconsider his approach to the
problem -- to use a different programming methodology, rather than a
different programming function.

andrew's last ditch effort to make a point:

RDBMS vs XML

but wait, there's more:

>
>> then, say we wanted to add a new listing to the menu:
>>
>> $menu->addOption("stir the cocktail", "/index.php?go=stir");
>
> in my case, the data is either in the database or on its way
> to the browser as html -- i don't see why i have to store it in
> an object if i just want to output what's in the database
>
> or delete it?  shoot, if i wanted to delete a menu item, i'd better do
> that in the database, or i'm screwed
>
> or change its colour!??  hey, my style sheet governs that!!
>

how about $order->addProduct('shoes');
or
$myTable->addColumn($columnName, $columnType);


>> finally, to output the menu one might:
>>
>> $menu->printMenu();
>
> i'm getting the idea, but i don't see how this gives me the flexibility
> i need in separating form from content
>

the examples may be poor -- how about if the above was:

$menu->applyTemplate("BlueTemplate");
// where BlueTemplate was retrieved from a database table of CSS styles
$menu->printMenu($system);
> thanks andrew, i do see somewhat more now
>

yay.

>> classes are normally included via ...
>
> stop right there
>
> includes are normally included, too
>
> what's the difference?
>

in your CF app, like a php app, you'd might do something like this

// get your db connection

// work out what the page is meant to do
// (e.g., parse GET variables to see what the user wants)

// retrieve your data

// format it

// output it

everything is done one step after the other. that's the 'procedural'
method. the other method which is still fairly fashionable (and,
arguably, unsuited to PHP's object model) is the 'object oriented'
method (OOP). that's where you do something like this:

// make a db connection

// make a page object -- let it work out what info's required by the
user
// -- let it work out how to get info from the db
// -- let it retrieve the data
// -- let it format it
// -- let it output it

what's the difference? well, nothing to the end user. to the developer
it's important if the language is java, or c++, or python, or
whatever-else. to a php developer it could get right messy after the
second version of the zend engine is released (when php becomes a bit
more sensible as an OOP language, imho, no flames please).

the primary advantage of using objects is, as Andy Warwick pointed out,
encapsulation -- all that page info, all the stuff that page does, is
internal. say in your CF app you had an include that had a variable
called pageID -- and you include that on every page. you use it to
retrieve your page from a db. now say your menu is dynamically
generated in a loop where there are many pageIDs floating around... it
could get messy. it shouldn't if everything is well designed, but it
can. under the OOP model your page object has its own ID and nothing
can alter it without asking it first (again, if everything is well
designed).

perhaps a slightly better example is the case of APIs -- say you're
building group of functions which extend on the provided PHP db
functions, and you want to support more than one vendor's db. a
class/object system is great in this situation --

$db = new db('mysql','localhost','whatever'....)
$db->query = "UPDATE WHATEVER .....";
$db->runQuery();

so you can have several objects with different queries, or even
database servers, running concurrently, and they're all grouped in
easily identifiable spaces (each object holds inside itself all the
stuff it needs).

i don't think there's anything one can *do* with the OOP model that
isn't possible with a procedural model, and i prefer the latter (that's
probably obvious by now), but i guess the point is the response to the
original post was encouraging Tom to reconsider his approach to the
problem -- to use a different programming methodology, rather than a
different programming function.

andrew's last ditch effort to make a point:

RDBMS vs XML

but wait, there's more:

>
>> then, say we wanted to add a new listing to the menu:
>>
>> $menu->addOption("stir the cocktail", "/index.php?go=stir");
>
> in my case, the data is either in the database or on its way
> to the browser as html -- i don't see why i have to store it in
> an object if i just want to output what's in the database
>
> or delete it?  shoot, if i wanted to delete a menu item, i'd better do
> that in the database, or i'm screwed
>
> or change its colour!??  hey, my style sheet governs that!!
>

how about $order->addProduct('shoes');
or
$myTable->addColumn($columnName, $columnType);


>> finally, to output the menu one might:
>>
>> $menu->printMenu();
>
> i'm getting the idea, but i don't see how this gives me the flexibility
> i need in separating form from content
>

the examples may be poor -- how about if the above was:

$menu->applyTemplate("BlueTemplate");
// where BlueTemplate was retrieved from a database table of CSS styles
$menu->printMenu($system);
// which collates and outputs all the html and css for the menu system
if $system is "HTML", or a printer friendly version, or a PDF, or
whatever...

form and content can still be as separate as your code allows.

>
> i would imagine -- feel free to enlighten me -- that the guy writing
> the
> html will have something to say about how a menu should be displayed
>
> if you encapsulate style into content, isn't that a step backward?
>

only if it's hard coded into the program. but that applies to OOP or
procedural programming.

bottom line: it's a methodology -- socialism vs communism vs capitalism
vs anarchism. they all attempt to do the same thing: structure a
community's politics. OOP vs procedural, they're different ways of
structuring the way a program works. OOP has been more fashionable for
15-odd years (feel free to correct, that's a half-arsed guess). with
procedural programming you have a flow chart, with OOP you get a nice
structural tree of relationships (parents -- children)  (to impress
management with, no doubt) , as well as a flow chart.

[fwiw, i'm quite enjoying this after an evolt leave of absence:) ]


// which collates and outputs all the html and css for the menu system
if $system is "HTML", or a printer friendly version, or a PDF, or
whatever...

form and content can still be as separate as your code allows.

>
> i would imagine -- feel free to enlighten me -- that the guy writing
> the
> html will have something to say about how a menu should be displayed
>
> if you encapsulate style into content, isn't that a step backward?
>

only if it's hard coded into the program. but that applies to OOP or
procedural programming.

bottom line: it's a methodology -- socialism vs communism vs capitalism
vs anarchism. they all attempt to do the same thing: structure a
community's politics. OOP vs procedural, they're different ways of
structuring the way a program works. OOP has been more fashionable for
15-odd years (feel free to correct, that's a half-arsed guess). with
procedural programming you have a flow chart, with OOP you get a nice
structural tree of relationships (parents -- children)  (to impress
management with, no doubt) , as well as a flow chart.

[fwiw, i'm quite enjoying this after an evolt leave of absence:) ]




More information about the thelist mailing list