(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

User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

(PHP5) How do you store and include your Interfaces

Post 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 8O
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Re: (PHP5) How do you store and include your Interfaces

Post 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.
Gambler
Forum Contributor
Posts: 246
Joined: Thu Dec 08, 2005 7:10 pm

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

Post 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 :)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

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

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

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

Post 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.
(#10850)
ShaneH
Forum Newbie
Posts: 1
Joined: Wed Jun 14, 2006 7:49 am

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

Post 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 :)
bg
Forum Contributor
Posts: 157
Joined: Fri Sep 12, 2003 11:01 am

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

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

Post 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.
Gambler
Forum Contributor
Posts: 246
Joined: Thu Dec 08, 2005 7:10 pm

Post 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.
Last edited by Gambler on Wed Jun 14, 2006 1:24 pm, edited 1 time in total.
Post Reply