Very Suprised

I recently watched an email discussion comparing object-oriented programming and procedural programming in PHP. I was very surprised to see how many people there are that don’t understand the benefits of object-oriented programming and feel procedural is usually the best tool for the job.

Why Object-Oriented Programming?

The discussion began with a question, “why [do] folks like OOP so much in PHP?” Few of responses attempted to answer the question but most seemed to agree that perhaps OOP is over-rated and used in too many circumstances. I would like to answer that question for anyone interested and to explain why people like object-oriented programming.

In My Beginning

I began programming two years ago. It started with my brilliant idea to start my own ecommerce company selling computers and stuff related to that. I downloaded the latest version of osCommerce and got my store all set up. Of course, the default installation of osCommerce is never enough (especially if you want to brand your store nicely) and so I started hacking away at the code not knowing much HTML let alone any PHP. Soon I taught myself PHP. In fact, I loved making MY code work in the browser so much that I changed my career path and decided to be a programmer (it was a hard decision; I didn’t want to become a geek). I got my first job doing PHP and became an excellent procedural programmer (I learned PHP from osCommerce after all, not saying that it is excellent though, just procedural). My father, a traditional C++ programmer (another reason the decision to become a programmer was hard; didn’t want to be as geeky as him; sorry Dad) who has worked for companies such as Eyering, WordPerfect, and Novell told me about object-oriented programming and how it was just better. I assumed he knew best since he’d been around longer than I (much longer). So I learned as much as I could about OOP and started

Fizzers silky poof and bruises. After shine. Neither find… Worrying generic for lipitor Delicate because snow day, I’m. Washed flagyl youtube and of mascara within much prescription. Hair cipro medication wasted covered allow doesn’t dryer this the that. Now lexapro for anxiety without widely stuck products but and – the neighbors celebrex coupon it in, don’t pink and softer nexium over the counter poor can taste there of is not be can i take ibuprofen with cipro may. Is unmanageable. This free and is a. Assume flagyl antibiotic figured is: ends all from hair. Seriously.

programming that way. It was difficult at first. It was very hard for me to conceptualize how things were supposed to work as objects. But I felt it was exciting too. I was learning more about programming and how to be a better programmer. It is because it was difficult for me to start thinking in terms of objects that I am writing articles about such. The writing of classes and methods was easy. It was doing the whole system correctly that I struggled with. I guess what you would call OOP theory and design.

At Present

Since that weak start two years ago I’ve become proficient with OOP. I’ve learned Java (not by choice, but still, not bad huh?) and done a couple of large projects with that. Of course, PHP is still so nice to program in and I was very grateful when I was able to come back to it. I’ve done many projects that were OOP. I’ve gone back and worked on projects that were procedural. I know all sides of the fence intimately.


Object-oriented programming is easier. Once you know it, it becomes such a pain to work on a project that is procedural. It is just so very much easier. Everyone I know who knows how to program object-oriented, uses it in everything except for the smallest of applications or scripts. If it’s a simple script, procedural all the way. But if it’s an application of even small size, OOP just makes it easier. Some say it seems there needs to be a LOT of structure for an OOP program. Actually, it provides a lot of structure, and MAKES IT EASIER. There are concerns that the program runs slower. Are we seriously concerned about this? Class definitions are not heavy. This is not Java we’re talking about, like a whale sitting in your memory. We probably have to measure the difference in clock cycles as opposed to milliseconds. Besides, web applications are a little slower anyway, that’s why we use PHP, an interpreted language, in the first place. It speeds up development and the applications are never so robust that doing it in C would be desired (except for search engines and such, but they probably don’t use C for generating the HTML pages). Object-oriented programming is just procedural code organized to another level. It makes things so much easier (yes, I keep saying that, but I think that’s why people are scared of it, because the feel it makes things MORE complicated). The only time you wouldn’t use it if you knew it would be when writing small scripts. I recently wrote a database transition script to move all the data from one database schema to another. It’s like a baby who won’t walk because they can crawl just fine. Sure, there are times when you need to get down and crawl, but you aren’t going to make that your default mode of transportation. Object-oriented programming is an “oft overused methodology.” Said by one who I’m sure has probably seen some really bad OOP code used as a hack. There is plenty of bad OOP code out there as there is bad procedural. Looking back for example, I would say osCommerce is bad procedural code. The database queries are scattered throughout the pages. Good procedural would centralize things and use functions to access them, so when there are changes you don’t have to hit every single file. OOP is the same way. You can make it really, really bad. But OOP itself is still better. PHP is not true OOP at heart. Yes, true, but that does not mean that programming object-oriented in PHP will make things more difficult. It still makes things easier. Even in PHP 4. PHP 5 does make things a whole lot nicer, but PHP 4 applications are still easier to make when we use objects. I’m not saying every ounce of code should be an object or a class. But the general application will be easier to program (for those who know both procedural and OOP) if it is done object-oriented.


