Service design pattern / chargement dynamique de services d'interfaces

Description

L'interface en programmation objet en plus de définir une structure de classe peut également être considérée comme un contrat. C'est un peu la différence entre une interface et une classe abstraite qui elle aussi peut définir une structure de classe à implémenter.

Je reviens pas sur les concepts de POO, si vous souhaitez utiliser ce bout de code je présume de toute façon que vous les maîtrisez.

Ce petit bout de code vous permet de développer votre code en l'orientant en services qui exposent des implémentations.

L'avantage d'une telle programmation est que :

1. vous pouvez faire un système modulaire facilement modifiable.
2. l'utilisateur du service n'a pas à se soucier de la classe à instancier

Voir le code d'utilisation ci-dessous :

Source / Exemple :


<?php
	
	// INIT SERVICE FACTORY
	require_once('service.class.php');
	
	// INIT SERVICE DEFINITION
	require_once('services/driver.interface.php');
	
	// INIT BASE CLASS
	require_once('implementation/driver.base.php');
	
	// INIT CONCRETE SERVICE CLASS
	if (!isset($_GET['test'])) $_GET['test'] = 'ouioui';
	require_once('implementation/'.$_GET['test'].'.class.php');

	// TEST SERVICE
	service::get('IDriver')->start();
	service::get('IDriver')->speedUp();
	...

Conclusion :


Le chargement modulaire n'est pas traité à ce niveau, à vous de savoir comment charger les bonnes classes dans le système car si deux classes implémentent la même interface vous aurez une exception de type duplicate service...

En php 5.3 j'aurais pû écrire dirrectement ceci :

service::IDriver()->start();
service::IDriver()->speedUp() ...

Codes Sources

A voir également

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.