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.