podział zadań na między klasy... Opcje

[rmn]

Robie zorientowana obiektowo galerie. Poszczegolne zdjecia sa reprezentowane przez obiekty klasy Foto.I teraz mam pytanie: Czy funkcje takie Register(zarejstruj w bazie), Show(wysiwetl sformatowane info o zdjeciu) powinny byc metodami klasy foto, czy metodami klasy Galeria przyjmujacymi jako argument obiekt klasy Foto?

[rzseattle]

Nik nie odpowie na to pytanie jednoznacznie. To kwestia indywidualnego podejscia programisty. Przy projektowaniu obiektowym nie raz spotkasz dzialania ktore pasuja do kilku obiektow jednoczesnie. Czasem jest to blad w projektowaniu struktury a czasem pierdola z ktora nie idzie sie uporac. Jesli chodzi o moje zdanie to mysle ze klasa foto powinna dziedziczyc po klasie galery bo przeciez logicznie rozumujac galeria jest rodzicem dla zdjecia. W ten sposob to co sie tyczy galeri bedzie dotyczylo kazdego zdjecia w niej zawartego.

[Seth]

Ja bym do tego poszedl w ten spsob (na przykladzie dwoch klas):
Klasy:
- Picture - klasa zawierajaca dane o obrazku - reprezentujaca obrazek
Wlasciwosci wysokosc, szerokosc, sciezka do pliku itp.
Metody: get - do pobierania zdjecia, update - do ukatualnienia, delete - do usniecia zdjecia itp
- PictureList - lista obrazkow
Metody: pobieranie listy z danej kategorii ew wszyskich, sortowanie, updateowanie, usuwanie elementow, usuwanie wszytkich elementow itp.

Wyswietlanie danych nie powinno znajdowac sie w tych klasach. Powinny byc do tego inne klasy/funkcje, ktore beda odpowiedzialne za pobieranie elementow i na bazie zawartych w nich danych formatowaly output.

Mozna do tego podejsc tez w ten spsoob, ze klasy Picture, PictureList beda tylko miejscami przechowywania danych bez metod operujacych na danych przechowywanych w bazie - do tego sluzyly by inne klasy.

[rmn]

Seth:

Mozna do tego podejsc tez w ten spsoob, ze klasy Picture, PictureList beda tylko miejscami przechowywania danych bez metod operujacych na danych przechowywanych w bazie - do tego sluzyly by inne klasy.

Ale wtedy klasy przestaną byc klasami? Stana się zwyklymi 'strukturami'?

Napisze wiecej jak będa tylko miał chwilę czasu. Dzięki za odpowiedzi. Postram się dzisiaj zaprojektować klasy według Wszych wskazówek i dalsza dyskusje będziemy prowadzili juz na nich(klasach). Myśle, że tak bedzie Nam łatwiej się zrozumiec:)

pozdrawiam.

[Seth]

Seth:

Mozna do tego podejsc tez w ten spsoob, ze klasy Picture, PictureList beda tylko miejscami przechowywania danych bez metod operujacych na danych przechowywanych w bazie - do tego sluzyly by inne klasy.

Ale wtedy klasy przestaną byc klasami? Stana się zwyklymi 'strukturami'?

Nie koniecznie gdyz klasa taka zawierala by tylko metody odpowiedzialne za pobieranie danych bez mozliwosci zapisywania danych czy tez ich zmiany. Czyli cos w rodzaju DataSetu (chyba tak to sie nazywalo) - klas potrzebnych min dla widoku strony.

No ale zobaczymy jak to Ty wykombinujesz

[rmn]

Więc mój pomysł jest taki:
class Engine
|-class Output //klasa zajmujaca sie 'wyswietlaniem' innych klas
|-class Galery//klasa modulu galerii
|---Register,Update,Delete,GetList (wszystkie pracuja na obiektach klasy -Foto)
|---class Foto//klasa ma konstruktor,który ja 'wypelnia' danymi

rzseattle
Nie rozumiem czemu klasa Foto ma dziedziczyć po klasie Galery. Przecież te obiekty zajmują sie czymś zupełnie innym. Instancje klasy foto, powinne być inicjowane przez klasę galery, ale przeiceż klasie foto niepotrebne sa takie metody jak Register czy Update. Ta klasa reprezentuje zdjecie (obrazek) więc nie powinna posidać możliwości rejestracji, tego zdjecia nie robia;)? Wlasnie rejestracja, i generalnie zarzadaniem zajmuje sie klasa galery?

[lolek09]

Dobra, jest siódma rano. Podobno o tej porze mózg najllepiej funkcjonuje (nie u każdego ). No w każdym razie doszedłem do wniosku, że walidacja użytkownika i przetwarzanie danych POST GET COOKIE itp. powinna mieć miejsce poza obiektem galeria, obiekt galeria w momencie tworzenia powinien znać użytkownika który z niej aktualnie korzysta i jego uprawnienia co do samej siebie powinna sama sprawdzać.
Miałbym więc następującą hierarchię:

Kod

+Root (wywoływanie odpowiednich klas na podstawie tego co zwróci Input)

+-Input (przetwarzanie POST, GET itp)

+-User (zarządza profilem, sprawdza użytkownika)

+-Gallery (Wszystko co się wiąże z galerią, administracja itp.)

+--Output (Wyświetlanie danych)

+--Album (Sortowanie zdjęć itp.)

+---Photo (Skalowanie, zmiany opisów itp.)

Jedyne czego nie jestem pewien, to umieszczenie klasy Output w galerii. Ale każdy dział będzie miał własną klasę z własnymi metodami od wyświetlania. To chyba słuszne?

[Pianandrill]

To ja jeszcze dorzucam pytanki.
Jeżeli mam klasę galeria (załóżmy, bo chodzi mi o cos jeszcze innego) ktora zajmuje sie wybieraniem z bd listy obrazków (załóżmy ze chodzi o podzial na stronki danej galerii), sortowaniem, zliczaniem, i innymi bardziej ogólnymi rzeczami... i
mamy klasę foto (obrazek) która zajmuje sie wyciąganiem z bd danych konkretnrgo obrazka i przedstawianiem ich na stronie, dodawaniem nowych zdjęć, edycją, usuwaniem... itp

Chodzi mi teraz o aspekt wydajnościowy.
klasa galeria odwołuje sie do bd pobierając id elementów na danej stronie (start, limit). Czy jest sens aby ta klasa wywoływała instancje klasy foto dla każdego zdjęcia/obrazka na stronie (powiedzmy w jakiejs tam pętli) a obiekt foto za kazdym razem odwoływał sie do bd z zapytaniem o dane konkretnego obrazka/zdjęcia?

Jak to zrobić sensownie... czym powinien sie zajmować obiekt typu lista (spis elementów) a czym obiekt element (konkretny element zbioru) ?