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:

[PHP] pobierz, plaintext 
<?php
class test {
 static public function get() { return array(); }
}
 
class test2 {
 public function get() { return array(); }
}
 
$s = microtime(true);
for($i=0; $i<=1000; $i++) {
 $x = new test;
 $y = $x->get();
 unset($x, $y);
}
echo "Object: ".round((microtime(true)-$s), 4)." ms<br/>";
 
$s = microtime(true);
for($i=0; $i<=1000; $i++) {
 $y = test2::get();
 unset($y);
}
echo "Static: ".round((microtime(true)-$s), 4)." ms<br/>";
 
/*
 Object: 0.0036 ms
 Static: 0.0037 ms
*/
?>
[PHP] pobierz, plaintext 

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:

[PHP] pobierz, plaintext 
<?php
 class subpage {
  protected $id = NULL;
  protected $validId = false;   
 
  function __construct($id=NULL) {
   if($id > 0 && textOperations::isInt($id)) { //basic validation
    $this->validId = true;
    $this->id = $id;
   } else {
    $this->validId = false;
   }
  }
 
  public static getList() { }
  public function get() { }
  public function delete() { }
  public function save($arrayWithParams) { }
 }
 
 $page = new subpage(134);
 $x = $page->get();
 $page->delete();
 unset($page);
?>
[PHP] pobierz, plaintext 

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:

[PHP] pobierz, plaintext 
<?php
 class subpage {  
  public static getList() { }
  public static function get($id) { }
  public static function delete($id) { }
  public static function save($id, $arrayWithParams) { }
 }
 
 $x = subpage::get(134);
 subpage::delete(134);
?>
[PHP] pobierz, plaintext 

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ź

Masz błąd w teście: statycznie wywołujesz metodę niestatyczną i na odwrót, ale wyniki generalnie masz w miarę OK - wywołanie metod statycznych jest wolniejsze niż niestatycznych. Różnice nie są wprawdzie duże, ale są.

Elementy statyczne w klasach z formalnego punktu widzenia nie mają z programowaniem obiektowym nic wspólnego, ponieważ jak programowaniem obiektowym może być coś, gdzie nie mamy obiektów? Na dobrą sprawę nie wnoszą one zbyt wiele do większości języków programowania. W Javie są one nawet przydatne, ale dlatego, że nie ma tam w ogóle funkcji. W PHP ich zastosowanie ogranicza się wyłącznie do podlegania automatycznemu ładowaniu i modyfikatorom dostępu. Ja od jakiegoś czasu mam bardzo prostą zasadę:

* pól statycznych nie używam w ogóle,
* metody statyczne używam tylko wtedy, gdy naprawdę wiem, co robię i że mi naprawdę jest to potrzebne.

Poza tym wszystko jedzie na obiektach. Jeśli faktycznie cały mechanizm odpalania akcji będzie zgodny z zasadami projektowania obiektowego, to wtedy zauważysz, że Twój ostatni listing to nieporozumienie .

Faktycznie, strzeliłem błąd. Przy poprawnej notacji wyniki (dla 10 tys przejść) są już nieco bardziej sensowne:
Object: 0.0358 ms
Static: 0.0166 ms

Tutaj faktycznie logiczniej jest tworzyć obiekt i ew. zostawiać część metod statycznych. A jeśli chodzi o klasy z wszystkimi statycznymi metodami to wydaje mi się, że ma to sens w wypadku gdy coś jest często używane w dużej ilości miejsc kodu gdzie przekazywanie uchwytu nie daje korzyści a jest upierdliwe (np. klasa do cache).

Tylko teraz co z funkcjami typu getMultiById()? Wtedy jest to operacja niby nie na jednej podstronie a na wielu. Nijak tu nie pasuje podanie do konstruktora array(1,3,55,134) więc dobrze aby metoda sama w sobie przyjmowała listę idków jako argument.

Niestety nie są sensowne. Znalazłem kolejny błąd. Tworzenie obiektu nie jest częścią wywoływania metody - owszem, trzeba to zrobić, ale to robisz RAZ. Dlaczego zatem w pętli wliczasz do wywoływania metody czas tworzenia obiektu?



Nie przekręcaj mojej wypowiedzi. Napisałem jasno, że metody statyczne powinniśmy tworzyć tylko wtedy, gdy wiemy co robimy, co oznacza, że 99% programistów nie powinno używać ich w ogóle. Nie mówię tu o braku umiejętności (chociaż z drugiej strony... ), ale o tym, że ich tak naprawdę w ogóle nie potrzebują. Twój problem akurat wybitnie należy do kategorii problemów, gdzie static nie ma żadnego logicznego uzasadnienia.



To źle Ci się wydaje. Argument "bo jest używane w dużej liczbie miejsc" to brednia do kwadratu, bowiem wtedy musiałbyś w ogóle przestać stosować obiektówkę do większości rzeczy. Co to w ogóle jest "uchwyt do klasy"? Z przykładem z cache też trafiłeś, jak kulą w płot - jest to jeden z fajniejszych tematów do modelowania obiektowego i robiąc tam wszystko statycznie byś go dokumentnie rozwalił.

