To OOP or not to OOP

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
This is partially an opinion question.  I have some modularization for my  
main site using vanilla PHP.  I'm a one-man operation.

Is there any major benefit to learning and using OOP?  I have lots of other  
stuff to be spending my limited intelligence learning.  

Re: To OOP or not to OOP

Quoted text here. Click to load it

OOP is VERY useful for one-man operations. Learning OOP, however, is
somewhat time-consuming (which is not good for one-man ops).

If you're in PHP 5, you're a lot better off OOP-wise. This makes it a
little difficult, if you learn PHP5 and use it's OOP features, but
then somehow get stuck in PHP 4, which is a lot more free-wheeling
(think JavaScript).

This is a really difficult question to answer, since bad OOP-
influenced code can be WORSE than some procedural or functional code.
But it sure makes it a lot less finger-breaking to code:

class Build_Html_Page {
    public static function __construct($key) {
        $str = $this->getHtmlHeader() .
                   $this->getHtmlBody($key) .
        return $str;
    protected function getHtmlHeader() {
        include BASE_PATH.'/INC/';
    protected function getHtmlFooter() {
        include BASE_PATH.'/INC/';
    protected function getHtmlBody() {
        include BASE_PATH.'/INC/switch_content'.
    protected function getSwitchKey() {
        $key = empty($_GET['section']) === true ?
                   'index' : $_GET['section'];
        return $key;
$site = new Build_Html_Page();

There you have a very low-key front-controller for a website. If you
want to change the switch section key logic, it sits in one place, and
one place only.

I personally like:

Also, try the Google Maps API to see a professionally-developed OOP
script (in JavaScript). Once you use objects well-developed, it makes
all the difference.

Re: To OOP or not to OOP

Quoted text here. Click to load it

Also, Harry Fuecks over at has some really good books on

If you want to learn to code using OOP techniques, you also MUST learn
about design patterns: (computer_science)

Re: To OOP or not to OOP

Gregor wrote:
Quoted text here. Click to load it

Yes, OOP is well worth learning.  If you do it properly, it can make  
code much more reusable and manageable.

The problem is there are a lot of self-styled "experts" on the web who  
really don't know what they're talking about.  Look for books from  
recognized experts in the field.  Your library can be a good starting point.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: To OOP or not to OOP

Jerry Stuckle wrote:

Quoted text here. Click to load it

Aside from "PHP5 OOP" books, I suggest that you read some books
about "Design Patterns". It will teach you some algorithmics that are only
possible with OOP (better said, very difficult without).

Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Dios Mío Está lleno de firmas!

Re: To OOP or not to OOP

Ivn Snchez Ortega

Quoted text here. Click to load it

And I present to all:
"PHP 5 Objects, Patterns and Practice" by Matt Zandstra

Been working through it over the past couple of weeks... highly recommended

Re: To OOP or not to OOP

Thanks for this and all of the many very helpful posts.

I just ordered this.  I guess the only way I'm going to get a final answer  
is to try it out, sigh.

Quoted text here. Click to load it

Re: To OOP or not to OOP

On 28.05.2007 22:44 Gregor wrote:
Quoted text here. Click to load it

OOP is like glasses. You don't understand how it can be useful until you  
really need it. If you feel comfortable without OOP, it isn't worth  
learning (yet).

gosha bine

extended php parser ~
blok ~

Re: To OOP or not to OOP

gosha bine wrote:

Quoted text here. Click to load it

Continuing the analogy further... and they might seem uncomfortable at
first, but that's not a reason to not persevere!

Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.12-12mdksmp, up 94 days, 20:03.]

                           Non-Intuitive Surnames

Re: To OOP or not to OOP

Gregor wrote:
Quoted text here. Click to load it

Well, all depends on your limited time.

There *are* alot of benefits learning OOP like more reusable and  
manageable code, you will be able to create better code and the ability  
to create more stable and error proof code.

I don't like the "glasses"-analogy because it's not only useful if you  
*need* it. Things can be useful also if you don't need it to fulfil your  

The negatives are that you can create some nasty bugs with OOP  
especially on more complex projects. Also some programmers tend to  
overuse OOP. There's nothing wrong with functions and some procedural  

Re: To OOP or not to OOP

My 2 cents. I come from a Java and Visual C++ background, so I am very
comfortable with OOP. When I developed a website that now gets about
100,000 viewers a day, I did OOP. That's because PHP5 was touted to be
better with OOP.

Long story short. My code is now procedural. Very clean, organized in
functions and commented richly, and separated out in files (which is
how you'd separate "Class" files anyway). Over time I realized two

1. Minimize require calls. (And use require instead of include or
include_once or require_once).
2. Use an accelerator, such as eAccelerator. This compiles your code
and basically boils it down to one include in most cases.

In reality, if you are learning the language then OOP may be a classy
thing to learn and it's good to know. Performance wise procedural is
best. I don't buy the cleanliness and maintenance stuff one bit.
Procedural  code can be equally clean and well laid out. And it
performs significantly better -- no instantiation of classes and

This is simply my experience.

Re: To OOP or not to OOP

L. Berger wrote:
Quoted text here. Click to load it

Well that's a good point i forgot.  The overall performance is not as  
good as procedural programming.

Then - on the other hand - the performance hit depends highly on the  
design. It's possible to OOP with a minimal performance hit.

Cleanliness and maintenance is important if you have complex web  
projects with many changes and additions.

Re: To OOP or not to OOP

* * *
Quoted text here. Click to load it

* * *

Could you explain these for me please, if you have the time?

I can understand the obvious reasons to minimize require calls, but why do  
you prefer, say, "require()" over "require_once()"?  And why not use  
"include()" for, say, a block of stand-alone text when you would rather see  
it omitted than have the page not load?

I have never heard of an accelerator.  I'm assuming it acts a bit like a css  
optimizer, perhaps sort of a poor man's framework?  Does eAccelerator ever  
create bugs, like css optimization programs?  

Re: To OOP or not to OOP

Quoted text here. Click to load it

Sorry, it was not very clever of me to make a pronouncement without
explanation. First, let's compare include and require, two

1. Include will only include the file when conditionally appropriate,
require will simply include it. In reality, especially when using an
accelerator (more about that below), require simply becomes a part of
your code. This is better than the PHP executable having to do some
additional processing to figure out whether something was necessary to
include or not. It's always there. When it is converted to bytecode,
it's there.

2. Include throws warnings, require throws errors -- which is an
important consideration for production level code. An application that
I had worked on (during corporate years) used "includes" of pretty
important functionality that went into transactions. Because this was
production server, the "error_reporting" was set to "E_ALL ^ E_NOTICE
^ E_WARNING". When includes failed, the warnings were not thrown out,
the transaction went incomplete but done. In cases like these
"require" is quite important ("includes" with checking for file
existence would have been much slower).

So yes, it depends on your particular situation and what your
application does (for small apps either is fine) but require has
turned out to be more effective for me.

Quoted text here. Click to load it

Google is your friend :) eAccelerator is the latest version of an
older caching solution, memturk. It's turned out much better for me
than APC especially when . Basically, these products compile your PHP
code into byte code, then store it in memory. As far as I know,
eAccelerator does not break any functionality and is highly tested by
the OSS community. There's a good explanation (and some thoroughly
unscientific testing) at these sites: or
-- which show that eAccelerator

Re: To OOP or not to OOP

At Wed, 30 May 2007 10:55:52 -0700, L. Berger let h(is|er) monkeys type:

Quoted text here. Click to load it

Nonsense. Include and Require Both do as told unconditionally. You are
mistaken. Check it, try including a php class or func definition file
Conditional inclusion/requirement is happens with include_once
and require_once.

Quoted text here. Click to load it

Yes, it is. I think no production code ought to spit out errors or
warnings which haven't been handled by the programmer. Do your own error
checking, use try/catch blocks, don't let PHP simply spew out default
errors. Which renders your second point moot as well imho.

Schraalhans Keukenmeester -
[Remove the lowercase part of Spamtrap to send me a message]

  "strcmp('apples','oranges') < 0"

Re: To OOP or not to OOP

Gregor schreef:
Quoted text here. Click to load it
One thing OOP is great at that is hard to do with procedural code is  
hiding different implementations under a common interface. Look for  
example to php's PDO (PHP Data Objects, see ). Several classes implement  
the PDO interface for different databases. At the start of your script  
you only have to instantiate the right class. From then on all the calls  
to the PDO objects will be the same, so if you want to make your script  
work on a different database, you will not have to go through your  
script to change all function calls. (Of course the PDO has it's  
limitations, it will not solve incompatibilities between the SQL  
dialects of the different databases.

OOP beginners can learn something else from this example too: It is not  
inheritance that matters, it's delegation. In the case of your script  
using PDO objects, the script is said to delegate to the PDO objects. It  
does not inherit from them. It may even be a procedural script. Yet it  
uses their functionality in a flexible way: the implementations can  
change by using an object of a different class.

Having different implementations for the same service is called  
polymorphism. Every OOP method call is a possible place to introduce  
polymorphism. Right away, or later on, when new end user demands need to  
be met.

If we use an object of a different class, all implementarions defined in  
that class come into effect together.  So classes bundel  
implementations, and therfore they limit flexibility. But using classes  
can improve understandability. The CRAFT of object oriented design is to  
balance understandability (simplicity) against flexibilty. The ART of  
object oriented design is to invent elegant solutions that maximize both.


Henk Verhoeven,

Re: To OOP or not to OOP

Quoted text here. Click to load it

Nice post.

Site Timeline