Mam w planach przygotowanie klasy o dumnie brzmiącej nazwie 'Core_Config', której będę używał do przechowywania konfiguracji systemowych jak i niesystemowych.

Klasa ma dostarczać następujących możliwości:

dostęp do konfigów w każdym miejscu aplikacji, moge to rozwiązać na 2 sposoby, albo singleton, albo 'registry' które delikatnie mowiąc 'podpatrzyłem' (ctrl+c) z zenda:

[PHP] pobierz, plaintext 
<?php
// registry
Carpo::registry('Config')->someParam;
// lub singleton
Core_Config::GetInstance()->someParam;
?>
[PHP] pobierz, plaintext 

nie zdecydowałem się jeszcze której z metod będe się trzymał, singleton jednak w tym momencie wydaje sie być rozsądniejszy.

Chciałbym w tak inteligentny sposob przygotować klase, aby moc dodawać do niej nowe 'rodzaje' przechowywania danych. Na starcie mam dwa - ini oraz mysql. Nie chciałbym tego jednak wpakować w jedną klasę. Chciałbym rodzielić to i w razie potrzeby mieć łatwo dopisać kolejne rodzaje, np pliki.txt, xml itp. Napewno tez w jakiś sposób musiałbym zawładnąć nadpisywaniem czy tam 'priorytetem' parametrów w momencie kiedy parametry w ini i mysql mają takie same nazwy.

Myslałem o zastosowaniu wzorca Factory:

[PHP] pobierz, plaintext 
<?php
ConfigFactory::build('ini','mysql');
?>
[PHP] pobierz, plaintext 

Tylko pytanie, jak przyjaźnie oddzielić kod odpowiedzialny za zarządzanie konfigami (W przypadku ini chodzi o zwykłe wczytanie danych z pliku, natomiast w momencie mysql'a chciałbym miec tez możliwość dodania metody setParam($name, $value);

myslalem o zastosowaniu klas abstrakcyjnych (Core_Config_Ini, Core_Config_Mysql, Core_Config_Xml), ale niestety nie napiszę

[PHP] pobierz, plaintext 
<?php
class Core_Config extends Core_Config_Ini, Core_Config_Mysql ...{}
?>
[PHP] pobierz, plaintext 

z wiadomych przyczyn.

Cod do singletona albo rejestru, możesz trzymać w obu, to przecież żadne problem - referencja.

Co do różnych zródeł:

[PHP] pobierz, plaintext 
<?php
interface ConfigSource {
public function getData();
}
 
class IniConfigSource implements ConfigSource {
   protected $aData = array();
   public function __construct( $sFile ) {
	  $this->aData = parse_ini_file( $sFile );
   }
   public function getData() {
	  return $this->aData;
   }
}
 
class CoreConfig {
   public function addSource( ConfigSource $ConfigSource ) {
	  $aData = $ConfigSource->getData(); // pobierasz dane, i dodajesz do globbalnych
   }
}
 
$CoreConfig = new CoreConfig();
$CoreConfig->addSource( new IniConfigSource( './plik.ini' ) );
$CoreConfig->addSource( new MySQLConfigSource( $ObiektDb ) );
$CoreConfig->addSource( new PHPArrayConfigFile( 'podJakaZmienna', 'plik.php' ) );
?>
[PHP] pobierz, plaintext 

Tyle.

jedno ale...

w jaki sposob MySQLConfigSource ma udostepnic metode setParam() w w CoreConfig?

Zamiast implementation powinno być oczywiście implements. Kolega hwao nieumyślnie się walnął w przykładzie .

___
Juz go poprawilem:)
AP

Tak nie możesz robić...

Możesz przerobić interfejs i dodac

[PHP] pobierz, plaintext 
<?php
interface ConfigSource {
   public function getData();
   public function set( $k, $v );
}
$Config = new MySQLConfigSource( $ObiektDb );
$Config->set( 'a', 'Test1' );
$Config->set( 'b', 'Test2' );
$Config->set( 'c', 'Test3' );
$Config->set( 'd', 'Test4' );
// W tej metodzie nastepuję albo buffering, albo od razu zapis
 
 
// dodanie danych do CoreConfig
$CoreConfig->addSource( $Config );
?>
[PHP] pobierz, plaintext 

ConfigCore pobiera wszystkie dane, tworzy wspólna tablice, i udostępnia je jakimś algorytmem.

@Denver wszystko z głowy na szybko pisze, a dopiero wstałem ;-)