Jakie metody w klasie News - jak ma to współgrać? Opcje

[Joachim Peters]

Witam,

jestem po lekturze naprawdę wielu tematów na tym forum, w okręg moich zainteresowań weszła także książka "PHP5 Obiekty, wzorce, narzędzia".
Mimo to mam problem co do ułożenia odpowiedniej klasy. Moje problemy:

1. Czy w klasie np. do obsługi newsów powinna znajdować się metoda do wyświetlania konkretnego newsa/newsów jeżeli nie stosuje ścisłego MVC (chce napisać stronę zintegrowaną z innym skryptem od którego będę używał kilka klas i funkcji, m.in. do wyświetlania w przeglądarce html)? Jeżeli nie to powinienem zrobić dla niej osobną funkcję (bez klasy)?

2. Idąc dalej przykładem klasy do obsługi newsów chciałbym zapytać czy lepiej definiować ID newsa już w konstruktorze czy ustalać go manualnie przez metodę np. setId()?

3. Czy opłaca się stworzyć osobną metodę do dodawania elementów do tablicy z danymi newsa (np. addParam($key, $value), czy wyjdzie na to samo (w sensie obiektowym) przekazując pełną tablicę prosto do metody np. update()?

Poniżej zarys klasy:

[PHP] pobierz, plaintext 
<?php
class News {
	private $newsId	 = 0;
	private $params		= array();
 
	public function setId($id) { } // Ustawia id newsa na którym chcemy operować
	public function submit() { } // Jeżeli newsId > 0 to aktualizuje, jeśli odwrotnie to tworzy nowy rekord
	private function insert() { }
	private function update() { }
	public function delete() { }
	public function addParam($key, $value) { } // Dodaje parametry typu nazwa newsa, autor, treść, źródło do tablicy danych
	public function print() { } // Wyświetla newsa, jeżeli ustaliliśmy Id do wyświetla wybrany news, jeżeli nie to
 wszystkie
	private function printSpecific() { } 
	private function printAll($perPage) { }
}
?>
[PHP] pobierz, plaintext 

Jest tu sens OOP? Co zmienić aby było lepiej?

Pozdrawiam i z góry serdecznie dziękuje za wyjaśnienia!

[LBO]

Generalnie to zależy od ciebie, ale jeżeli obiekt News reprezentuję jednego newsa to nie widzę zastrzeżeń, żeby było to w konstruktorze - będzie bardziej czytelnie.

[PHP] pobierz, plaintext 
<?php
$news = new News($id); // wygląda przystępniej niż..
 
$news = news News();
$news->setId($id); // .. to, praawda?
 
// Ewentualnie możesz postawić na czytelność metod...
 
$news = news News();
$news->getById($id); // identyczne jak w drugim przykładzie, ale czytelniejsze.
 
// .. a nawet tak
 
$news_2 = News::getById(2); // metoda statyczna, zwraca obiekt News
 
// czy
 
$news = News::getAllByPage($page, $per_page); // zwraca tablicę obiektów News, które zostały wypełnione danymi zewnętrznie
?>
[PHP] pobierz, plaintext 

Możesz nawet stosować hybrydy, czyli jeżeli sam tworzysz News to $id w konstruktorze ( i tam wyciągasz dane z bazy), a jak chcesz kilka to tworzysz metodę, która zwraca tobie tablicę obiektów News (ale nie wywołujesz ich tam, przez $id w konstruktorze, tylko wyciągasz dane jednym zapytaniem w tej metodzie i "manualnie" te obiekty wypełniasz).

[terabit]

@LBO
takie pytanko

czy jest jakas roznica miedzy

$news = news News();
$news->getById($id); // identyczne jak w drugim przykładzie, ale czytelniejsze.

a tym

$news_2 = News::getById(2); // metoda statyczna, zwraca obiekt News

czy po prostu jak kto woli

[LBO]

Jest różnica, bo w metodach statycznych opakowujesz Managera. Kod jest bardziej przejrzysty jak dla mnie.
To są niewielkie różnice w wydajności, ale do tych operacji, które nie są związane z żadną konkretną instancją, lepiej zaprząc statyczną część klasy.

[Sedziwoj]

Ogólnie chyba

[PHP] pobierz, plaintext 
<?php
$news_2 = NewsPeer::getById(2);
?>
[PHP] pobierz, plaintext 

wykorzystanie DAO i AR ;] Czy jakoś tak to szło, mi się zawsze pojęcia mieszają.

[Black-Berry]

