Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [uml] Indetyfikacja klas
Forum PHP.pl > Forum > PHP > Object-oriented programming
patryczakowy
Witam zacząłem bawić się troszkę uml zakładam temat tutaj bo niestety niema na tym forum działu uml i w tym miejscu raz jeszcze rzucę propozycję utworzenia takiego działu. W końcu wcześniej czy później każdemu programiście przyjdzie się zmierzyć z tym językiem.
Problem mam taki zacząłem szukać klas jakie powinny być w projekcie no i przy identyfikacji klas ukazało mi się mnóstwo list np:
lista ofert, lista wiadomości, lista zamówień i wiele wiele innych.
I teraz pytanie jak to rozwiązać w pierwszej chwili pomyślałem klasa bazowa(abstrakcyjna) lista a każda lista będzie dziedziczyć po tej klasie jakieś podstawowe właściwości.
Ale w ten sposób będę miał mnóstwo(dziesiątki) rożnych klas dziedziczących po liście.
To drugi pomysł jedna klasa lista obsługuje wszystkie listy. No i to też nie wydaje mi się dobrym pomysłem może ktoś zaproponuje jakieś ciekawe rozwiązanie.
Crozin
Przepraszam, że nie na temat, ale język polski obsługuje: kropki, wielkie litery, akapity i co najważniejsze... literę "ó".
patryczakowy
Teraz lepiej?
JoShiMa
A te listy to nie mogą być po prostu tablice obiektów?

BTW. Jaki to ma związek z UMLem?
patryczakowy
Taki że będę z tego robił diagram klas.
Mógłbyś rozwinąć myśl z tą tablicą jakie obiekty by w niej miały być? Sprecyzuj to bardziej bo wiesz ja większość programowałem
proceduralnie i teraz troszkę trudno mi się na obiektowy sposób myślenia przerzucić?
JoShiMa
Cytat(patryczakowy @ 16.05.2009, 21:28:44 ) *
Mógłbyś rozwinąć myśl z tą tablicą

Mogłabym. Jeśli potrzebujesz mieć listę wiadomości to robisz klasę definiująca wiadomość i tablicę, której elementami są obiekty tej klasy. No chyba, że potrzebujesz, żeby ta lista wiadomości miała jakieś swoje funkcje, to faktycznie lepiej zrobić odpowiednią klasę
patryczakowy
No właśnie nie każda lista będzie miała metody niektóre będą się tylko wyświetlać inne zaś będą posiadać metody dodawania, usuwania, ale teraz wpadł mi pomysł przecież nie dodaję obiektów do listy tylko tworzę obiekty a lista to tylko zbiór tych obiektów.
Więc może jedna klasa lista która będzie przyjmować różne obiekty i je wyświetlać, ewentualnie sprawdzać czy dany użytkownik może oglądać tą listę.
No bo w tym całym obiektowym programowaniu w końcu chodzi o to żeby wykorzystywać klasę wiele razy.
Crozin
Cytat
inne zaś będą posiadać metody dodawania, usuwania
Ale zapewne ograniczy się to do dodania/usunięcia elementu z listy i niczego więcej? Zwykła tablica spisze się doskonale.
Cytat
przecież nie dodaję obiektów do listy tylko tworzę obiekty a lista to tylko zbiór tych obiektów
Ale i tak na jakimś tam etapie do tej listy (nieważne czy to będzie zwykła tablica czy jakiś obiekt) dodajesz utworzone wcześniej obiekty.
Cytat
Więc może jedna klasa lista która będzie przyjmować różne obiekty i je wyświetlać
Ale wyświetlać, czyli co? Zwracać, generować kod HTML czy coś innego?
Cytat
ewentualnie sprawdzać czy dany użytkownik może oglądać tą listę
IMO to powinno być wykonane przed utworzeniem jakichkolwiek obiektów, do których ktoś nie ma dostępu.
patryczakowy
Wyświetlać czyli dołączać odpowiedni szablon
Crozin
Takie coś to już nie zadanie dla tej listy (kolekcji). Ona powinna się ograniczyć do przechowywania swoich elementów oraz dawać możliwość ich dodawania/usuwania/wyszukiwania/segregowania i oczywiście zwracania. Sama w sobie nie powinna mieć nic wspólnego z widokiem aplikacji - to powinien zrobić jakiś kontroler, który ma dostęp do listy i widoku (szablonów).
patryczakowy
A możesz podać jakiś uproszczony przykład takiego kontrolera?
Crozin
kontroler:
  1. <?php
  2. $abcJakisModel = new ABCJakisModel();
  3. $collection = $abcJakisModel->getSthCollection();
  4.  
  5. $myView->set('collection', $collection);
  6. ?>
Model:
  1. <?php
  2. class AbcJakisModel ...{
  3.  ...
  4.  
  5.  public function getSthCollection(){
  6.    return $this->database->getRows('...');
  7.  }
  8. }
  9. ?>
Jakiś szablon:
  1. <h2>Lista czegośtam:</h2>
  2. <ul>
  3.   <?php foreach($collection as $item): ?>
  4.   <li><?php echo $item['cos_tam'] ?></li>
  5.   <?php endforeach; ?>
  6. </ul>
Jeżeli uznasz to za stosowne, zamiast zwracać zwykłą tablicę możesz zwracać jakiś obiekt kolekcji - listę. Zastanów się tylko czy aby napewno tego potrzebujesz. Dobrze by też było by ten obiekt implementował m.in. interface Iterator by można go było wrzucić w pętlę foreach() w widoku.
patryczakowy
Jako że zamierzam to zrobić na smarty to chyba rodzaj takiego kontrolera będzie właśnie pełniła klasa smarty której przekażę tablicę lub obiekt i nazwę szablonu.
Czy może lepiej napisać jakąś własną klasę dziedziczącą po smarty?
Co to jest interfejs to wiem tylko jak miała by wyglądać implementacja takiego iteratora bo tego za bardzo nie rozumiem?
Crozin
Eee... Smarty to może być co najwyżej widok, nie kontroler.

Cytat
Co to jest interfejs to wiem tylko jak miała by wyglądać implementacja takiego iteratora bo tego za bardzo nie rozumiem?
Lekki oksymoron smile.gif
Przykład użycia interaceu iterator znajdziesz np. tutaj: http://www.sitepoint.com/article/php5-standard-library/
patryczakowy
ok dzięki na razie za wszystkie podpowiedzi jak przejrzę to o czym mi pisałaś to pewnie wrócę jeszcze do tematu



Powyżej jest diagram klas który udało mi się stworzyć.
Jest parę luźnych klas które nie wiem na razie jak połączyć z całością .
Na razie nie opisuje tego co jest tu zrobione bo chce zobaczyć czy jest to dla was chociaż w 50% czytelne i czy umielibyście coś z tego napisać? Wszelkie, komentarze, sugestie, krytyka mile widziana.

Widzę że zainteresowanie tematem jest żadne.
Szkoda nasuwają się mi tylko dwie rzeczy namyśl:
1 Albo ten schemat jest całkiem do d...
2 Albo rozdział pod tytułem UML należy zamknąć bo nie warto się tego uczyć i lepiej tak jak do tej pory wszystko w czaszce sobie układać?
A wy panowie co zawodowo w branży siedzicie (chodzi mi o tych co w firmach pracują) jak często spotykacie się z UML?
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.