Require once is part of your documenation points out an interesting case.
Consider that you have two programs, A and B. A and B share some duplicated code. Since duplicate code is bad, we factor out the duplicate code into file C (for common). Both A and B include C. All is well. The code is obvious.
However, there is still one last code duplication between A and B. That is the include statement itself. So instead, we wave our magic patterns wand, utter some mystical phrases (”dependency inversion!”) and introduce a front controller. Now, the common code that was in file C is included by the front controller even before A or B is called.
A and B are even simpler because they don’t need the include statement. Depending on the code, they may also no longer have any explicit dependency at all on the common code. C is a little more complex because it has to dispatch to A and B, but when A and B are really A-Z, the dispatch price fades away.
The cost? The application has a bigger learning curve for those unfamiliar with it.
The benefit? The developers familiar with the application have better productivity.
could php’s session_start() function be so simple without the bazillion session.x ini file settings that were established before your program even ran? PHP provides an environment in which your application can be simpler. Large productive projects also do this at the application level.
Its my opinion that any web application of sufficient size can’t help but sprout a front controller at some point.
Should you put a require_once at the top of every file for each dependency it contains? I think the state of the art is going in a different direction, towards containers, front controllers, and dependency injection.
Feed
Subscribe to this blog…
Are you familiar with Ruby on Rails? http://rubyonrails.org/
It uses dependency injection and front controllers very nicely.
Wether you are doing includes, auto_prepend, explicit Frontcontroller by rewriting every request to a single script – I see it all only as a matter of syntax. There is no inherent superiority with either appraoch. Depending on how all the other code looks, some people may be more comfortable with one over the other, but that boils down to a matter of personal preference. IMHO.
>C is a little more complex because it has to dispatch to A and
>B, but when A and B are really A-Z, the dispatch price fades
>away.
I am not sure I understand what you are saying here. Is it easier to add lines to the frontcontroller than to the file that would otherwise have an include-statement?
>Should you put a require_once at the top of every file for >each dependency it contains?
No, I think most people would just require one file that takes care of including all the other necesary ones.
>I think the state of the art is going in a different >direction, towards containers, front controllers, and >dependency injection.
I agree, but I think it’s because it fits better with the (meta-)language that most people speak, it’s neither new nor different from what people were doing before the knew the words or concepts of container, front controller and dependency injection.
The article acheived it’s aim, in that it encourages coders to think carefully about when and where to put your require_once’s. In a totally OO patterned framework, you probably have a base action class, for a particular module or site, which can load up common libraries that are required. So it is likely you end up with a single require_once on the action page, the inclusion of the base class. Which in turn pulls in some of the more critical libraries (Database tools / Template Tools etc.). Other components (like task specific libraries) are often best moved right next to the location they are used.. the line before the class is first instantated..
As my own mini-framework has evolved, the amount of libraries autoloaded at the start has been reducing, rather than increasing, moving alot of the responsibilities to the page action base classes, or directly into the code flow..
I would suggest this comes down to personal preference, I myself define most of the require_once’s in a single file and then pull this into my MVC’s entry point, this way all classes are instantly available without the worry of maintaining dependancies.
Depending on the project this could be anything from 10 to 100+ includes, and before any of the hardcore-speed-freaks scream how wasteful this is, the overhead of pulling in so many classes can be drastically reduced by using a Cache system such and EAccelerator or Zend Accelerator.