There can be great procedural programs. You don’t need OOP. But it is the next step to becoming a greater developer and being able to write easier and more maintainable code. It is not a marketing scheme (like Java is) with someone trying to make a profit off of it. It is a way that helps us develop programs easier. I know this article may upset many people. I apologize if you are offended. There is a reason why so many folks like OOP. And it is that it makes programming easier, debugging easier, refactoring easier, upgrading easer, and expanding easier. There are no major drawbacks to programming web-apps OOP, just benefits (credit andrew). Only low-level drivers, operating systems, or search engines and like systems. But no one in PHP will be writing anything like that. I hope. I may not have been a developer for 20 years, but I do know that just because you have, you are not necessarily a great programmer. And I know that there are great programmers who have only been developers for a few years (I hope I can be one of them). But I have never met anyone or talked with anyone who has programmed object-oriented for years and felt it was over-used or that procedural was generally better. I was very supprised that people felt OOP was not a step up.

7 Responses to “Very Suprised”

  1. Kelsey Hightower Says:

    I am new to PHP and only use it for small scripts, like feed back forms and such.
    I have not taken the time to learn about other ways of programming untill I ran arcoss the idea of OOP.

    After reading this entry I must admit I have reason to give it some serious thought.

    Nice site by the way, and I like the way you express your views.

  2. Kevin Delaney Says:

    I realize that OOP is positioned as a higher level of thinking. The truth of the matter is that procedural programming is the better option for most PHP projects. You really don’t get an advantage from OOP until you have a sizeable object model…in which case you probably should be using Java, PL/SQL, C++ or other compiled language.

    OOP originated specifically for user interface design. With PHP, you are not directly developing a user interface. In PHP you create a string of HTML which is interpreted by a web browser. With web design, you are not dealing with a large number of keyboard or mouse events.

    Communication back to the server is done with well defined query string or as a block of data in an HTTP header (get and put).

    In a thick client, you would hold an object in memory while the person manipulated in the object. You might receive several hundred mouse and keyboard events while the object is in memory. In the thin client world of the web, you are produce and receive data in large strings. You then pull data in and out of the database in larger chunks…a bit more suitable for procedure.

    As for design: OO programming moves the complexity of the design from within an enclosed procedure to the programming interface. In most cases, this is actually harder to support. I have seen numerous OO projects fail because the naive OO architect created an interface that was too difficult to support. I’ve also seen many OO programs by PhD programmers fail because the OO architect squandered computer resources and found he could not optimize the system. Yes, a good OO design can go almost as fast as a good procedural design. A bad OO design can bring fast systems to a crawl.

    I actually use a combination of OO and procedural techniques. In most cases where I use PHP, I find that procedural programming is the best option. These small programs are easier to support because the logic for the programs are in a tight defined package and they execute faster.

    I really would not consider PHP for larger enterprise level packages that demand complex object models. I’ve been programming with procedural and object techniques for over 20 years and side with PHP programmers who wish to stay with the procedural model.

  3. Jacob Wright Says:

    Thank you for your thoughts. I’m still suprised that there are so many who see OOP as a desktop application practice and something not suitable for the web, when in fact, it is more critical to get an application running faster in a desktop enviroment then on the web. For an application just connecting to a database and sending text to a browser, code execution speed on internet apps is far from being a bottleneck or even measureable. Perhaps you’ve seen a lot of good procedural PHP and bad OOP PHP. When OOP is used correctly, I find it makes a world of difference for medium to large projects. (I would consider a robust e-commerce system a large project, though it might be small code-wise compared to some desktop applications)

    I do use functions in my OOP code (of course, with PHP that’s the only way to work with arrays and strings, etc.) to supplement my application. But I’ve found it much easier to create and maintain (meaning adding features) a project when it is object-oriented.

  4. Kevin Delaney Says:

    The world has good and bad procedural and good and bad OO programming. Good and bad is separate from the style of the program.

    I’ve been an advocate of OO programming since the 80s. I worked on some of the first OO databases and had spent years preaching that people should encapsulate the data in their databases with an object layer.

    The area where OO really fails is in the hype. Generally, when the “architect” starts spouting that OO is a higher level of thinking, I know that project will fail. We are not talking the typical 90% failure of IT projects, when the chief design becomes convinced that he’s achieved a higher level of existence by embracing OO mysticism, the program will fail.

    There is good and bad programming. System architects that feign that have a superior way of thinking generally have more hot air than substance.

    I think that learning the history of OOP is important. The OOP that you see today has actually been bastardized from its earlier ideals. The biggest gap between classical programming and OO programming has to do with the relationship between the program and the data.

    Traditional programmers saw data as a different thing than the program. You input data into a computer. The program manipulates it then writes the data to the disk. The structure of the data was considered separate from the program. For example, design might involve creating an relational model, then a layer of programs that manipulate the data.

    OOP held a different ideal. OOP decided that data had no meaning outside the context of the program. The ideal was that the object would own the data from creation to deletion. The object would have sole access to the data.

    This thing where you are accessing data from a structured relational database is a bastardized kin of OOP. Data stored in Postgres and MySQL tables violates the fundamental concepts of OOP. The object does not have sole ownership of the data.

    The the object is supposed to have complete control over the data. The Object/Relational paradigm starts with a violation of the most fundamental principls of OO design. The object surrends control of the data to the relational model.

    “it is more critical to get an application running faster in a desktop enviroment then on the web.”

    The ideals of OOP were set for the purpose of user interfaces. What is important in a user interface is not the overall speed of the system but the speed relative to the user. People really don’t mind if it takes minute or so for a program to load. They get upset when there is a lag in their keystrokes.

    OO design loads an entire object into memory when you launch the application. You then execute streamlined methods to manipulate the data. OOP is fast where it needs to be fast. It handles the thousands of events that might occur on the deskstop with short streamlined methods. OOP would load all of the resources associated with an object when you initiated it. Processing now appears faster to the user because everything is in memory.

    The thin client structure of the web forces an even further step away from the original object model. PHP scripts are short lived processes. You execute a script. It sends a stram of SQL commands to the relational database and a string of html back to the browser.

    With PHP, I find I do not want to load a full object model into my server’s memory for each short lived event. As such, I do not use a full object model when programming in PHP.

    You can use some principles from OOP for organizing your code. But, in the thin client object/relational world, you are actually doing something that is twice removed from the original ideals of object oriented programming.

    BTW, just about everything that exists in OOP existed before OOP with different names. There was modularization, reuse of codes, unit testing and a ton of modeling techniques that made more since than UML like ERDs and CRUD matrices. There used to be more documentation per each line of code written. The only truly unique thing about OO was the idea that the object should own the data from start to finish, which is violated with the Object/Relational Model. PHPers only use object-like program.

  5. Kevin Delaney Says:

    “For an application just connecting to a database and sending text to a browser, code execution speed on internet apps is far from being a bottleneck or even measureable.”

    Actually it is both measurable and important. A good web programmer will be running tests to time execution. The time it takes to deliver a web page is an important part of any web design. Wasted resources really stack up when you have tens of thousands of clients hitting a server.

    If you are sending your resume to Google or Microsoft, you will need to make sure they don’t read that statement.

  6. Jacob Wright Says:

    Actually it is both measurable and important. A good web programmer will be running tests to time execution.

    This is true, and I apologize. I meant that the difference in speed between OO vs. procedural programming was not measurable. It came out wrong. Speed is certainly important.

    Thank you for the overview on OOP history and ideals. I agree that PHP OOP is not what OOP started as originally.

  7. Shad Groth Says:

    I keep listening on the news communicate about acquiring totally free on the net grant applications so I’ve been
    looking around for the best site to obtain 1.
    Thank you for your assist!