Obiekt czy obiekty, problem ze zrozumieniem zagadnienia Opcje

[Fixus]

Witam,
mam problem z rozwiązaniem pewnego zagadnienia. Nie chodzi o samo programowanie, ale o dobre podejście do tego.

Posłużę się chyba najprostszym przykładem. Moduł obsługi usera

Mamy obiek User który ma następujące właściwości

[PHP] pobierz, plaintext 
public $name;
public $surname;
[PHP] pobierz, plaintext 

posiada też metody get set

Zastanawiam się czy obiekty takie jak register (rejestracja), editData (edycja) powinny zawierać się w tym obiekcie czy w jakimś np. User_control ?

Czy to powinno być rozbijane czy nie ?

[l3l0]

Zastanawiam się czy obiekty takie jak register (rejestracja), editData (edycja) powinny zawierać się w tym obiekcie czy w jakimś np. User_control ?

Czy to powinno być rozbijane czy nie ?

Witam,

Myśle żę na to pytane nie ma jedoznaczej odpowiedzi.
Ogólnie musisz przemyśleć czy rozbicie tej klasy na więcej klas coś Ci da...
Tak samo jak ze wzoracami projektowymi, przecież nie używa się ich ponieważ wszyscy mówią że są super, a dlatego że pomagają w utrzymaniu aplikacji. Czasem po prostu nie warto używać wzorca ponieważ może on tylko zaciemnić i skąplikować nasz kod, tak samo w tym przypadku.
Jeśli nie masz pojęcia dlaczego miałbyś rozbjać tą klase to lepiej tego nie rób. Najwyżej póżniej jeśli się okaże że jest to potrzebne zrobisz refactoring.

[Fixus]

brzmi to sensownie

Po prostu czasami się zastanawiam czy LOGICZNIE jest aby obiekt User sam siebie dodawał i sam siebie edytował. Jednak to chyba niepotrzebne komplikowanie sprawy

[marcio]

brzmi to sensownie

Po prostu czasami się zastanawiam czy LOGICZNIE jest aby obiekt User sam siebie dodawał i sam siebie edytował. Jednak to chyba niepotrzebne komplikowanie sprawy

Fakt brzmi sensownie ale wedlug ciebie co powinien robic modul logowania?

Autoryzacja i tyle,rejestracja to inna logika inny widok inny model ogolnie osobny modul tak samo z edycja danych user'a raczej wypadaloby wsadzic do modulu profilu.

Latwiej jest zmodyfikowac/edytowac/rozszerzyc jeden klocek niz caly dom z klockow.



PS.

Ogólnie musisz przemyśleć czy rozbicie tej klasy na więcej klas coś Ci da...

Da logike dzialania danego modulu nie mozna wszystkiego pakowac do jednej klasy czy jednego modulu jak nie to znow wracamy do programowania proceduralnego/funkcyjnego i do burdelu w kodzie.

[Fixus]

PS.

Cytat
Ogólnie musisz przemyśleć czy rozbicie tej klasy na więcej klas coś Ci da...


Da logike dzialania danego modulu nie mozna wszystkiego pakowac do jednej klasy czy jednego modulu jak nie to znow wracamy do programowania proceduralnego/funkcyjnego i do burdelu w kodzie.

Tym trafiłeś w sedno. Moje pytanie właśnie wynikło z wątpliwości dotyczące tej różnicy. Ponieważ nie chce tworzyć jednej klasy z metodami która de facto stanie się plikiem z funkcjami, a zrobić to sensownie. Szukam tej granicy, która pomoże mi odpowiednio rozdzielać całość

[marcio]

Dlatego najpierw podziel dobrze logike co kazdy modul ma robic i potem to zaimplementuj .

Jak nie to wszystko mozna wsadzic do jednej klasy i  gra a potem burdel na maxa i wlasciciel kodu nie wiem gdzie ma rece wlozyc

[cojack]

Dajcie spokój z tym burdelem, co tu dziwki na forum się ogłaszają czy co?

Ogólnie sprawa z Userem jest bagatela szeroka jak rzeka i głęboka jak morze. Założenia projektowe powinny być takie że sama klasa bazowa User powinna być klasą abstrakcyjną dziedziczącą interfejs w którym byśmy zaimplementowali pewne ograniczenia. Narzuci to rygorystyczne wymagania do klas dziedziczonych, ale tym się nie ma co przejmować bo każda tak czy siak będzie musiała to posiadać. Zmienne, ja Ci dam public, to Cię krew zaleje. O Hermetyzacji Pan słyszał? No to już usłyszał a teraz poczyta. Modułowo obiektowo, nie wiem czy do końca ogarnąłeś temat ocb ale sprawa jest prosta jak budowa cepa, w oop jest jedna zasada: DZIEL I RZĄDŹ. Możesz mieć fabrykę do ogarnięcia klasy usera, taka czysta forma abstrakcji, i bardzo ładnie się nią posłużysz. Kwintesencja modułowego programowania zorientowanego obiektowo.

[marcio]

Dajcie spokój z tym burdelem, co tu dziwki na forum się ogłaszają czy co?

Niekorych botow na forum traktuje nawet gorzej .

Założenia projektowe powinny być takie że sama klasa bazowa User powinna być klasą abstrakcyjną dziedziczącą interfejs w którym byśmy zaimplementowali pewne ograniczenia. Narzuci to rygorystyczne wymagania do klas dziedziczonych, ale tym się nie ma co przejmować bo każda tak czy siak będzie musiała to posiadać

Na php.net czy gdziekolwiem indziej nie ma zadnej reguly na implementacje klasy USER kazdy to robi jak chce,jak mu wygodniej i jak pasuje pod jego system chodz fakt faktem interfejsy czasami sa niezbedne.

Regula wedlug mnie jest to ze w OOP nie wrzuca sie wszystkiego do jednego wora i tyle.
Reszta, implementacja to sprawa kodera nie kazdy framework obsluguje to tak samo, przynajmniej mi sie tak wydaje wiec prosze nie generalizowac.

Pozdro

Ten post edytował marcio 1.02.2010, 23:36:11

[dr4ko]

Wszystko zależy od tego co piszesz. Jeśli to jest jednorazowa robota, piszesz, zgarniasz kasę i zapominasz o sprawie to pisz jak ci się podoba. Ale jeśli aplikacja ma być rozwijana to pisz tak, żeby kod był skalowalny, czyli rozbijaj na moduły i za chiny nie wrzucaj obsługi tworzenia użytkownika do jego klasy.

[Fixus]

Tylko trzymać to np. w jakiejś klasie Profile ?

[marcio]

logowanie - modul:auth,login,signin
rejestracja - modul:register
zarzadznie prifilem - modul:profile
przykladowe nazwy modolow i ich zadanie

Ten post edytował marcio 4.02.2010, 17:55:34