Witam
Posiadam abstrakcyjną klasę Wykres i dzieci tej klasy np. Wykres słupkowy, Wykres belkowy, Wykres liniowy itd. Teraz do utworzenia każdego z tych wykresów potrzebuję określonego zbioru opcji, z których tylko nieliczne być może będą wspólne dla wszystkich wykresów. Mój problem dotyczy wyboru jednego z rozwiązań sposobu dostarczenia tych opcji, które przyszły mi do głowy:
1. W każdej klasie zdefiniuję domyślną tablicę z ustawieniami, która będzie miała postać:

[PHP] pobierz, plaintext 
$settings = array(
	'chart' => array(
		'background' => '#FFFFFF',
		'marginTop' => 40
	),
	'values' => array(
		'showValues' => TRUE
	)
	//... itd
);
[PHP] pobierz, plaintext 

Edit: 2. Upakowanie wszystkich ustawień do osobnych zmiennych/tablic.
3. Napiszę abstrakcyjną klasę WykresUstawienia, która będzie zawierała wszystkie wspólne ustawienia oraz funkcje umożliwiające nimi zarządzanie oraz szereg klas, które będą dziedziczyły z tej klasy. Każdy wykres będzie miał osobną klasę ustawień.

Wydaje mi się, że pierwsze rozwiązanie jest lepsze i pisanie osobnych klas ustawień dla każdego rodzaju wykresu jest stratą czasu. Tak czy owak widziałem już parę różnych projektów na tym forum i pisanie osobnych klas ustawień wydaje się mieć jakiś sens

Proszę o pomoc w rozwiązaniu mojego małego problemu. Dzięki za pomoc.

A nie pomyślałeś o klasie z dynamiczną liczbą własności w przykładowym stylu:

[PHP] pobierz, plaintext 
class Configuration
{
  protected $_config;
  public function __construct()
  {
    $_config = array();
  };
  public function __destruct()
  {
    $_config = NULL;
  };
  public function get($name)
  {
    if(is_string($name))
    {
      if(array_key_exists($name, $_config))
      {
        return $_config[$name];
      }
      else
      {
        throw Exception('Brak własności o takiej nazwie');
      }
    }
    else
    {
      throw Exception('Nazwa nie jest stringiem');
    }
  };
  public function set($name)
  {
    if(is_string($name))
    {
      $_config[$name] = $value;
    }
    else
    {
      throw Exception('Nazwa nie jest stringiem');
    }
  };
}
$konfiguracja1 = new Configuration();
$konfiguracja1.set('klucz1', array('klucz' => 'wartosc'));
$konfiguracja1.set('klucz2', 'wartosc2');
$konfiguracja2 = new Configuration();
$konfiguracja2.set('klucz1', 5);
$konfiguracja2.set('klucz2', 2.897);
$konfiguracja1.get('klucz1');
[PHP] pobierz, plaintext 

Oczywiście można też inaczej, ale to pozwala robić wiele obiektów tej samej klasy z różnymi własnościami i dynamicznie modyfikowalnymi. Do tego można zmienić konstruktor pod wymagania i całą klasę rozszerzać też jak chcesz. Możesz dorzucić jeszcze funkcję clone by tworzyć mnóstwo obiektów tych samych czy do debugu __toString machnij

Tylko że w takim podejściu możesz jedynie klucze 1 rzędu wyciągać oraz ustawiać. Jeśli są one tablicą to musiałbyś zmodyfikować funkcje dostępu by obsłużyły one i to. Przykładowo w formie
$obiekt.get('klucz1rzedu.klucz2rzedu.klucz3rzedu');
co byłoby równoznaczne z dostępem do elementu:
$obiekt._config['klucz1rzedu']['klucz2rzedu']['klucz3rzedu'];
Tylko trzeba pamiętać, że . może też oznaczać dostęp do własności obiektu, jeśli wartość klucza jest obiektem. Rekurencja w tym wypadku byłaby wskazana.

@thek: Przecież to co pokazałeś ma dokładnie takie same wady/zalety co zwykła tablica.

Plusy użycia tablicy: pozornie szybszy czas na zrobienie tego.
Minusy użycia tablicy: jest to struktura dynamiczna, w przeciwieństwie do obiektu, który byłby strukturą statyczną. A jak powszechnie wiadomo dynamiczne struktury są mniej wygodne w użyciu, bardziej podatne na błędy, wymagają nieładnych "hacków" jeżeli chcemy wprowadzić jakąś kontrolę nad zawartością jaką przechowują/reprezentują.
Użycie obiektu niesie sporo korzyści przy niewielkich niedogodnościach typu kilka linijek kodu więcej*.

* chociaż akurat w większości przypadków dłuższy zapis czegoś nietrywialnego/niestandardowego jest lepszy - czytelniejszy i łatwiejszy w utrzymaniu.

Owszem Crozin... Ale ja też napisałem, że to dopiero wstęp do klasy konfiguracji, którą powinien sobie rozbudować zgodnie z własnymi wymaganiami/potrzebami. Mógłby przykładowo zmienić strukturę danych na taką, która odróżniała by dane w konfiguracji prywatne/chronione od publicznych czy też wspomnianą przez Ciebie kontrolę zawartości/typu przechowywanych danych. Kwestia tylko przemyślanego usystematyzowania struktury. To raptem tylko szkic wstępny od którego można zacząć. Nic więcej. Dopiero trzeba to porządnie rozbudować tak, by działało według naszych potrzeb. Samo posiadanie przez nią po najprostszym seterze i getterze, nie czyni z niej jeszcze klasy konfiguracyjnej pełną gębą. Można wszak przecież pójść o krok dalej i zabawić się w jej cache'owanie z użyciem __sleep oraz __wakeup między innymi czy tym podobne "zabawy". Można posłużyć się bardzo szybkim tworzeniem zbliżonych konfiguracji poprzez użycie __clone. Sam pewnie miałbyś wiele różnych pomysłów na rozbudowanie tego do akceptowalnego stopnia użyteczności.