Why many popular opensource PHP apps are plain script [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

This is part observation, part question.

First the observation:

While everyone talks of modular programming, OOP, procedural done right, aspect oriented, design patterns, etc., several popular opensource PHP apps are plain script files with the structure being controlled by includes and requires.

This looked stupid to me till I faced a recent issue with my shared web host - they don't support MySQL stored procedures on shared hosting. I checked out many comp开发者_开发百科eting shared hosting packages - same story.

Then I rewrote the code using SQL queries and some static functions in DB-handling class.

That was when I realised that the said PHP projects actually take into account the whole spectrum of web hosting packages and so decide to keep the code as dumb as possible, so as to reach a wider user base.

The other thing is the reach of the script to newbies without a formal Software Engg background: Scripts are easier to hack for newbies.

Those two were the good reasons I saw to explain the phenomenon.

Make no mistake, the guys maintaining these projects are pretty good at software development, so it is not incompetence.

Sometimes they have spare cash too.

Now the question: What other sensible reasons can you think of?

EDIT: I personally feel that it's not about OOP alone, as pointed out by others, good code structure is not dependent on OOP/Procedural style. I've seen and coded a few functions-based PHP projects myself.

The thing that bothers me most is that the folder/filesystem layout is good, the file/folder naming is great, documentation is plenty, standards are followed, but, when you open the file to read the code, there's a hundred if-then-else conditions, version-checking, odd use of output buffering here and there, cookie manipulation code, some constants, includes, and no clear structure in many files.

At least I seem to be lost every time I try reading the code. But if I read code from Java or C# code bases, or even some other sidelined PHP apps - there is proper separation of code inside functions, templating is used for display and so on. Looks organised. Looks easily understandable.

Backward compatibility could be the issue for maintainers, but they would be open to making the next version in a more structured way. But that too does not happen!

Obviously, I'm missing something because those maintainers always work hard, after all.

Provider compatibility is an issue in many areas when building applications with PHP, it's not the reason why OOP is not used in certain projects.

Several Object Oriented Programming characteristics like interfaces, the public/private/protected keywords and more can be only found in PHP 5. Some applications still support PHP 4, mainly for the reason that there are still providers out there who won't upgrade (out of the justified fear that their clients' PHP 4 apps will crash by the dozen). Therefore, there is still a lot of "primitive" PHP 4 OOP code around. But there is no living PHP version that does not support at least basic OOP.

include and require are used to import code snippets into the current script. You will find them in object oriented applications as well.

There are several software products that make almost no use of OOP at all, and that's fine as long as the overall code quality is in order. While it is regarded by many (myself included) as a important method to write better, more reusable software, OOP is no requirement to write good software.

i see 3 main reasons:

compatibility: PHP did not include OOP from start on. to be down-compatible with older PHP environments and to reach a wider audience, you're keeping the status quo.
effort-switch: switching/refactoring a codebase fron non-OOP to OOP is a lot(!!) of work, transformation script in my view aren't a solution, because they tend to generate code for machines and not for humans. this is OK from runtime aspect but horrible for maintenance.
team-culture: i talked to some PHP developers, some just don't want to make the switch, because they say everything is good and working...

One of the biggest barriers to going all OOP with PHP is that everything has to be reloaded, initialized and executed on every page hit. If you designed a PHP system that was truly object oriented, across the board, performance would probably be abysmal. There would just be a lot of files and objects to load and configure to get things going. Everything has to be loaded and ready to go within a second (ideally much less). Compare that to say a Java based system where it doesn't really matter if it takes 10 minutes to get the system started. Once it's started, everything is loaded and ready to go.

WordPress is probably a good example of how slow things can get when creating a modular system with lots of files. Much less a modular OOP system. Load testing a straight WordPress install will get you about 10-15 pages/sec with a simple "Hello World" page. Compare that to being able to get well over a hundred pages/sec with a straight "Hello World" php script. You can work around these issues with caching, which WordPress, Symfony and other systems do.

Unless you use an MVC framework with PHP, Such object oriented approach (like ASP .NET has) would take too much time of yours. Actually you will need to design your own framework first.

I cannot say using a true object oriented approach in php is not possible. You can take objects whereever you want and serialize to strore them in session etc...

When it comes to MVC frameworks in PHP, you can see a true object oriented approach.

Check here for Zend Framework example

Zend Framework is not the only one.

But the words "object oriented" are new for PHP. Only PHP5 is considered as having true OOP. So you have to wait 1-2 years more for having good scripts with true object oriented approach.