Jak traktowac obiekty? Opcje

[Beynar]

Ostatnio mnie nurtuje pytanie dot. OOP... mianowicie mam nastepujace pytania:

1. Czy wlasciwym jest pisac np. klase user uzywac jej w ten sposob by do kazdej metody podawac jakies argumenty ktore w rzeczywistosci beda odnosic sie do roznych userow? Czy tworzyc instancje klasy danego user i w tym momencie wszystkie metody obiektu nie przyjmuja argumentow dotyczących tego na jakim userze ma wykonywac operacje, poniewaz operuje na obecnym stanie obiektu - danym userze.

2. Jesli przyjac powyzsza idee, to jak rozwiazac problem gdy dany obiekt wyjsciowo ma reprezentowac jakis string. Generowac napis ktory ma zostac wyswietlony. Takich napisow ma byc 30. Tworzyc 30 obiektow tylko po to zeby je wydrukowac? Chyba troche malo optymlanie... z drugiej strony jesli skorzystac z jednego obiektu do budowania tych 30 napisow to moj obiekt zamini sie w mala fabryke i juz nie bedzie tak swietnie implementowal idei obiektowosci (tak mysle, moze blednie).

Ten post edytował Beynar 19.05.2008, 22:00:08

[Cotter]

1. Oba rozwiązania mają wady i zalety i wbrew pozorom user jako reprezentant wszystkich użytkowników nie jest programowaniem strukturalnym. Wielu programistów zadaje sobie pytanie co powinno być modelem. W znanym CakePHP modelem jest cała tabela.

Ja zawsze skłaniałem się ku rozwiązaniu gdzie 1 użytkownik = 1 obiekt User. Głównym jego plusem jest naturalność w korzystaniu i łatwość w operowaniu danymi. Minusem w porównaniu z rozwiązaniem alternatywnym może być szybkość oraz konieczność konwertowania rekordów z bazy danych na obiekty. Jest to szczególnie istotne kiedy na przykład chcesz wyświetlić tabelę podstawowych informacji 100 użytkowników.

Aby radzić sobie z takimi sytuacjami można w klasie User implementować metody statyczne, które upraszczają i przyspieszają wykonywanie kluczowych operacji na wielu użytkownikach na raz. Przykładem takiej metody może być: User::getUsers() która zwraca tabelkę z gotowymi do wyświetlenia informacjami.

Rozwiązanie 1 User = 1 użytkownik + metody statyczne zapewnia jeden punkt dostępowy do całej tabeli użytkowników i posiada zalety obu rozwiązań.

2. Adresy URL warto rozwiązać podobnie jak w przypadku użytkowników. Wszystkie najczęstsze metody warto zaimplementować statycznie, aby nie tworzyć zbędnie obiektów. Nie warto wszystkiego implementować w ten sposób (a tym samym tworzyć jednego obiektu który zawiera wszystkie takie metody), ponieważ skończy się to na implementacji wielu metod wymagających bardzo wielu niezrozumiałych parametrów. Jeżeli występuje potrzeba stworzenia skomplikowanego i nietypowego URLa można stworzyć obiekt i użyć zwykłych metod aby łatwo wygenerować porządany adres.

Osobiście właśnie tak piszę moje strony. Najważniejsze w tego typu pisaniu jest poprawne decydowanie o tym co może być statyczne, a co nie.