Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Usuwanie podstrony/innej treści, Jak to wykonać zgodnie z obiektowością?
kiler129
post
Post #1





Grupa: Zarejestrowani
Postów: 566
Pomógł: 35
Dołączył: 21.06.2006

Ostrzeżenie: (0%)
-----


Witajcie!
Krótko i na temat - postanowiłem z lekka uporządkować kod swojego CMSu i uczynić go bardziej obiektowym. W związku z tym sprawdziłem jaki wpływa na prędkość ma zbudowanie obiektu i wykonanie metody kontra wykonanie metody statycznej, wyniki z lekka mnie zaskoczyły:
  1. <?php
  2. class test {
  3. static public function get() { return array(); }
  4. }
  5.  
  6. class test2 {
  7. public function get() { return array(); }
  8. }
  9.  
  10. $s = microtime(true);
  11. for($i=0; $i<=1000; $i++) {
  12. $x = new test;
  13. $y = $x->get();
  14. unset($x, $y);
  15. }
  16. echo "Object: ".round((microtime(true)-$s), 4)." ms<br/>";
  17.  
  18. $s = microtime(true);
  19. for($i=0; $i<=1000; $i++) {
  20. $y = test2::get();
  21. unset($y);
  22. }
  23. echo "Static: ".round((microtime(true)-$s), 4)." ms<br/>";
  24.  
  25. /*
  26.  Object: 0.0036 ms
  27.  Static: 0.0037 ms
  28. */
  29. ?>


Różnica praktycznie żadna a wg teorii OOP wykonujemy akcję na danym obiekcie więc chyba najsensowniejszym podejściem jest taka organizacja obsługi podstron:
  1. <?php
  2. class subpage {
  3. protected $id = NULL;
  4. protected $validId = false;
  5.  
  6. function __construct($id=NULL) {
  7. if($id > 0 && textOperations::isInt($id)) { //basic validation
  8. $this->validId = true;
  9. $this->id = $id;
  10. } else {
  11. $this->validId = false;
  12. }
  13. }
  14.  
  15. public static getList() { }
  16. public function get() { }
  17. public function delete() { }
  18. public function save($arrayWithParams) { }
  19. }
  20.  
  21. $page = new subpage(134);
  22. $x = $page->get();
  23. $page->delete();
  24. unset($page);
  25. ?>


Jedna z metod (akurat w tym przykładzie) jest niezależna od id podstrony bo defakto odnosi się nie do jednej a do listy podstron.
Zastanawia mnie natomiast jedna kwestia - czy obiektowo poprawnie będzie rozwiązać to tak:
  1. <?php
  2. class subpage {
  3. public static getList() { }
  4. public static function get($id) { }
  5. public static function delete($id) { }
  6. public static function save($id, $arrayWithParams) { }
  7. }
  8.  
  9. $x = subpage::get(134);
  10. subpage::delete(134);
  11. ?>


Druga metoda jest wygodniejsza w użyciu, prędkością się nie różni ale nie wiem czy jest to do końca poprawne.
Z góry dzięki za odpowiedź (IMG:style_emoticons/default/smile.gif)
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi
Zyx
post
Post #2





Grupa: Zarejestrowani
Postów: 952
Pomógł: 154
Dołączył: 20.01.2007
Skąd: /dev/oracle

Ostrzeżenie: (0%)
-----


Tobie też by się takie ćwiczenie przydało, skoro napisałeś taki post (IMG:style_emoticons/default/smile.gif) . W jednym masz rację: słowo abstract też powinno znaleźć się na liście słów zakazanych, bo bez extends nie ma sensu (IMG:style_emoticons/default/smile.gif) .

A czemu, przecież napisałem:

Cytat
(...) to jest istota programowania obiektowego ogołocona ze wszystkich ogłupiaczy. Dopiero gdy się tego nauczysz, będziesz wiedział, że cała reszta to zwykły lukier składniowy i pomoc, która jednak jest pomocą tylko wtedy, gdy znajduje się w doświadczonych rękach.