Po co te klasy statyczne? Mi się na przykąłd cały kod strony ze strukturą, kategoriami i jakimś tam menu generuje w 50ms. Dojdę moze do 100ms ale to i tak nic nie zmienia bo złożoność obliczeniowa zawsze będzie rzędu On czyli liniowa. Co one własciwie dają ? (w sensie wydajnościowym)

Ten post edytował Black-Berry 1.09.2008, 23:50:30

[Sedziwoj]

@Black-Berry
A co daje podejście obiektowe, przecież to też jest gorsze wydajnościowo niż strukturalny kod ;]
Zwiększa czytelność i elastyczność kodu, zasada że klasy i ich obiekty mają jedno konkretne zadanie, po to się rozbija na funkcjonalność. Klasa News ma się zając konkretną aktualnością, nie obchodzi jej skąd się wzięła, czy jest częścią większego zbiory.

[LBO]

Ogólnie chyba

[PHP] pobierz, plaintext 
<?php
$news_2 = NewsPeer::getById(2);
?>
[PHP] pobierz, plaintext 

wykorzystanie DAO i AR ;] Czy jakoś tak to szło, mi się zawsze pojęcia mieszają.

Można i tak (Propel-way), ale czy przy tak niewielkim zastosowaniu trzeba rozbijać to na dwie klasy na tabelę?

Po co te klasy statyczne? Mi się na przykąłd cały kod strony ze strukturą, kategoriami i jakimś tam menu generuje w 50ms. Dojdę moze do 100ms ale to i tak nic nie zmienia bo złożoność obliczeniowa zawsze będzie rzędu On czyli liniowa. Co one własciwie dają ? (w sensie wydajnościowym)

Może nie dają nic, ale są bardziej czytelne? Po co tworzyć obiekt, skoro taki manager (jaki reprezentują metody statyczne) jest bezstanowy.

[Sedziwoj]

Można i tak (Propel-way), ale czy przy tak niewielkim zastosowaniu trzeba rozbijać to na dwie klasy na tabelę?

To był przykład, jak masz metody pobierające np. najnowsze News'y losowe, czy jakiekolwiek zbiory, to umieszczasz to tam, masz w jednym miejscu wszystkie metody pobierania News'ów, dzięki temu, jak jest wymagana poprawka, zmiana funkcjonalności, masz jedno miejsce do edycji (albo dobry punkt zaczepienia, przy większych zmianach). Czyli taki Peer operuje ogólnie na News'ach, a obiekty klasy News na konkretnym elemencie, i tam masz metody np. do pobierania autora, czy co tam będzie potrzebne, przy operowaniu na konkretnej News'ie.

P.S. Hibernate ma jeszcze bardziej to rozbite.

[Black-Berry]

@Black-Berry
A co daje podejście obiektowe, przecież to też jest gorsze wydajnościowo niż strukturalny kod ;]
Zwiększa czytelność i elastyczność kodu, zasada że klasy i ich obiekty mają jedno konkretne zadanie, po to się rozbija na funkcjonalność. Klasa News ma się zając konkretną aktualnością, nie obchodzi jej skąd się wzięła, czy jest częścią większego zbiory.

Chodziło mi o coś wręcz przeciwnego. Myślałem, że LBO pije do tego ze klasy statyczne są szybsze. Wogóle to mam mętlik straszny bo każdy mówi co innego: jedni ze singletny są złe, inni ze rejestry, jeszcze inni ze nie wolno używać globalsów... Pooli dochodze do wniosku że nikt ni ma racji, a liczy się tylko wygoda. Zresztą jak ma być 1 obiekt z danej klasy tylko to trzeba napisać to w komentarzach A jak ktoś jest na tyle głupi żeby tworzyć 2 klasy dbDriver to już jego problem Od dzisiaj tylko czyste obiekty bez żadnych udziwnień singletonami i klasami statycznymi stosuję... Od jutra bo dzis juz idę w kimę... sory za odejście od tematu poprostu musiałem się wyżalić Pozdrawiam wszystkich.

[LBO]

Heeh, ja to wiem. Pytam się czy takie rozbicie jest konieczne? Jak sam mówisz Hibernate ma jeszcze większy poziom decouple'ingu niż Propel - czy to znaczy, że Propel ma się stać jeszcze bardziej skomplikowany, bo trzeba naśladować Hibernate (abstrachując od związku z Torque )?

/ciach/ Wogóle to mam mętlik straszny bo każdy mówi co innego: jedni ze singletny są złe, inni ze rejestry, jeszcze inni ze nie wolno używać globalsów...

