Skoro po kilku konsultacjach doszedłem do wniosku, że jednak nie warto stosować tablicy $GLOBALS do przechowywania ustawień witryny zaczałem pisać klasę settings Wygląda ona mniej więcej tak:

[PHP] pobierz, plaintext 
<?php
class settings  //ta klasa wchodzi w skłąd klasy głównej jako singleton
	{
		private static $instance = null;
		private $tablica=array( "db_name"=>"test" ); //tablica przechowywująca zmienne 
 
		public function get_instance() //funkcja do przekazania instancji - singleton
		{
			$class = __CLASS__;
			return self::$instance == null ? self::$instance = new $class : self::$instance;
		}
 
		function __get( $name ) //magiczna metoda do pobierania zmiennych
		{ 
			return strtolower( $this->tablica[$name] );
		}
	}
?>
[PHP] pobierz, plaintext 

Chciałbym teraz wczytać do tablicy '$tablica' zmienne z pliku 'settings.ini' który wyglądał będzie tak:

Pierwsze pytanie:
-- Czy istnieje jakaś fajna funkcja która wczyta za mnie zmienne z pliku .ini? Może ktoś ma i mógłby mi wkleić? (znalazłem już dlatego pytanie jest nieważne - funkcja $ini = parse_ini_file('file.ini'); )
-- Chciałbym jednak zapytać czy uważacie że to dobry (albo zły) sposób na napisanie takiej klasy. Pytam bo nie chce juz tego poprawiać więcej

Drugie pytanie dotyczy posta którego nie mogę teraz odnaleźć ale pisało w nim, że:

-- Czy powinienem unikać metody magicznej? Muszę przyznać, że w tym wypadku znacznie poprawiłaby ona czytelność kodu.

Masz bana na manuala...?
parse_ini_file" title="Zobacz w manualu PHP" target="_manual

Sory pospieszyłem się z tym pytaniem ale chodzi mi teraz o bardziej ogólne pytanie o opinię na temat tego sposobu.

Lepiej zrobisz jak odziedziczysz po ArrayObject. Dostaniesz gratis funkcję ArrayObject::offsetGet(), dzięki której wszystko zrobisz bardziej elastycznie i bardziej elegancko.

Co to jest klasa main_object i dlaczego po niej dziedziczą wszystkie inne?

racja @mike. Klasa settings nie musi dziedziczyć po żadnej. (Mój bład) Klasa "settings" wchodzi w skłąd klasy "main_object" jako singleton. Po main_object dziedziczą wszystkie inne klasy dzięki temu mamy główny węzeł dla całego systemu.

Coooooo? Wyrzuć to do kosza. Natychmiast!
Splatch’s devblog :: Singleton
Antywzorzec projektowy

o matko znowu od nowa... a było juz tak pięknie

Noc chyba, że źle zrozumiałem.
Jeśli u Ciebie każda klasa (lub większość) jest singletonem to ja na zawał padnę

Na zawał to o mało ja nie padam teraz Bo co ja zrobię bez singletona.

Nie wszystkie. W zasadzie tylko kilka. Jest tak:

--main_object // klasa główna po której dziedziczą inne
---- db_driver() // singleton
---- settings() // to tez miałem nadzieję zrobić jako singleton
---- db_functions // konkretne zapytania do bazy opakowane w funkcje tez jako singleton

nowy obiekt tworzę tak:
class news extends main_object

Co ja zrobię bez singletona? globals zle, $GLOBALS też zle i teraz singleton też jest be. Proszę pomocy! Co ja mam zrobić?

1. Nie wpadać w panikę
2. Zainwestować w książkę
3. Ukorzyć się przed wielkim OOP ;p

dzieki za radę ale jakoś nie czuję się mądrzejszy po niej

No co? ;p Pierwsze 2 punkty są zupełnie na poważnie. W moim odczuciu wpadasz w panikę i miotasz się, bo chcesz wszystko od razu mieć naj. Tak się nie da, bo konsekwencje odczujesz dopiero, gdy zaczniesz tego używać. Pomyśl o tym jak o żywym organiźmie. Mózg sam nic nie robi, tylko wydaje polecenia za pośrednictwem połączeń nerwowych. Tak samo od nich odbiera sygnały. Każdy singleton to jak połączenie oddzielnym kanałem nerwowym, który omija wszystkie inne i cholera wie, jakie informacje tam idą.

Mi tylko chodzi o to żebym mógł w klasach stosować proste odwołanie do settings. Singleton dobrze sie do tego nadawał:

[PHP] pobierz, plaintext 
<?php
$this->settings()->db_host;
?>
[PHP] pobierz, plaintext 