Programowanie obiektowe to nie są klasy abstrakcyjne, static czy extends. To sposób myślenia i projektowania. Dopóki ktoś się go nie nauczy, będzie jedynie programistą, który umie używać klas oraz dziedziczenia i nic poza tym. Klasy abstrakcyjne, dziedziczenie i cała reszta to jedynie narzędzia i lukier składniowy. OK, dziedziczenie nie do końca się do tego zalicza, ale akurat jest jedną z bardziej zwodniczych koncepcji. Naucz się najpierw dobrze podstaw, a później siadaj za pulpitem sterowniczym elektrowni jądrowej.

--- [odpowiedź dla kilera] ----

Który sposób będzie tam poprawny? Nie ma na to pytanie jednej odpowiedzi, może poza tym, że ID to ja bym jako argument przekazywał, jeśli już (IMG:style_emoticons/default/smile.gif) . Zapytasz się mnie, co w sytuacji, gdy identyfikacja wiersza wymaga większej liczby pól, a ja Ci odpowiem: niech argument z identyfikatorem będzie obiektem implementującym interfejs Identifier. Wtedy sobie zaimplementujesz różne typy identyfikatorów, jakie masz w aplikacji i będziesz mógł nimi operować w sposób uniwersalny. To jest właśnie przykład obiektowego podejścia.

A dlaczego żadnemu z Twoich sposobów nie można nadać etykietki "poprawny"/"niepoprawny"? Ponieważ tutaj to już tak naprawdę zależy od tego, co chcesz zrobić i co te Twoje obiekty mają reprezentować. Metoda #2 to zwykłe mapowanie obiektowo-relacyjne, gdzie obiekty reprezentują jeden wiersz w bazie. Jest to popularne, zwłaszcza w zastosowaniach typu CRUD, natomiast do bardziej zaawansowanych rzeczy ja preferuję metodę #1 ze wspomnianą już modyfikacją, ponieważ jest ona bardziej ogólna i mniej przekombinowana w przypadku złożonych schematów.

Co do przykładu z cache, to wyjaśnij mi, czym to, co zrobiłeś, różni się od wywołania funkcji np. apc_get(), albo zwykłego wstawienia global? Ja Ci już podpowiem prawidłową odpowiedź, że absolutnie niczym. Przede wszystkim kto powiedział, że potrzebujesz dokładnie jeden obiekt cache'u? Pomyśl. Cache'ujemy różne rodzaje danych, różne rodzaje danych mają różne wymagania (cykliczne aktualizacje, aktualizacje na żądanie, dłuższe, krótsze itp. itd.)? Wprowadzasz tu pojęcie zasobu (np. "konfiguracja", "dane", "kod HTML"), polityki (czyli jakiej funkcjonalności oczekujesz od cache'u) oraz strategii (czyli już konkretna implementacja). Politykę kodujesz jako interfejs, strategię jako klasę implementującą ten interfejs, a zasób jako pytanie do menedżera obiektów strategii "panie, podaj mi tu obiekt, który potrafi cache'ować zasób z rodziny 'konfiguracja'". Dostajesz obiekt, upewniasz się co do obsługiwanej przez niego polityki, robisz operacje i po sprawie. Chcesz zmienić strategię dla konkretnego zasobu, w menedżerze rejestrujesz dla niego inną strategię i tyle.

Cytat
Problem jest jednak taki, że nie mam za bardzo czasu na dokładne teoretyczne studiowanie tego tylko uczę się przy okazji stałego rozwijania CMSu (który bądź co bądź na mnie zarabia poniekąd).


Dlatego radzę Ci, byś zostawił tego CMS-a w takim kształcie, jak on jest (ew. nie bawił się tu na razie w obiektówkę), a zaoszczędzony czas poświęcił na jakieś prostsze ćwiczenia. Szkoda marnować i wspomniany czas, i CMS-a nieudolną przebudową. CMS Ci nie ucieknie, a dzięki temu później zrobisz go lepiej i szybciej. Ja np. bardzo żałuję, że w czasach, gdy miałem swoje pierwsze próby z klasami (11 lat temu), nie było nikogo, kto by mi powiedział to, co napisałem teraz Tobie, przez co mnóstwo mojej pracy poszło na marne.

Ten post edytował Zyx 21.07.2011, 21:30:14
Go to the top of the page
+Quote Post

Posty w temacie


Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 5.10.2025 - 07:36