Design Patterns

[borobudur]

I was asking myself how much sense it does to use design patterns with php5.

 

For example if I'm designing a component with a interface, it's implementation (which should be hidden, package private exists?) and a factory (which handles it's references).

 

What's your opinion about that?

[Buyocat]

Patterns have nothing to do with the language you program in; you should apply a pattern when it would improve the quality of your application or help you solve a common problem.  So if you want to decouple the creation of objects and their access then use a factory pattern.  Designing to an interface isn't using any pattern per se, but it is a good decision because it means that you can switch implementations in the future, so your code is more extensible (this assumes a good interface).  There is no notion of a package or private packages in PHP, so you won't need to build a factory for that reason, but implementing a factory would keep in line with the goals of the interface.

 

Suppose interface Foo was defined.  A Foo factory would allow you to swap the implementation of Foo by changing a single line of code no matter how many classes referenced Foo's implementation.  This sort of flexibility makes your code easier to maintain, and more consumable by third parties.

 

If you have any other patterns you'd like to discuss, or questions, feel free to ask.

[borobudur]

Thanks for your professional explaining.

 

I'm aware of the advantage of design patterns, I'm just a bit confused what it means for PHP as a script language and people saying that PHP is not really OO.

 

Hear is what I'd like to do:

- I was thinking to use the MVC pattern as the main 'code organizing' part.

- Util packages with interfaces, factories and its implementation.

- the composit pattern to build some view components

 

Thanks for your replay

borobudur

[Buyocat]

You're plans sound good to me, and if you want to discuss more specific implementation details let's start a new thread.

 

PHP used to have bad OO support (even 4 was pretty bad) so I guess it's still got that stigma attached to it.  That said PHP 5 will let you do just about everything you're used to doing in most modern languages.  Patterns specifically don't require OO, though they're often spoken of in the context of OO.  Either way, since you can program in OO fashion you can apply the patterns you read about directly.

 

As a shameless plug, if you're interested I have some utilities written for PHP 5 that you could add to your own utils.  They do various things, and are meant to be standalone items.  If you're interested just follow my signature.

[bmario]

hello

 

at first sorry for putting this thread up and for my english (at least my german isn't even better i think )

 

but i searching for a long time such a thread. becuase i'm unsure about what interface can do for me.

 

now im writing on a cms that would be all in oop and php5

so i want to use as much as i can of the oop ideas.

 

so i found that interfaces to make my classes (until now for mysqli) changeable.

so in case of changing from one to another class implementation (perhaps sqlite or something) i don't want to change my entire source

so i would prefer the way interface (if i unterstand right)...

hope you understand me  ???

 

at least here my pseudocode...

 

interface DataStorage
{
  //some functions, doesn't matter
  public function query();
}

class MysqlDataStorage implements DataStorage
{
  //implementation with mysql
  public function query()
  {
    //some code for query a mysql server...
  }
}

//$ds should be a child of MyqslDataStorage, but with creating from the interface, is that possible? if yes, what happens if two classes implements the interface (is that possible, i think so..)?
$ds = new DataStorage();

[aschk]

You can't instantiate an interface

$ds = new DataStorage();

 

I think what you meant was

$ds = new MysqlDataStorage();

[Daniel0]

what happens if two classes implements the interface (is that possible, i think so..)?

Then they'll implement the same functionality. You can implement multiple interfaces as well if you wish.

[bmario]

$ds = new DataStorage();

 

uhm.. the point is, i want a system that don't cares about the specific class, that implements DataStorage, only gives my an instance of that class.

 

i just want to call something like "$ds = new anyDataStorage();" so i just know, there is a way, so it gets saved to something even the devel himself put it in his mind, at this situation i dont wont to care about it.

 

i just wont ANY implementation of datastorage what is definded.

 

hope you can understand my idea...

 

[Daniel0]

Well, DataStorage is not a class, it's an interface. By implementing an interface in a class you'll make sure that the class has the methods required by the interface. On run time you can check it using the instanceof operator.

[448191]

$ds = new DataStorage();

 

uhm.. the point is, i want a system that don't cares about the specific class, that implements DataStorage, only gives my an instance of that class.

 

i just want to call something like "$ds = new anyDataStorage();" so i just know, there is a way, so it gets saved to something even the devel himself put it in his mind, at this situation i dont wont to care about it.

 

i just wont ANY implementation of datastorage what is definded.

 

hope you can understand my idea...

 

 

And how is your client code supposed to know what DataStorage class to instantiate?

 

What you COULD do is using __autoload and a factory method in an abstract supertype. This system would be dependent on the absence of other implementations of DataStorage: when installing, you only place the file with the DataStorage implementation you want your code to use. In the long run, you're probably better off using a configuration file, but I'll provide you with an example anyway.

 

Here's how that could work:

 

Define __autoload():

 

<?php
function __autoload($classname){
include str_replace('_', DIRECTORY_SEPARATOR).'.php';
}
?>

 

Define your abstract supertype with Factory Method:

<?php
abstract class Data_Storage {

/**
 * Known implementations of DataStorage
 *
 * @var array
 * @static 
 */
static $implementations = array(
	'Data_Storage_Implementation1',
	'Data_Storage_Implementation2',
	'Data_Storage_Implementation3'
);

public static function factory(Array $arguments){
	foreach(self::$implementations as $classname){
		if(class_exists($classname, true)){
			break;
		}
	}
	$reflection = new ReflectionClass($classname);
	return $reflection->newInstanceArgs($arguments);
}
}
?>

 

Now you can do this:

<?php
$dataStorageImpl = Data_Storage::factory(array('value', 'value'));
?>

 

And you will get an instance of the first class in the $implementations array that is found by __autoload()

 

Note that you create a direct dependency between the supertype and it's implementation this way (the supertype needs to know who is inheriting from it).

 

Alternatively, you can scan a directory for the presence of an implementation file. This removes the Factory's dependency on the supertype's $implementations array, but will also destroy performance.