[PHP]OOP'owe początki Opcje

[Fanatyko]

Witam, zaczynam zabawę z OOP'em przy wykorzystaniu wzorca MVC. Czy kod poniżej jest poprawny, czy też nie ? Co zmienić, co robić, czego nie robić (ogólnie tak jakos )
Z czasem będę dodawał nowe pytania, bo zapewne na jednym się nie skończy

[PHP] pobierz, plaintext 
<?php
 
$Controler = new GameController;
 
 
class GameController
{
    public function __construct()
    {
      if(isset($_GET['action']))
      {
        $strAction = $_GET['action'];
 
      }
      else
      {
        $strAction = "statystyki";
 
      }
      $objAction = new $strAction();           
      $objAction->DoAction();  
 
 
 
    }
 
}
 
class ShowCharacter 
{
    public function DoAction()
    {
      $objModel = new CharacterModel();
      $arrCharacter = $objModel->GetCharacter();
 
      foreach ($arrCharacter as $arrStatisctics)
      {
        echo "Sila: ".$arrStatisctics['strenght']." Zrecznosc: ".$arrStatisctics['agility']."";
      }
 
      return null;
 
    }
 
}
 
class CharacterModel
{
    public function GetCharacter()
    {
       return array(array( 'strenght' => 15, 'agility' => 20)) ;    
    }
 
 
}
 
 
 
?>
[PHP] pobierz, plaintext 

[Pawel_W]

po 1:

[PHP] pobierz, plaintext 
      if(isset($_GET['action']))
      {
        $strAction = $_GET['action'];
 
      }
      else
      {
        $strAction = "statystyki";
 
      }
[PHP] pobierz, plaintext 

żadne takie ify z $_GET, to powinno być przekazane w konstruktorzem czyli np.

[PHP] pobierz, plaintext 
$Controler = new GameController($_GET['action']);;
[PHP] pobierz, plaintext 

2.

[PHP] pobierz, plaintext 
      $objAction = new $strAction();           
      $objAction->DoAction();  
[PHP] pobierz, plaintext 

to się aż prosi o zastosowanie wzorca projektowego "factory"

po 3: DZIEDZICZENIE! - naprawdę warto byłoby z niego tu skorzystać

[Fanatyko]

1.Ok dzięki, zaraz to poprawię.
2.Jakiś przykładzik by się dało ?
3.Przykład gdzie można to zastosować bym prosił (średni ogarnięty z dziedziczeniem jestem ;p)

Dzięki za opowiedzi

[Pawel_W]

2. http://bukox.pl/php/wzorce-projektowe-factory/

3. mógłbyś spokojnie połączyć klasy character model i show character, tak, żeby ta druga dziedziczyła z pierwszej, bo jak znam życie to pewnie to jeszcze rozbudujesz i tak Ci będzie prościej

[Fanatyko]

OK, dziękuje. Potestuję sobie to co podrzuciłeś. Zapewne pytań ciąg dalszy niedługo

[Crozin]

1) Twój kod nie ma wiele wspólnego z MVC - brak w nim w ogóle warstwy widoku.
2) Nie za bardzo wiem co Pawel_W miał na myśli przez dziedziczenie. Tutaj jego wykorzystanie byłoby błędem - przecież ShowCharacter::DoAction() jedynie wykorzystuje CharacterModel.
3) Twoja klasa GameController bardziej przypomina Dispatcher niż kontroler.

btw: return null; jest zbędne.

[Pawel_W]

wyszedłem z założenia, że każda postać będzie miała własne statystyki, dlatego dobrze byłoby to wszystko połączyć

[Crozin]

Model ma się zajmować swoim zadaniem: ma udostępniać dane, a nie nimi zarządzać.

[Fanatyko]

Twój kod nie ma wiele wspólnego z MVC - brak w nim w ogóle warstwy widoku.

A klasa ShowCharacter ?

Twoja klasa GameController bardziej przypomina Dispatcher niż kontroler.

Mógłbyś wyjaśnić dlaczego ?

[Crozin]

Widok nie tworzy sam sobie modelu - to kontroler inicjalizuje widok i przekazuje mu model(e).

[Luneth]

