Cześć.

Na początku zaznaczam, że to moje początki OOP, żeby nie było .

[PHP] pobierz, plaintext 
class creatPlanet // klasa konstrukcyjna
 {
  public $planet;
 
	 public function __construct(Planet $class)
	 {
	  return $this ->planet = $class;
	 }
 
 }
 
 
  abstract class FuncPlanet // funkcje planet
  {
	 public function __construct()
	 {
	   $this ->nameplanet = get_class($this);
	   $this ->increase = strlen($this ->nameplanet);
	 }
 
     public function getParamPlanet() //wyświetla wszystkie parametry ustawione przez użytkownika
     {
        foreach ($this ->parameter as $param => $p)
		{
		 echo '<br />'.$param. ' +' .$p;
		}
     } 
	 public function getIncrease() //szybkość rozwoju planety
	 {
	    return $this ->increase;
	 }
	 public function getNamePlanet() //nazwa planety użytkownika
	 {
	     return $this ->nameplanet;
	 }
   }
 
 
  abstract class Planet extends FuncPlanet  // ustawienie początkowych parametrów planety przez użytkownika
  {
   protected $increase;
   protected $nameplanet;
   protected $parameter = array();
 
 
     function __construct($economic = 0, $military = 0, $explorative = 0)
     {  
	   $this ->parameter = array (
	    'economic' => $economic, 
	    'military' => $military,
	    'explorative' => $explorative
	    );
	       parent::__construct();
     }
   }
 
 
  class Mercury extends Planet {}
  class Venus extends Planet {}
  class Earth extends Planet {}
  class Jupiter extends Planet {}
  class Saturn extends Planet {}
  class Uranium extends Planet {}
  class Neptune extends Planet {}
 
[PHP] pobierz, plaintext 

Od początku - nazewnictwo jak dla mnie jest trochę "nie tego".
creatPlanet - można już było dać PlanetCreator albo coś innego, bo teraz to wygląda trochę jak createPlanet (a czasownikowa nazwa dla klasy - średnio).

Dalej funcPlanet (może BasePlanet)?

Poza tym w Twoim przypadku wystarczyłoby wszystko wrzucić do klasy Planet.

Nie myślałem nad nazewnictwem podczas pisania klas, głównie skupiłem się na koncepcji stworzenia skryptu umożliwiającego łatwe rozwijanie w przyszłości.

Rozumiem, że aktualna struktura = "przerost formy nad treścią". Co w przypadku indywidualnego rozszerzania funkcjonalności planet. Nie lepiej by było je mieć w osobnych klasach, tak jak to jest teraz?. Wydaje mi się to bardziej czytelne. Cały czas w OOP mówi się o zasadzie "pojedynczej odpowiedzialności", czyli klasa pobiera parametry, ale nie ingeruje w nie, tak rozumiem zasadę pojedynczej odpowiedzialności. Mylę się?.

Moim zdaniem masz rację i nie powinieneś zamykać wszystkiego w jednej klasie.
No chyba, że ta klasa nazywała by się w twoim przypadku SolarSystem

Nie wystarczy pisać obiektowo, trzeba także myśleć i projektować obiektowo, bo sama deklaracja klasy, oraz modyfikatory dostępu to nie OOP.

Jako, że każda planeta w układzie słonecznym jest pewnym realnym obiektem, który może charakteryzować się różnymi cechami.
Ale może posiadać także cechy wspólne słusznie rozdzieliłeś planety jako osobne klasy, które dziedziczą po klasie abstrakcyjnej Planet

Wszystko zależy od tego przez jakie parametry chcesz opisywać Planety, jeżeli te parametry powtarzają się przy każdej z planet to nie widzę sensu tworzenia klas dla poszczególnych planet. W ogóle raczej planeta to planeta i wszystkie według mnie można opisać podobnie ew. dodać jakieś specjalne parametry (jakaś odpowiednia metoda, bo nawet jak stworzysz dodatkowe klasy to i tak będziesz musiał to pamiętać)

1. Uranium to nazwa pierwiastka, Uranus to nazwa planety.
2. Zastanów się, które zdanie ma sens: "Uran to Uran" czy może "Uran to planeta"? Już ten prosty test pokazuje Ci, że raczej powinieneś mieć jedną klasę Planeta i dowolną ilość jej instancji (Merkury, Wenus, Ziemia, Mars, ..., Neptun, ..., Ozyrys, COROT-12 b czy Kepler-7 . Wszystkie one mają cechy/właściwości wspólne: nazwa, średnica, masa.
3. Pamiętaj, że nazwą klasy powinien być rzeczownik (np. PlanetCreator), zaś nazwą metod czasownik (np. create czy getName()).
4. Jest bardzo niewiele przypadków, gdzie użycie $this ->nameplanet = get_class($this); byłoby uzasadnione. Nazwa planety to jedna z jej podstawowych właścwiości i powinna zostać przekazana jako argument konstruktora.
5. Widzę, że każdej z planet przypisujesz jakieś właściwości nie związane bezpośrednio z samą planetą, tj. jej potencjał ekonomiczny czy militarny. Takie coś powinno być ujęte albo w kompletnie innym obiekcie, który na podstawie przekazanej mu planety zwracałby jej potencjał militarny/ekonomiczny, bądź w osobnym obiekcie będącym właściwością samego obiektu Planeta.
6. Zastanawiasz się czy utworzenie osobnej klasy (dziedziczącej po Planet czy też implementującej jakiś tam interfejs) celem implementacji specyficznych właściwości nie będzie lepsze. Powinieneś mieć na uwadze to, że obiekt typu Planeta to przykład tzw. obiekt domeny, a te raczej nie powinny wykonywać zbyt wielu operacji. Ich przeznaczenie to reprezentacja danych oraz najbardziej podstawowe operacje na nich, czyli taki obiekt Planeta mógłby mieć metody typu: isHeavierThan(Planet $other) czy getGravitationalAcceleration(). Jakieś bardziej zaawansowane operacje powinny już być wykonywane spoza obiektu typu Planet.

Dzięki za rady . Jaki wzorzec by najlepiej pasował do mojego problemu?.

1. Jeszcze jedna uwaga: nie korzystaj z tablic do przechowywania właściwości obiektu, które nie są kolekcją (patrz: potencjał militarny/ekonomiczny).
2. Przede wszystkim opisz nam tutaj co tworzysz, czym mają być te planety (z punktu widzenia programu/użytkownika, nie kodu) i co będzie miało się z nimi robić. Wtedy będziemy mogli napisać Ci jak się za to zabrać.

1. Chodzi ci o to, że dane nie są ze sobą powiązane?.

2. Tworzę grę na przeglądarkę. W tej grze użytkownik ma możliwość wyboru planety, oraz późniejszego jej rozwijania. Każda planeta ma jakąś metodykę rozwoju np: militarną, ekonomiczną, odkrywczą, którym użytkownik przydziela punkty(tylko podczas tworzenie planety). Wszystkie planety cechuję szybkość ogólnego rozwoju($increase), która różni się w zależności od wybranej planety(obliczanie na podstawie nazwy planety w skrypcie, jest tylko prowizorycznym zastosowaniem).

Krótko mówiąc, czysty model tworzenia planety za pomocą formularza. Nie chcę gotowca, prosiłbym o nazwę wzorca odpowiadającym do ww. logiki skryptu. Zastanawiam się nad wzorcem Decorator, Strategy.

1. Chodzi o to, że takie rzeczy powinny być właściowścią obiektu (każda z osobna), a nie umieszczone w tablicy. Dlaczego? Bo łatwiej wtedy przydzielić im indywidualne cechy, łatwiej udokumentować kod czy ogólnie utrzymywać go.
2. Rozumiem, że te planety nie ograniczają się do naszego Układu Słonecznego? W takim wypadku obiekt typu Planeta powinien mieć jakieś podstawowe właściwości opisujące samą planetę (np. nazwa czy wspomniana szybkość ogólnego rozwoju). Punkty przydzielone przez użytkownika mogą być albo bezpośrednimi właściwościami tego obiektu, mogą też być osobnym obiektem będącym właściwością obiektu Planeta. Które rozwiązanie jest lepsze? To już zależy, m.in. od tego czy obiekt Planeta i MetodykaRozwojuPlanety są rozbudowane czy nie. Jednak prawdopodobnie osobny obiekt, będzie lepszym rozwiązaniem.

Wydaje mi się, że "The Strategy Pattern" by się tutaj świetnie spisał, mógłbyś stworzyć niezależne interfejsy oraz klasy zachowań poszczególnych planet, które można by nawet przydzielać planetom dynamicznie (w trakcie działania aplikacji).

Poniżej przykład mojego pierwszego kodu (napisanego milion lat temu) z implementacją "The Strategy Pattern" - wklejam prosto ze starych notatek, nie chce mi się go nawet poprawiać. Jego przejrzenie może dać ogólne pojęcie nt. odizolowania rzeczy statycznych od rzeczy zmiennych. Na jego przykładzie widać jak łatwo można implementować nowe zachowania, czy zmieniać je dynamicznie podczas działania aplikacji (at run-time).

[PHP] pobierz, plaintext 
<?php
 
// Interfejs zachowań dla Zwierząt
 
interface Behaviours
{
    public function tryToFly();
    public function makeSound();
}
 
// Interfejs latania
interface FlyBehaviour
{
    public static function tryToFly();
}
 
// Interfejs wydawania dźwięku
interface SoundBehaviour
{
    public static function makeSound();
}
 
 
class Szczekanie implements SoundBehaviour
{
    public static function makeSound(){
        echo 'Szczeka... hał, hał...  <br/>';
    }		
}
 
 
class Miauczenie implements SoundBehaviour
{
    public static function makeSound(){
        echo 'Miauczy... miau, miau...  <br/>';
    }	
}
 
 
class Mruczenie implements SoundBehaviour
{
    public static function makeSound(){
        echo 'Mruczy... mrrr, mrrr...  <br/>';
    }	
}
 
 
class Latanie implements FlyBehaviour
{
    public static function  tryToFly(){
        echo 'Odbija się od ziemi i unosi się w przestworzach...  <br/>';
    }	
}
 
 
class LatanieNieudane implements FlyBehaviour
{
    public static function  tryToFly(){
        echo 'Próbuje wzbić się ponad ziemię, jednak mu się to nie udaje... <br/>';
    }	
}
 
 
class LatanieSamolotem implements FlyBehaviour
{
    public static function  tryToFly(){
        echo 'Wsiada do samolotu i odlatuje! <br/>';
    }	
}
 
class Zwierzeta implements Behaviours
{
    public $flying;
    public $sound;
    public $animal;
 
    public function run(){
        echo $this->animal . ' ';
        echo 'Biegnie, ale szbko! <br/>';
    }
 
    public function look(){
        echo "To jest " . $this->animal . "<br/>";
    }
 
    public function makeSound(){
        echo $this->animal . ' ';
        $x = $this->sound;
        $x::makeSound();
    }
 
    public function tryToFly(){
        echo $this->animal . ' ';
        $x = $this->flying;
        $x::tryToFly();
    }
 
    public function changeBehaviour($zmiana){
        $this->flying = $zmiana;		
    }
}
 
class Pies extends Zwierzeta
{
    public $flying = 'Latanie';
    public $sound = 'Szczekanie';
    public $animal = 'Pies';
}
 
class Kot extends Zwierzeta
{
    public $flying = 'LatanieNieudane';
    public $sound = 'Miauczenie';
    public $animal = 'Kot';	
}
 
?>
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<?php
$kot = new Kot;
$kot->look();
$kot->makeSound();
$kot->trytofly();
$kot->changeBehaviour('Latanie'); // Dynamiczna zmiana zachowania
$kot->tryToFly();
 
echo '<br/>';
 
$pies = new Pies;
$pies->look();
$pies->makeSound();
$pies->tryToFly();
$pies->changeBehaviour('LatanieNieudane'); // Dynamiczna zmiana zachowania
$pies->tryToFly();
 
echo '<br/>';
 
$kot->tryToFly();
$s = 'LatanieSamolotem'; // Dynamiczna zmiana zachowania
$kot->changeBehaviour($s);
$kot->tryToFly();
 
?>
</body>
</html>
[PHP] pobierz, plaintext 

UWAGA: Kod służył tylko do praktyki, tak więc latające koty i miauczące psy nie powinny nikogo dziwić.