a co do mojej potzreby "idealności" to naprawde zależy mi na ostatecznym rozwiązaniu. Już nie mam siły tego przepisywać co pół roku. Muszę jeszcze napisać newslettery, file_menagera, sondę i mase innych a nie mogę wyjść z jądra systemu.

Wiesz jaki kod piszemy jest zależne od tego co umiemy, jak ktoś się ciągle rozwija to będzie ciągle zmieniał to co kiedyś napisał.

Co do settings i singletona, to przecież i tak w konkretnym miejscu pobierasz te dane i tam też je możesz przekazać do innych obiektów które je potrzebują, że to są startowe informacje tylko raz musisz je przekazać, więc na prawdę używanie singletona jest w tym przypadku niepotrzebne.

Bo chyba masz w jednym miejscu wczytywanie konfiguracji? Bo jak będzie rozrzucona to będzie właśnie problem z tym "a gdzie to ja tego używam", dlatego singleton jest antywzorcem.

@Sedziwoj Trochę nie radzę sobie z tym zadaniem. Mógłbyś mi doradzić?

[PHP] pobierz, plaintext 
<?php
	abstract class main_object
	{
		/* settings getting instance */
		public function settings(){ 
			return edc_settings::get_instance(); 
		}
 
		/* db_driver getting instance */
		public function db_driver(){ 
			return mysql_db_driver::get_instance();
		}
	}
 
	class edc_settings
	{
		private static $instance = null;
		public $settings = array();
 
		public function __construct(){
			$this->settings=parse_ini_file('settings.ini');
		}
 
		public function get_instance(){
			$class = __CLASS__;
			return self::$instance == null ? self::$instance = new $class : self::$instance;
		}
 
		function __get( $name ){
			return strtolower( $this->settings[$name] );
		}
	}
?>
[PHP] pobierz, plaintext 

Tak więc mam główną klasę po której dziedziczą inne. Zawiera ona 2 odwołania do singletonów. Tworząc nową klasę np news dziedziczę po main

[PHP] pobierz, plaintext 
<?php
	class news extends main_object
	{
		public function drop_linik()
		{
			 // wewnątrz funkcji mogę korzystać z settingsów bez zmiennych $GLOBALS których pon
oć nie powinno sie używać.
			 print( $this->settings()->base_href . "podstrona" ); //pobieram z settingsów "base_href";
		}
	}
	$object_news = new news;
	$object_news->drop_link();
?>
[PHP] pobierz, plaintext 

Jak mam to robić inaczej ? Sugerujesz, że powinienem przekazywać obiekt $settings do konstruktora object_news ? To strasznie niewygodne.

Wygoda jest tu na drugim miejscu. Co ma klasa News wspólnego konfiguracją Twojego systemu? Nic, a przynajmniej bardzo niewiele.
Powinieneś przekazać jej tyle danych, ile jest jej potrzebne. Nawet przekazanie obiektu $settings jako parametr w konstruktorze jest kontrowersyjne, choć lepsze niż dziedziczenie po jakimś dziwnym obiekcie. W idealnym przypadku powinieneś posiadać dodatkową klasę NewsManager/NewsBase/NewsHelper/NewsVendor/CoTamChcesz, która się zajmie rozmową z resztą systemu. Możesz wykorzystać coć na podobieństwo wzorca Prototype/Fabryki obiektów.

[PHP] pobierz, plaintext 
<?php
class newsFactory
{
  static function createOne()
  {
	$obj=new News();
	$obj->setAdditionalConfig($settings);
	return $obj;
  }
}
 
$news=newsFactory::createOne();
?>
[PHP] pobierz, plaintext 

Omijasz w ten sposób te niedogodności.

Pozdrawiam.

Ja mam tylko taką uwagę:

Wiesz jaką funkcję (między innymi) pełnią wzorce projektowe? Wprowadzają ujednolicenie nomenklatury i standardy.
Jednym z największych plusów jest to, że jak mówię komuś innemu, nawet na końcu globu (nie kojarzyć z globals ) na przykład Intercepting Filter to on wie co ja mam na myśli.

A czemu to mówię? Bo Twoja klasa main_object to taki Context i tego raczej się trzymaj. Gdybyś nie podał ostatniego listingu to wiele osób nadal mogłoby nie wiedzieć czym u licha jest to Twoje main_object.
Już sama nazwa jest nie bardzo bo prędzej powinno być: main_class.

A teraz uwaga!
Polecam najlepsze książki do nauki wzorców dla PHP: php|architect's Guide to PHP Design Patterns, J2EE. Wzorce projektowe, Java. Wzorce projektowe