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.

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.

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.

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.

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.

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.