Jedyne dziedziczenie jakie mi przychodzi tutaj na myśl to ewentualnie kontroler rozszerzający widok, żeby mieć dostęp do jego metod. Co do tych ifów w kontrolerze - zgodzę się z przedmówcą, ogólnie zrób sobie jakąś klasę router, która będzie parsować i filtrować żądanie GET, a jeśli kontroler ma parę różnych opcji co do wykonania akcji - to możesz np zastosować switcha miast tych ifów. Dodatkowo takie składowe funkcje widoku powinny zwracać te wartości zamiast od razu je wyświetlać, ogólnie funkcje same w sobie powinny zawsze coś zwracać. No i te kwestie o których Crozin też wspomniał.

Ponadto: http://www.phppatterns.com/docs/design/arc...rn?s=model+view

Ten post edytował Luneth 15.08.2010, 03:01:27

[Fanatyko]

@Crozin ok, chyba załapałem
@Luneth dzięki, przydatny link.

Popracuję na kodem i zobaczę co mi wyjdzie.

Wiecie co ? Jednak nie czaje absolutnie MVC

Mógłby ktoś napisać/dać linka do baaardzo prostego przykładu MVC ? Taki który tłumaczy zasady tegoż wzroca. Byłbym wdzięczny.

PS. Czytałem troche tematów na forum ale nic mi to nie dało. Głupi jakoś jestem ostatnio

[Crozin]

http://forum.php.pl/index.php?s=&showt...st&p=771967

[Luneth]

Po prostu wszystko dzielisz na trzy kategorie: operacje na danych, pobieranie-udostępnianie danych, wyświetlanie danych (kontroler,model,widok). Kontroler ma wybierać model, dać go do widoku, widok z modelu ma wziąć dane i zapakować je w coś przyjemnego dla oka MVC to po prostu pewna konkretna abstrakcja sposobu działania aplikacji, uporządkowania czegoś, nałożenia pewnych zasad jak i ograniczeń. Tego typu wzorce projektowe mają dwa podstawowe cele: umożliwiać przystępną rozbudowę (o kolejne abstrakcyjne wymysły, lub wprowadzanie np nowości w php, np wyobraź sobie, że chcesz wprowadzić przestrzenie nazw) no i ułatwiać pracę w grupie. Wolałbyś pracowac z np 10 osobami na czymś strukturalnym czy na takim ładnym, estetycznym, podzielonym na warstwy kodzie z interfejsami, klasami abstrakcyjnymi, z hermetyzacją, gdzie kod sam Ci mówi w jaki sposób działa i czego masz z nim nie robić przypadkiem? Próbuj to ogarnąć, w końcu to "poczujesz" i załapiesz.

Tak samo jak masz bardziej złożone wzory matematyczne, ktoś je ułożył raz, byś Ty mógł ich używać i wykonywać obliczenia do których "zmusza" Cię ten wzór, zostały one przewidziane przez jego autora. Ufam, że kojarzysz wzór na deltę funkcji kwadratowej Niby na 1 rzut oka nie wiadomo skąd te zależności w nim, ale stosując go właściwie masz pewność że otrzymujesz dobre wyniki bez rysowania sobie na kartce wykresu funkcji, prawda? To właśnie programowanie strukturalne jest takim mozolnym zaznaczaniem punktów i ich łączeniem a ten wzór taką przejrzystą zależnością pomiędzy składowymi (wzorce projektowe, obiektowe programowanie).

Ten post edytował Luneth 17.08.2010, 01:43:51

[Fanatyko]

[PHP] pobierz, plaintext 
<?php
 
 
class GameController
{
  public function ShowChar()
  {
    $View = new View();
    $View->SetModel(new GameModel);
    return $View; 
 
  }
}
 
class View
{
  public function SetModel($model)
  {
   $this->Model = $model;  
  }
 
  public function SetTemplate($template)
  {
   $this->Template = $template;
  }
 
  public function Show()
  {  
   $Data = $this->Model;
   $this->Char = $Data->GetChar();
   $this->SetTemplate('table');
   include ('' . $this->Template . '.php');  
  }
 
}
 
class GameModel
{
  public function GetChar()
  {
    return array(array( 'strenght' => 15, 'agility' => 20)) ;    
 
  }
 
 
}
 
