Page 1 of 2
(PHP5) How do you store and include your Interfaces
Posted: Fri May 19, 2006 9:15 am
by Chris Corbyn
Do you put your interfaces in a separate file to the class they should enforced upon or do you just stick the code straight at the top of the class file above the class declaration?
I've always kept them separate but it's just dawned on my that it's probably not a great idea because:
a) It's just a nother file to need to include every time the class is used
b) If you're using it as a form of mini-documentation it's less obvious where to find it
c) See comment below about objects loaded via methods*
* Also if a class has methods which load in object adhering to a certain interface you probably want those interfaces to be available to the class all the time.
This is a pretty pointless question really come to think of it

Re: (PHP5) How do you store and include your Interfaces
Posted: Fri May 19, 2006 9:41 am
by santosj
Indeed.
I would separate them in case you have two or more classes in separate files that need access to the interface and don't want to include the own file introducing fluff.
Posted: Fri May 19, 2006 2:45 pm
by Gambler
I even store _functions_ in separate files (like getUser.f.inc). Much easier to work that way.
If you implement interface in one class only, why do you use interface at all?
Posted: Fri May 19, 2006 3:10 pm
by Chris Corbyn
Gambler wrote:I even store _functions_ in separate files (like getUser.f.inc). Much easier to work that way.
If you implement interface in one class only, why do you use interface at all?
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.
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.
Like:
Code: Select all
<?php
interface IPlugin
{
public function connect($server);
public function disconnect();
public function command($string);
}
class someLibrary
{
private $plugin;
private $server;
public function __construct($server)
{
$this->server = $server;
}
public function loadPlugin(IPlugin &$pluginObject)
{
$this->plugin = $pluginObject;
$this->plugin->connect();
}
/* blah blah */
}
?>
And the plugin:
Code: Select all
<?php
class somePlugin implements IPlugin
{
public function connect($server)
{
//
}
public function disconnect()
{
//
}
public function command($command)
{
//
}
}
?>
So now all you do from a developer *using* the code is:
Code: Select all
$object = new someLibrary('localhost');
$object->loadPlugin( new somePlugin );
If you had the interface in it;s own file the user would have to include it themselves... and if you had support for multiple plugins they'd need to make sure it was included only once. It just seems like an unneccesary hassle to the end-user.
I've sort of stuck them at the top of my main class in my latest venture although it doesn't look overly conventional. The interfaces are provided in separate files for the developers too.
I agree the separating things makes them more re-usable though

Posted: Fri May 19, 2006 3:58 pm
by Ambush Commander
Makes sense, but personally, as long as you name your files in a sane manner, it should be trivial to open up the file that contains the interface for further inspection.
Posted: Fri May 19, 2006 4:18 pm
by feyd
Normally when I write an interface it will, for the most part, be implemented by a certain class so I keep them in the same file. Only when I write a highly pluggable system do I separate them to ease up on parsing a bit (overall.)
Posted: Fri May 19, 2006 4:27 pm
by Christopher
I keep abstract classes in separate files, but honestly I still haven't found a reason to use interfaces. I have seen no need to communicate what they communicate -- to myself. I have used them for reflection a little, but that has been broken ... although it seems to be improving with each release.
Posted: Fri May 19, 2006 4:31 pm
by Chris Corbyn
arborint wrote:I keep abstract classes in separate files, but honestly I still haven't found a reason to use interfaces. I have seen no need to communicate what they communicate -- to myself. I have used them for reflection a little, but that has been broken ... although it seems to be improving with each release.
Do you now find them useful when you've written something that you expect developers to write code for? I'm aware that because they don't affect functionality they are completely down to personal preference however

Posted: Fri May 19, 2006 4:40 pm
by Christopher
d11wtq wrote:Do you now find them useful when you've written something that you expect developers to write code for?
They enforce methods and parameters -- and that was not a problem I have really ever needed to be solved in PHP. I can see how a compiiler might want that kind of information.
As I said, the only real use I have found is for reflection for DI -- but that is really just sort of a miserable, stop-gap method until some better support comes along.
Posted: Wed Jun 14, 2006 8:18 am
by ShaneH
Interfaces are invaluable when you're writing code that's meant to be extended/overloaded by another developer. I sell my product with a set of DB classes for common databases. If a developer needs to support a new DB, all he needs to do is create a DB class, and put it in a directory that include() checks before it checks my built-in \lib\ directory. By providing an interface for the developer to implement, it makes his life easier and it means that the rest of the system can count on a uniform DB experience, no matter who created the class.
If you're working on your own, these advantages are still there, but it's not nearly as big of deal.
Posted: Wed Jun 14, 2006 8:49 am
by Chris Corbyn
ShaneH wrote:Interfaces are invaluable when you're writing code that's meant to be extended/overloaded by another developer. I sell my product with a set of DB classes for common databases. If a developer needs to support a new DB, all he needs to do is create a DB class, and put it in a directory that include() checks before it checks my built-in \lib\ directory. By providing an interface for the developer to implement, it makes his life easier and it means that the rest of the system can count on a uniform DB experience, no matter who created the class.
If you're working on your own, these advantages are still there, but it's not nearly as big of deal.
Yeah, I'd only bother with interfaces where I expect other people to want to hack away at my code and write their own components

Posted: Wed Jun 14, 2006 1:05 pm
by bg
Gambler wrote:I even store _functions_ in separate files (like getUser.f.inc). Much easier to work that way.
If you implement interface in one class only, why do you use interface at all?
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.
Generally, any object that implements an interface is going to be held by a governing object. For example,
Code: Select all
class app{
private $plugins = array();
public function load_plugin($plugin_name){
$plugins[$plugin_name]->load();
}
}
interface plugin{
public function load();
}
As you see, the app object isnt functional without the interface, because unless a plugin implements the plugin interface, it won't function as expected. So, there is no reason not to include it in the app class file.
Posted: Wed Jun 14, 2006 1:15 pm
by Roja
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 disagree, but let me explain my reasoning.
I'm working on a huge chunk of ~2000 era code, filled with procedural nightmares that would make OOP purists run away in horror.
As I refactor the code, where possible, I'm moving *true functions* into seperate files. I'm selectively defining true functions as a function with a clear and defined input, process, and output, in under 200 lines of code.
By doing so, I'm able to compartmentalize the code, which (much further down the road) can lead to them becoming testable classes, and (oh holy day) actual solid OOP objects and methods.
The path from spaghetti to purity does have some nasty bumps along the way, and having standalone functions in seperate files isn't a net bad thing. I consider it a distinct improvement over raw mixed procedural code by a long shot. (At least with a defined input/process/output, I can hack up tests for that function, and later replace it with a full test-driven designed OOP member).
Not to mention, I've heard comments in multiple areas (notably including PanamaJack) that classes can add substantial overhead compared to raw includes and function calls. He has accomplished substantial gains in his "lite" implementations of adodb and Smarty, so he'd be a good one to ask if he finds that to be the case.
Regardless, as an interim step towards OOP, I don't find standalone function files to be a step back, or a bad thing.
Posted: Wed Jun 14, 2006 1:19 pm
by Chris Corbyn
Yes, functions should indeed be in seperate files. They are much easier to find if you have a functions dir and you name the files according to the content.
I do agree with keeping interfaces with the class if they are only used by that class though. If they get used in several places however common sense seems to suggest they should be in their own files.
FYI: No errors would be thrown in your code if you didn't implement the interface... place the interface name infront of the method parameter which loads the object.
Posted: Wed Jun 14, 2006 1:23 pm
by Gambler
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.