what gave you the most hassle?
Moderator: General Moderators
-
magicrobotmonkey
- Forum Regular
- Posts: 888
- Joined: Sun Mar 21, 2004 1:09 pm
- Location: Cambridge, MA
- Ixplodestuff8
- Forum Commoner
- Posts: 60
- Joined: Mon Feb 09, 2004 8:17 pm
- Location: Queens, New York
OOP isn't really that new. It's just been the most recent rage. OO goes way back to Simula and Smalltalk. Well before Java (since some people seem to think otherwise).magicrobotmonkey wrote:Yea, OOP is relatively new, I think there must have been some good code written before it! It just makes it a lot easier to aboid spaghetti (once you know it...)
Cheers,
BDKR
Probably the more complex an application gets the more you get pushed into OOP.
The argument against procedural code is perhaps the same as the one against "loose" scripts with everything in the global scope. Good design creates modular components and layers by encapsulation: chunks of code in fns, or state in classes with an interface to manipulate/access state (although classes sometimes can be "do-ers" more than the "things" they are classically held to be). Fns allow a certain, useful amount of encapsulation, but OOP provides much more.
I seem to have been banging on a lot about decorated iterators recently - very flexible and powerful tools (there's always a lot of looping in web apps). Once you tried this well-worn example, you just can't go back:
You can take any data source you like - db query, directory structure, csv file etc and print it in a table using the same Table class. You can insert further Decorators if you need to process the basic iterator rows before passing them on to the Table decorator. Eg you could use a Ranker decorator with QueryIterator to add a ['result_rank'] key to each row.
Classes can be easily swapped in and out.
Simple, flexible, elegant: that's the smell of good OOP.
The argument against procedural code is perhaps the same as the one against "loose" scripts with everything in the global scope. Good design creates modular components and layers by encapsulation: chunks of code in fns, or state in classes with an interface to manipulate/access state (although classes sometimes can be "do-ers" more than the "things" they are classically held to be). Fns allow a certain, useful amount of encapsulation, but OOP provides much more.
I seem to have been banging on a lot about decorated iterators recently - very flexible and powerful tools (there's always a lot of looping in web apps). Once you tried this well-worn example, you just can't go back:
Code: Select all
<?php
/*
Table is an iterator decorator which prints 2D collections (iterators) in a table.
The same Table class can print any type of collection.
*/
// db query results
$table =& new Table(new QueryIterator($query));
// directory contents
$table =& new Table(new DirectoryIterator($directory));
// parsed file contents
// CsvParser (another decorator) parses cols from each FileLineIterator line
$table =& new Table(new CsvParser(new FileLineIterator($file_path)));
// finally, print the table:
$html .= '<table>';
for($table->reset(); $table->isValid(); $table->next())
{
$html .= $table->getCurrent();
}
$html .= '</table>';
echo $html;
?>Classes can be easily swapped in and out.
Simple, flexible, elegant: that's the smell of good OOP.
Last edited by McGruff on Tue Aug 09, 2005 3:35 am, edited 1 time in total.
-
magicrobotmonkey
- Forum Regular
- Posts: 888
- Joined: Sun Mar 21, 2004 1:09 pm
- Location: Cambridge, MA
A farm, eh? Hmmm...
class AnimalManger
{manipulators}
feed
muckOut
butcher
{accessors}
getProducts
class PigManager extends AnimalManager
(overides the base class interface)
class CowManager extends AnimalManager
(overides the base class interface)
class ChickenManager
(overides the base class interface)
class AnimalManger
{manipulators}
feed
muckOut
butcher
{accessors}
getProducts
class PigManager extends AnimalManager
(overides the base class interface)
class CowManager extends AnimalManager
(overides the base class interface)
class ChickenManager
(overides the base class interface)
Code: Select all
<?php
/*
CLASS
*/
class FarmManager
{
function FarmManager()
{
$this->pigs =& new PigManager();
$this->cows =& new CowManager();
$this->chickens =& new ChickenManager();
}
function todaysChores()
{
$this->pigs->feed();
$this->pigs->muckOut();
$this->cows->feed();
// ..etc
}
function getProducts()
{
$this->pigs->butcher();
$this->cows->butcher();
$this->chickens->butcher();
return array($this->pigs->getProducts(), $this->cows ..etc);
}
}
///////////////
// END CLASS //
///////////////
// manage the farm:
$manager =& new FarmManager();
$manager->todaysChores();
// bad news piggies it's market day
$manager->getProducts();
?>
Last edited by McGruff on Tue Aug 09, 2005 3:34 am, edited 2 times in total.
-
magicrobotmonkey
- Forum Regular
- Posts: 888
- Joined: Sun Mar 21, 2004 1:09 pm
- Location: Cambridge, MA
I agree with this to a point. I think it depends on what it is you are developing, the language you are using, and the target audience.McGruff wrote: Probably the more complex an application gets the more you get pushed into OOP.
But even still, define complex. Additionally, there are some rather complex hunks of code out there (far more so than what many of us will ever do in PHP) that are procedural. How about the Linux kernel? It's not really a matter of complexity as it is an issue of the size of the project
Actually, the argument against procedural code should be that it doesn't do anything to help the "Software crisis". When comp scientists of note started to notice that projets didn't get done any quicker as developers were added, they began to realize that something was amiss. Many of the same things they noted are issues that are resolved with OOP. All of those OOP things like information hiding, private methods, encapsulation, etc... are there to help teams of developers work together without blowings their legs off.McGruff wrote: The argument against procedural code is perhaps the same as the one against "loose" scripts with everything in the global scope. Good design creates modular components and layers by encapsulation: chunks of code in fns, or state in classes with an interface to manipulate/access state (although classes sometimes can be "do-ers" more than the "things" they are classically held to be). Fns allow a certain, useful amount of encapsulation, but OOP provides much more.
When you say good design, do you mean object oriented design (OOD)? I use OOD all the time, but not OOP. A subtle but important distinction to make.
Anyway, good design happens regardless of whatever paradigm you choose to worship. If good design was simply a matter of a chosen paradigm, then PHP would be written in C++ instead of C, as would Windows, Linux, Unix, Quake 1 - 3, etc.....
Cheers,
BDKR
- llanitedave
- Forum Commoner
- Posts: 78
- Joined: Thu Jan 15, 2004 11:24 am
- Location: Las Vegas, NV.
