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 

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ć

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

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

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

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.

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ć

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

A klasa ShowCharacter ?



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

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

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

@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

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

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

[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 ?

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

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

Trochę zrypane Copy&Paste View to raczej klasa abstrakcyjna, a Ty operujesz na jej potomkach, bo sama w sobie jest zbyt ogólna.
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.
Dlaczego przekombinowane? Działanie aplikacji niekoniecznie musi kończyć się wraz z ostatnią linijką kontrolera.

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:

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ę.

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.

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