$GameController = new GameController();
$Result = $GameController->ShowChar();
 
if ($Result instanceof View) 
{
	$Result->Show();
}
 
 
?>
[PHP] pobierz, plaintext 

Wymodziłem coś takiego, większość zerżnięta od Crozina ;D

Luneth dzięki za ten post, pomógł i to bardzo.

I jak mi wyszło ?

[Luneth]

1. Jeśli robisz settery to ustal tym atrybutom jaki ma być do nich dostęp tutaj pasuje protected, bo private wtedy, kiedy klasa ma być rozszerzana i coś nie ma być dostępne klasie - dziecku.
2. Zakładając, że chcesz mieć różne modele i templatki do jednego widoku to ok, ale jak nie to niepotrzebne te settery (bo jak nie, to kontroler mógłby np widokowi przekazać zmienną z obiektem modelu jako parametr do konstruktora)
3. Trochę przekombinowane z tym zwracaniem widoku przez kontroler ale swoją drogą ciekawe

Ten post edytował Luneth 17.08.2010, 12:04:19

[Crozin]

To właśnie programowanie strukturalne jest takim mozolnym zaznaczaniem punktów i ich łączeniem a ten wzór taką przejrzystą zależnością pomiędzy składowymi (wzorce projektowe, obiektowe programowanie).

Nie... paradygmat programowania strukturalnego wcale nie jest gorszy od obiektowego - on jest inny.

I jak mi wyszło ?

Trochę zrypane Copy&Paste View to raczej klasa abstrakcyjna, a Ty operujesz na jej potomkach, bo sama w sobie jest zbyt ogólna.

(bo jak nie, to kontroler mógłby np widokowi przekazać zmienną z obiektem modelu jako parametr do konstruktora)

Raczej zły pomysł. Nagle w aplikacji pojawiło by się jedno API dla widoków, dla których można ustalić inny szablon i inne API dla takich ze stałym. Swoją drogą czegoś takiego jak stały szablon dla widoku być nie powinno - jak już to mógłby być jakiś domyślny.

Trochę przekombinowane z tym zwracaniem widoku przez kontroler ale swoją drogą ciekawe

Dlaczego przekombinowane? Działanie aplikacji niekoniecznie musi kończyć się wraz z ostatnią linijką kontrolera.

[Luneth]

Crozin: oczywiście, że programowanie strukturalne jest inne, myślę że wszyscy już o tym tutaj wiedzą, ale ciekawe spostrzeżenie miałem na myśli to, że w większości przypadków kończy się to tzw. 'kodem spaghetti'. Przekombinowane, bo dosyć wymyślne, oczywiście kolejna rzecz którą wszyscy wiemy - tak, masz rację, nie musi się to kończyć ostatnią linijką. Przekombinowane nie znaczy źle zrobione czy 'tak się nie robi' Co do tego, że jego View nie jest abstraktem - dla tak prostego kodu który nam przedstawił wcale mnie nie dziwi, że nie zastosował dziedziczenia... na pewno przy rozwijaniu projektu sam zauważy, że mu to potrzebne A na koniec powiem, że nie rozumiem tego:

Raczej zły pomysł. Nagle w aplikacji pojawiło by się jedno API dla widoków, dla których można ustalić inny szablon i inne API dla takich ze stałym. Swoją drogą czegoś takiego jak stały szablon dla widoku być nie powinno - jak już to mógłby być jakiś domyślny.

Przecież powiedziałem, że jeśli przewiduje różne sposoby przedstawianie danych, to dobrze zrobił? A swoją drogą kompletnie nie rozumiem jak się doszukałeś jakichś problemów z różnymi API... MVC chyba nie zakłada z góry, że mają/mogą być różne szablony do wszystkiego? Bo to już chyba własne założenia programisty są, jak on to widzi, ale może się mylę.

Ten post edytował Luneth 17.08.2010, 15:01:28

[Crozin]

Chyba oboje się nie zrozumieliśmy...
Myślałem, że sugerujesz stworzenie dwóch wersji API dla różnego rodzaju widoków, co byłoby błędem.

[Luneth]

A to faktycznie kompletne nieporozumienie nam wyszło w tej kwestii