Maja rację

Pooli dochodze do wniosku że nikt ni ma racji, a liczy się tylko wygoda.

Też, ale nieraz ważniejszy jest porządek w kodzie. Można sobie nieźle nabruździć z takim czysto-praktycznym podejściem.

Zresztą jak ma być 1 obiekt z danej klasy tylko to trzeba napisać to w komentarzach A jak ktoś jest na tyle głupi żeby tworzyć 2 klasy dbDriver to już jego problem Od dzisiaj tylko czyste obiekty bez żadnych udziwnień singletonami i klasami statycznymi stosuję... Od jutra bo dzis juz idę w kimę... sory za odejście od tematu poprostu musiałem się wyżalić Pozdrawiam wszystkich.

Bo chyba nie do końca rozumiesz pojęcie Singletonu mam wrażenie. Singleton nie jest tożsamy z dokładnie jednym obiektem danej klasy.

[Cysiaczek]

Globalsów się nie używa... bo nie
Singletona się używa ostrożnie - w uzasadnionych przypadkach (np. obiekt kontrolujący bazę danych)
Rejestru się używa i jest on dobrym wzorcem - trzeba mieć niepokolei w głowie, żeby twierdzić inaczej
Klasy statyczne stosuje się tam, gdzie trzeba (co już powiedzieli moim przedmówcy) i nie jest to żadne udziwnienie

Masz mętlik w głowie? Świetnie, powtarzaj mantrę "wszystko zależy od okoliczności, wszystko zależy od okoliczności, wszystko zależy od okoliczności" - codziennie przez godzinę

Pozdrawiam.

[Sedziwoj]

Globalsów się nie używa... bo nie

Zgodzę się

Singletona się używa ostrożnie - w uzasadnionych przypadkach (np. obiekt kontrolujący bazę danych)

Nie zgodzę się, a co jak chcesz mieć parę różnych połączeń w jednej chwili? Już miałem przyjemność z singletonem, więc musiałem napisać okropny kod, bo nie było czasu na przerobienie tej konstrukcji. (Propel jak wiesz pozwala na wiele połączeń, mimo że jak się używa jednego,to jest to nie zauważalne)

Rejestru się używa i jest on dobrym wzorcem - trzeba mieć niepokolei w głowie, żeby twierdzić inaczej

Czy takim dobrym, to bym nie był pewien, ale na pewno lepszy niż Globals

Masz mętlik w głowie? Świetnie, powtarzaj mantrę "wszystko zależy od okoliczności, wszystko zależy od okoliczności, wszystko zależy od okoliczności" - codziennie przez godzinę

Tylko wątpię aby to pomogło ;]
@Black-Berry
Dwie rzeczy, doświadczenie (praktyka) z różnymi rozwiązaniami, powie Ci co jest lepsze. Bo to jest lepsze, co potem pozwala Ci szybciej i wygodniej pracować. Ponieważ te wszystkie rzeczy, OOP, Design Patterns itd. są po to, aby w przyszłości korzystanie z tak napisanych elementów było łatwo korzystać, i jak już trzeba coś dodać/zmienić, aby to była chwila.
Ale to nie jest tak, że jest jedno poprawne rozwiązanie, każdy programista ma swoje preferencje i stąd wynikają te różnice, ale do ogólnych spraw raczej większość jest zgodna.
Niestety, tylko doświadczenie w pisaniu i korzystaniu z różnych rozwiązań da Ci pewną pewność jak to rozwiązać... Więc czytaj, korzystaj, pisz i analizuj, jak się sprawują jakieś rozwiązania, próbuj różnych, ogólnie polecamy Propel, Synfony (może jeszcze parę) dla tego, że są przyzwoicie napisane, jak będziesz z nich korzystać, to zobaczysz że jest to wygodne i będziesz mógł podejrzeć jak inni to robią.

[Black-Berry]

@Sedziwoj Z tego co mówisz pośrednio wynika, że najlepiej przekazywać wszystko jawnie w konstruktorze bo moze się okazać, że chcesz np mieć osobne połaczenie z bazą dla przykładowego newsMenager'a. Idąc dalej tym tropem dobrze by było nie przekazywać za każdym razem 15 obiektów tylko już lepiej wrzucić wszystko do rejestru i przekazywać tylko jeden obiekt rejestru. Obiekt główny po którym dziedziczy każdy inny już sobie poustawia odpowiednie pola... Ale zauważ że w ten sposób tuszujesz tylko globalność niektórych obiektów.

