(PHP5) How do you store and include your Interfaces

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

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!
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Roja 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!
They are cool indeed :) Not 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.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

d11wtq wrote: They are cool indeed :) Not 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.
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..
bg
Forum Contributor
Posts: 157
Joined: Fri Sep 12, 2003 11:01 am

Post by bg »

Gambler wrote:
A seperate file for each function?
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?

Edit: Damn, I should learn to type faster.
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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

bgzee wrote:Additionally, you will reduce overhead with less includes.
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.

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.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

bgzee wrote:Additionally, you will reduce overhead with less includes.
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.

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. :)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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.
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: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.
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:It's just a nother file to need to include every time the class is used
Just one more... It'll break your application and cripple your server! :)

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...:).
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.
Roja took you down, tied you up, then slapped you silly...;). A lot of folk still work on legacy code - and some of it is even spanking new sparkly code that's not all that bad. Procedural code still has a place in development.
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..
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.
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.
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.
bg
Forum Contributor
Posts: 157
Joined: Fri Sep 12, 2003 11:01 am

Post by bg »

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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

bgzee wrote:I can see the argument both ways, I guess in the end it comes down to personal preference.
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.
(#10850)
bg
Forum Contributor
Posts: 157
Joined: Fri Sep 12, 2003 11:01 am

Post by bg »

arborint wrote:
bgzee wrote:I can see the argument both ways, I guess in the end it comes down to personal preference.
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.
You took my quote out of context buddy. Interfaces really had nothing to do with that statement.
bg
Forum Contributor
Posts: 157
Joined: Fri Sep 12, 2003 11:01 am

Post by bg »

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.
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.

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
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I don't see this sort of file splitting beneficial when debugging... I never really thought it was too hard to find
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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

It's fudamental really. Nothing to do with premature optimization. Start as you mean to go on. If your app just continues to grow and grow in size you'll need something highly organised so why not just do it from the outset?
Post Reply