Ogólnie powiem tak: znasz składnię, wiesz jak działają obiekty, klasy, elementy statyczne. Jednak to, że potrafisz dwie cegły spoić cementem, nie czyni jeszcze z Ciebie architekta. Umiesz używać klas i obiektów, natomiast o programowaniu obiektowym nie masz zielonego pojęcia. Co bym Ci radził na początek, to zostawienie CMS-a i rozpoczęcie od paru ćwiczeń, w trakcie których nie wolno Ci używać słów kluczowych global, static, extends (a i owszem) oraz metod, których nazwy zaczynają się od __, z wyjątkiem __construct() i __destruct(). Ba, powiem nawet więcej: modelując system, powinieneś wręcz zapomnieć o pojęciu klasy, bowiem jak sama nazwa programowanie obiektowe wskazuje, operujemy tu na obiektach i tylko na obiektach, a klasa to jedynie wygodny schemat do tworzenia obiektów o podobnych zadaniach. Co, że restrykcyjne? Nie, 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.

A weź teraz Zyx uzasadnij czemu Kiler129 nie powinien używać extends.
Może jeszcze powiedz jak miał by uczyć się tworzenia klas abstrakcyjnych bez extends.

Czyli kolejna rzecz przewróciłeś mi w głowie
Która metoda jest tutaj w takim razie poprawna:



Co do cytatu to bardziej odnosił się do moich przemyśleń a nie do twojej wypowiedzi
Kiedy więc static ma logiczne uzasadnienie? Cache wydaje mi się tutaj dobrym przykładem bo używam w dużej liczbie miejsc niepowiązanych ze sobą np. core_cache::get("news", 13); - php inicjuje sobie w środku jedną kopie i ja mam z głowy dbanie jak się do niej odwołać (nie muszę mieć czegoś w stylu $GLOBALS["cacheObj"] = new core_cache;)

Jeśli chodzi o moją znajomość obiektówki to się z tobą w 100% zgadzam: wiem jak co działa ale już żeby to logicznie zaprojektować to z tym gorzej. 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).

Czy mógłbyś naświetlić mi jak powinna (oczywiście szablonowo) wyglądać klasa obsługująca dostęp do newsów czy to podstron uwzględniając to, że można pobrać ich kilka na raz?

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

A czemu, przecież napisałem:



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ż . 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.



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.

Zyx, on powinien ćwiczyć korzystanie z extends właśnie po to by wiedzieć kiedy, czy i jak z niego korzystać.
Niech się bawi w klasy np. rodzic auto i dzieci fiat, matiz.
Niech wie że matiz nie dziedziczy po db mysql itp.

Spawnm... rodzic "auto" i dzieci "fiat, matiz"... to jest przecież jeden ze sztandarowych przykładów, jak się z dziedziczenia nie powinno korzystać. Właśnie perfekcyjnie teraz widać, jak to się ludzie uczą, kiedy "extends" wykorzystywać, pakując je wszędzie, gdzie się da. I co, jak będziesz chciał dodać kolejną markę, to będziesz nową klasę pisał oraz przebudowywał całą aplikację? I co, jak do "auta" dodasz jakąś nową funkcjonalność, będziesz wszystkie klasy pochodne przerabiał i od nowa testował, by się upewnić, że wszystko jest OK? I co, później zrobisz na bazie tych klas aplikację do zarządzania typami aut i w momencie gdy użytkownik zauważy, że przypadkiem zły typ ustawił, odpowiesz mu "sorry, nie możesz teraz tego zmienić, bo ja już utworzyłem obiekt"? To się załatwia, robiąc obiekty klasy "Pojazd" trzymające referencje do obiektów klasy "TypPojazdu".

"[...] jak się z dziedziczenia nie powinno korzystać."
A ja uważam, że powinien używać extends jeśli chce zobaczyć na czym polega obiektowość. Nauka polega na tym, że popełnia się błędy i wyciąga z nich wnioski. Po za tym nie można nigdy polegać na tym co powie Ci ktoś kto ma doświadczenie - bo różni programiści mają bardzo różne doświadczenia. Jeśli ktoś chce być świadomy to musi przejść przez etap - używania i odrzucania lub też nie. Wtedy kształtuje się własne zdanie, a samo doświadczenie jest bogatsze. Używanie extends jest to temat rzeka, i nigdy nie wiadomo gdzie się przyda, a gdzie będzie zbyteczne, o tym decyduje charakter pisanej aplikacji i problem, który rozwiązujemy, a często również nasze "widzi mi się" czyli to jak patrzymy na nasze własne prywatne i skromne rozwiązanie problemu.

Jeśli to co robię w kodzie jest poparte paroma argumentami Za, i jednym przeciw - to z reguły używam tego rozwiązania. Czasami łatwiej jest użyć extends i zaoszczędzić czas niż stracić czas i odrazu super uelastycznić aplikację. Początkowa wersja programu wg. mnie nie powinna mieć super architektury, bo ciężko jest określić w jakim kierunku pójdą zmiany. A tworzenie od samego początku super super architektury może w pewnych przypadkach być wadą aplikacji.

Zyx:: i w tym momencie zabiłeś mi ćwieka patrząc na kod Zenda i na to co napisałeś dostałem małego zawrotu głowy. Hmm, może jak znajdziesz chwile wolnego czasu mógłbyś przedstawić na jakimś prostym przykładzie kiedy należy używać dziedziczenia?

ps. powinieneś założyć bloga i pisać w nim artykuły na takie tematy