No i moje dalsze rozumowanie: Po co tuszować? Nie lepiej w konstruktorze obiektu głównego i tylko w nim użyć słówka kluczowego global aby przypisać globalne obiekty do pól dziedziczących? Wtedy już nic nie musze przekazywać w konstruktorach, no i nie chowam śmieci pod dywan za pomocą rejestru

Ten post edytował Black-Berry 2.09.2008, 10:27:11

[Sedziwoj]

No i moje dalsze rozumowanie: Po co tuszować? Nie lepiej w konstruktorze obiektu głównego i tylko w nim użyć słówka kluczowego global aby przypisać globalne obiekty do pól dziedziczących? Wtedy już nic nie musze przekazywać w konstruktorach, no i nie chowam śmieci pod dywan za pomocą rejestru

W lesie masz rozrzucone kuleczki, teraz je znajdź trudne, co nie?
A wyobraź sobie że masz teraz do każdej przywiązaną nitkę, tak że zbiegają się wszystkie w Twoich dłoniach, o wiele łatwiej znaleźć?

Ogólnie zaplanowanie tak aplikacji, aby mieć zawsze dostęp do rzeczy potrzebnych w danym miejscu i nie robić tego na około, to jest trudne zagadnienie.

[Cysiaczek]

Dlaczego tak wszyscy nie lubią Registry? Przecież jest to wzorzec, który stosowany umiejętnie rozwiązuje np. problem BlackBerrego z 15 obiektami, które chce przekazać.
Inicjujesz rejestr, dodajesz do niego obiekty kojarząc je w kolekcje, potem tylko do konstruktora leci konkretna kolekcja - jako jeden parametr. Konstruktor sobie to rozpakowuje i voila!

Taki rejestr może kojarzyć obiekty na podstawie implementowanych interfejsów, co jest kolejnym przykładem ich zastosowania. Omijasz wówczas jawne przypisywanie do kolekcji.

Pozdrawiam.

[Black-Berry]

W lesie masz rozrzucone kuleczki, teraz je znajdź trudne, co nie?
A wyobraź sobie że masz teraz do każdej przywiązaną nitkę, tak że zbiegają się wszystkie w Twoich dłoniach, o wiele łatwiej znaleźć?

Chyba mnie właśnie nawróciłeś

Inicjujesz rejestr, dodajesz do niego obiekty kojarząc je w kolekcje, potem tylko do konstruktora leci konkretna kolekcja - jako jeden parametr. Konstruktor sobie to rozpakowuje i voila!
Taki rejestr może kojarzyć obiekty na podstawie implementowanych interfejsów, co jest kolejnym przykładem ich zastosowania. Omijasz wówczas jawne przypisywanie do kolekcji.

Można prosić o jakiś manual do poczytania? O co chodzi z tymi kolekcjami? Chodzi tylko o grupowanie w logikę czy to ma też względy wydajnościowe jeśli nie przekazuję całego rejestru?

Ten post edytował Black-Berry 2.09.2008, 10:46:26

[Sedziwoj]

@Cysiaczek
Bo taki Registry, wydaje mi się niedaleko od wzorca Singleton ;]
Po prostu, jak nie wiem jak coś zrobić go wykorzystam...
Ale to jest jałowa dyskusja, bo wydaje mi się że na razie do kompromisu się nie dojdzie. Nie mówię że stosowanie Registry jest złe, po prostu mi się on bardzo nie podoba.

[Black-Berry]

@Cysiaczek
Bo taki Registry, wydaje mi się niedaleko od wzorca Singleton ;]
Po prostu, jak nie wiem jak coś zrobić go wykorzystam...
Ale to jest jałowa dyskusja, bo wydaje mi się że na razie do kompromisu się nie dojdzie. Nie mówię że stosowanie Registry jest złe, po prostu mi się on bardzo nie podoba.

Co w takim razie robisz z obiektami globalnymi?

[Sedziwoj]

Co w takim razie robisz z obiektami globalnymi?

Jedna sprawa to skorzystać z np. generatora miniaturek, który po prostu ma zrobić swoje, a inna sprawa to korzystanie z dostępu do np. bazy danych które gdzieś jest inicjalizowane, czy danych z GET/POST/itd. które mają być dostępne w akcjach. Po prostu większość rzeczy da się przekazać do obiektu w jakiś inny sposób, np. wykorzystując warstwę abstrakcji, Registry jest o tyle brzydki że trzeba wiedzieć co w nim jest.