(PHP5) How do you store and include your Interfaces
Moderator: General Moderators
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
They are cool indeedRoja wrote:I gotta mention this.. despite working on the php.net website, despite years working on php, I had never seen interfaces in PHP before. Granted, I only work on OOP at work, where its mostly maintenance, but..
Very cool to learn something new!
Seeing as how I've been working through a plugin system, thats incredibly sexy. Oh how I look forward to php5+ being the majority install one day so I can use the OOP features..d11wtq wrote: They are cool indeedNot all that useful 90% of the time though. Useful in the scenario that you've wirtten a plugin system. A developer decides to write plugin. It doesn't work that great, not sure why. Now do the same thing again but using the interface. Errors - fatal ones. Oh, I've forgotten to implement <insert name here> method! The code just physically won't run without that strict enforcement.
First, if you have 100 php files, you need to consolidate. Grouping functions by category is a good way of knowing which file a function may reside. Instead of having, login.f.php, logout.f.php, update_profile.f.php, you could group all these into one file, for example user.lib.php, since they are all user functions. Then, if at some point you choose to switch to OOP, you will essentially have all member functions written and in one file, and included where necessary within your code. Additionally, you will reduce overhead with less includes.Gambler wrote:I have function doThisStuff() and I have one hundred PHP files. How do I find which one contains code of this function? How do I decide which file is worthy of containing my new functions? How can I be sure that some optional include won't result in fatal error bacause of naming collision?A seperate file for each function?
Edit: Damn, I should learn to type faster.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
I disagree. The overhead is minimal, the organization is better (ever looked through phpBB code?) and the overhead may even be less since you'll not be including junk (other functions) that you're not going to use.bgzee wrote:Additionally, you will reduce overhead with less includes.
I sometimes create a "core_components.php" file which includes files from various places but generally my app layout is such that I don't need to do this sort of thing (front controller, lazy loading, page controllers on each section).
EDIT | haha Roja's comment back's up my point exactly
Last edited by Chris Corbyn on Wed Jun 14, 2006 2:56 pm, edited 1 time in total.
I experienced just the opposite. BNT had a (ridiculous) monolithic "function library" file, with many functions that weren't needed. While it reduced the number of includes needed, it also increased the number of functions included that weren't needed.bgzee wrote:Additionally, you will reduce overhead with less includes.
By breaking the function libraries into seperate files, we reduced the per-page processing time - despite having more (count) total files to include. More smaller > less bigger. Seems counter intuitive, but thats the experience I had.
Now, I do agree that we could combine a number of function files together, but I'm still working through spaghetti code to get each function to be a true function. (I can't count the number of functions we have that have no defined return, that spew hard-coded html output, and don't handle errors - at all).
One step at a time for me.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
I always put them in separate files, and since Interfaces are not loaded autmatically class I use a require_once() statement to include them. The issue here is that Interfaces while good documentation, document the API outline only. They have limited documentation utility, and their value is enforcing an interface across multiple classes. Leaving it with one class defeats the purpose of an interface IMO.d11wtq wrote:Interfaces provide a sort of documentation. If your class is say, 3000 lines long and a developer opens it up, the interface they find at the top of the file gives a very brief summary of it's functionality.
It's limiting re-use on a level. What if you need the interface outside the Library class? Your approach is still valid (and kudos) - it's just not a cure all. I'd just replace the interface definition with a require_once call...d11wtq wrote:One thing I was thinking of was classes that support plugins. If you have a class for public download and plugins adhere to an interface you don't really want to have to instruct the user of your class to manually include the interface, so you could just hard-code it into the main class file where the plugins get loaded in.
Just one more... It'll break your application and cripple your server!d11wtq wrote:It's just a nother file to need to include every time the class is used
To be honest I have found few places to use an interface proper. The apps I work on are not large scale, and usually an Abstract Class does the trick quite neatly. Plus an Abstract has the same effect as an interface - it will enforce a specific API on all sub classes. If an abstract works, an interface is unnecessary. If the abstract's common functionality is expected to start differing across units, then an interface comes into play for all abstracts/classes to implement. Small plugins (due to size) are the other interface use where no common code is shared...as you probably knew already...
Roja took you down, tied you up, then slapped you silly...bgzee wrote:A seperate file for each function? That sounds like complete insanity and a huge mess of includes. I could understand function libraries, but even those are like, so 2002.
I'm one of those people who have taken to coding in PHP5, and then downgrading it to PHP4 as an alternative. It's annoying, but at least the code is forced up a few notches. The extra effort is a bit irritating, but my projects aren't so big it's impossible to do it effectively.Roja wrote:Seeing as how I've been working through a plugin system, thats incredibly sexy. Oh how I look forward to php5+ being the majority install one day so I can use the OOP features..
Counting includes is premature optimisation IMHO. Includes are fast - I have a small app doing upwards of 40 and it's not registering on any XDebug profiles. It's just not worth optimisation at that level unless you've exhausted all other avenues, and you desperately need those extra microseconds. Splitting functions out is a logical route - it's well organised, easy to navigate, and narrows down debugging. Consolidation does not lead to OOP easily - there's all those finnicky OOP ideals to consider.bgzee wrote:First, if you have 100 php files, you need to consolidate. Grouping functions by category is a good way of knowing which file a function may reside. Instead of having, login.f.php, logout.f.php, update_profile.f.php, you could group all these into one file, for example user.lib.php, since they are all user functions. Then, if at some point you choose to switch to OOP, you will essentially have all member functions written and in one file, and included where necessary within your code. Additionally, you will reduce overhead with less includes.
I can see the argument both ways, I guess in the end it comes down to personal preference. However, in moving your code to OOP, eventually you will have classes with member functions that were once included in seperate files, so there will be unused functions included in your script. The question is whether or not its worth it to be that anal about unexecuted code. My theory is that if code is separated properly by functionality, whether oop or procedural, it won't be too big a problem.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
You took my quote out of context buddy. Interfaces really had nothing to do with that statement.arborint wrote:It's not really about personal preference ... interfaces exist to do a specific thing. If you need to do that thing you use them. If your don't need to do that thing you don't.bgzee wrote:I can see the argument both ways, I guess in the end it comes down to personal preference.
Being too picky about unexecuted code is also a premature optimization, with little effect on actual performance. I'd be willing to bet includes are more expensive, in terms of performance, than having a reasonable number of functions that may not be used included in a script. Either way I think it can be agreed that the difference is neglegable. My point is however, that in the transition to OOP multiple functions will at some point need to be placed, based on responsibility, within a class definition. And ultimatly, some of these functions will never be executed in certain situations.Maugrim_The_Reaper wrote:
Counting includes is premature optimisation IMHO. Includes are fast - I have a small app doing upwards of 40 and it's not registering on any XDebug profiles. It's just not worth optimisation at that level unless you've exhausted all other avenues, and you desperately need those extra microseconds. Splitting functions out is a logical route - it's well organised, easy to navigate, and narrows down debugging. Consolidation does not lead to OOP easily - there's all those finnicky OOP ideals to consider.
I don't see this sort of file splitting beneficial when debugging... I never really thought it was too hard to find
Code: Select all
/usr/home/bgzee/www/some_functions.php on line 4- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
It provides the function name in addition to a line num. Small difference I know but it can ease the process when the alternative is a function file running to several or more pages. It's a useability preference in terms of debugging - I shouldn't have mentioned it.I don't see this sort of file splitting beneficial when debugging... I never really thought it was too hard to find
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia