Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
 Reply to this topicStart new topic
> Ocena - Klasy tworzenia planety.
q3trm
post 10.04.2013, 21:51:29
Post #1





Grupa: Zarejestrowani
Postów: 83
Pomógł: 1
Dołączył: 26.02.2013

Ostrzeżenie: (0%)
-----

Cześć.

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


[PHP] pobierz, plaintext 
  1. class creatPlanet // klasa konstrukcyjna
  2.  {
  3.   public $planet;
  4.  
  5. 	 public function __construct(Planet $class)
  6. 	 {
  7. 	  return $this ->planet = $class;
  8. 	 }
  9.  
  10.  }
  11.  
  12.  
  13.   abstract class FuncPlanet // funkcje planet
  14.   {
  15. 	 public function __construct()
  16. 	 {
  17. 	   $this ->nameplanet = get_class($this);
  18. 	   $this ->increase = strlen($this ->nameplanet);
  19. 	 }
  20.  
  21.      public function getParamPlanet() //wyświetla wszystkie parametry ustawione przez użytkownika
  22.      {
  23.         foreach ($this ->parameter as $param => $p)
  24. 		{
  25. 		 echo '<br />'.$param. ' +' .$p;
  26. 		}
  27.      } 
  28. 	 public function getIncrease() //szybkość rozwoju planety
  29. 	 {
  30. 	    return $this ->increase;
  31. 	 }
  32. 	 public function getNamePlanet() //nazwa planety użytkownika
  33. 	 {
  34. 	     return $this ->nameplanet;
  35. 	 }
  36.    }
  37.  
  38.  
  39.   abstract class Planet extends FuncPlanet  // ustawienie początkowych parametrów planety przez użytkownika
  40.   {
  41.    protected $increase;
  42.    protected $nameplanet;
  43.    protected $parameter = array();
  44.  
  45.  
  46.      function __construct($economic = 0, $military = 0, $explorative = 0)
  47.      {  
  48. 	   $this ->parameter = array (
  49. 	    'economic' => $economic, 
  50. 	    'military' => $military,
  51. 	    'explorative' => $explorative
  52. 	    );
  53. 	       parent::__construct();
  54.      }
  55.    }
  56.  
  57.  
  58.   class Mercury extends Planet {}
  59.   class Venus extends Planet {}
  60.   class Earth extends Planet {}
  61.   class Jupiter extends Planet {}
  62.   class Saturn extends Planet {}
  63.   class Uranium extends Planet {}
  64.   class Neptune extends Planet {}
  65.  
[PHP] pobierz, plaintext


Ten post edytował q3trm 10.04.2013, 21:52:39
Go to the top of the page
+Quote Post
matiit
post 11.04.2013, 13:31:18
Post #2





Grupa: Zarejestrowani
Postów: 365
Pomógł: 70
Dołączył: 5.04.2009

Ostrzeżenie: (0%)
-----

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.
Go to the top of the page
+Quote Post
q3trm
post 11.04.2013, 15:51:10
Post #3





Grupa: Zarejestrowani
Postów: 83
Pomógł: 1
Dołączył: 26.02.2013

Ostrzeżenie: (0%)
-----

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ę?.
Go to the top of the page
+Quote Post
mstraczkowski
post 17.04.2013, 01:31:07
Post #4





Grupa: Zarejestrowani
Postów: 273
Pomógł: 52
Dołączył: 3.02.2013
Skąd: Przemyśl

Ostrzeżenie: (0%)
-----

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 wink.gif

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

Ten post edytował mstraczkowski 17.04.2013, 01:34:35


--------------------
Jeżeli moja wypowiedź Ci pomogła użyj przycisku
Go to the top of the page
+Quote Post
Fifi209
post 18.04.2013, 12:31:18
Post #5





Grupa: Zarejestrowani
Postów: 4 655
Pomógł: 556
Dołączył: 17.03.2009
Skąd: Katowice

Ostrzeżenie: (0%)
-----

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ć)


--------------------
Zainteresowania: C#, PHP, JS, SQL, AJAX, XML, C dla AVR
Chętnie pomogę, lecz zanim napiszesz: Wujek Google , Manual PHP
Go to the top of the page
+Quote Post
Crozin
post 18.04.2013, 13:23:10
Post #6





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----

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 cool.gif. 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.
Go to the top of the page
+Quote Post
q3trm
post 19.04.2013, 11:27:34
Post #7





Grupa: Zarejestrowani
Postów: 83
Pomógł: 1
Dołączył: 26.02.2013

Ostrzeżenie: (0%)
-----

Dzięki za rady snitch.gif. Jaki wzorzec by najlepiej pasował do mojego problemu?.
Go to the top of the page
+Quote Post
Crozin
post 19.04.2013, 11:29:47
Post #8





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----

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ć.
Go to the top of the page
+Quote Post
q3trm
post 19.04.2013, 12:36:37
Post #9





Grupa: Zarejestrowani
Postów: 83
Pomógł: 1
Dołączył: 26.02.2013

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
Crozin
post 19.04.2013, 13:05:06
Post #10





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----

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.
Go to the top of the page
+Quote Post
Dejmien_85
post 30.05.2013, 00:42:12
Post #11





Grupa: Zarejestrowani
Postów: 251
Pomógł: 23
Dołączył: 23.04.2013

Ostrzeżenie: (0%)
-----

Cytat(q3trm @ 19.04.2013, 13:36:37 ) *
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.


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 
  1. <?php
  2.  
  3. // Interfejs zachowań dla Zwierząt
  4.  
  5. interface Behaviours
  6. {
  7.     public function tryToFly();
  8.     public function makeSound();
  9. }
  10.  
  11. // Interfejs latania
  12. interface FlyBehaviour
  13. {
  14.     public static function tryToFly();
  15. }
  16.  
  17. // Interfejs wydawania dźwięku
  18. interface SoundBehaviour
  19. {
  20.     public static function makeSound();
  21. }
  22.  
  23.  
  24. class Szczekanie implements SoundBehaviour
  25. {
  26.     public static function makeSound(){
  27.         echo 'Szczeka... hał, hał...  <br/>';
  28.     }		
  29. }
  30.  
  31.  
  32. class Miauczenie implements SoundBehaviour
  33. {
  34.     public static function makeSound(){
  35.         echo 'Miauczy... miau, miau...  <br/>';
  36.     }	
  37. }
  38.  
  39.  
  40. class Mruczenie implements SoundBehaviour
  41. {
  42.     public static function makeSound(){
  43.         echo 'Mruczy... mrrr, mrrr...  <br/>';
  44.     }	
  45. }
  46.  
  47.  
  48. class Latanie implements FlyBehaviour
  49. {
  50.     public static function  tryToFly(){
  51.         echo 'Odbija się od ziemi i unosi się w przestworzach...  <br/>';
  52.     }	
  53. }
  54.  
  55.  
  56. class LatanieNieudane implements FlyBehaviour
  57. {
  58.     public static function  tryToFly(){
  59.         echo 'Próbuje wzbić się ponad ziemię, jednak mu się to nie udaje... <br/>';
  60.     }	
  61. }
  62.  
  63.  
  64. class LatanieSamolotem implements FlyBehaviour
  65. {
  66.     public static function  tryToFly(){
  67.         echo 'Wsiada do samolotu i odlatuje! <br/>';
  68.     }	
  69. }
  70.  
  71. class Zwierzeta implements Behaviours
  72. {
  73.     public $flying;
  74.     public $sound;
  75.     public $animal;
  76.  
  77.     public function run(){
  78.         echo $this->animal . ' ';
  79.         echo 'Biegnie, ale szbko! <br/>';
  80.     }
  81.  
  82.     public function look(){
  83.         echo "To jest " . $this->animal . "<br/>";
  84.     }
  85.  
  86.     public function makeSound(){
  87.         echo $this->animal . ' ';
  88.         $x = $this->sound;
  89.         $x::makeSound();
  90.     }
  91.  
  92.     public function tryToFly(){
  93.         echo $this->animal . ' ';
  94.         $x = $this->flying;
  95.         $x::tryToFly();
  96.     }
  97.  
  98.     public function changeBehaviour($zmiana){
  99.         $this->flying = $zmiana;		
  100.     }
  101. }
  102.  
  103. class Pies extends Zwierzeta
  104. {
  105.     public $flying = 'Latanie';
  106.     public $sound = 'Szczekanie';
  107.     public $animal = 'Pies';
  108. }
  109.  
  110. class Kot extends Zwierzeta
  111. {
  112.     public $flying = 'LatanieNieudane';
  113.     public $sound = 'Miauczenie';
  114.     public $animal = 'Kot';	
  115. }
  116.  
  117. ?>
  118. <!DOCTYPE html>
  119. <html>
  120. <head>
  121. <title></title>
  122. </head>
  123. <body>
  124. <?php
  125. $kot = new Kot;
  126. $kot->look();
  127. $kot->makeSound();
  128. $kot->trytofly();
  129. $kot->changeBehaviour('Latanie'); // Dynamiczna zmiana zachowania
  130. $kot->tryToFly();
  131.  
  132. echo '<br/>';
  133.  
  134. $pies = new Pies;
  135. $pies->look();
  136. $pies->makeSound();
  137. $pies->tryToFly();
  138. $pies->changeBehaviour('LatanieNieudane'); // Dynamiczna zmiana zachowania
  139. $pies->tryToFly();
  140.  
  141. echo '<br/>';
  142.  
  143. $kot->tryToFly();
  144. $s = 'LatanieSamolotem'; // Dynamiczna zmiana zachowania
  145. $kot->changeBehaviour($s);
  146. $kot->tryToFly();
  147.  
  148. ?>
  149. </body>
  150. </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ć. brzydal.gif

Ten post edytował Dejmien_85 30.05.2013, 01:01:00
Go to the top of the page
+Quote Post
« Następny starszy · Object-oriented programming · Następny nowszy »
 

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 

Tryb wyświetlania: Standardowy · Przełącz na: Linearny+ · Przełącz na: Drzewo

Śledź ten temat · Wyślij temat na e-mail · Wydrukuj ten temat · Subskrybuj to forum

RSS Wersja Lo-Fi Aktualny czas: 25.04.2024 - 13:17
Powered By IP.Board © 2024  IPS, Inc.
All changes by PHP.pl Administrators
Hosting zapewnia NQ.pl hosting, trac, svn