Forum PHP.pl

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 .

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.

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.

Ten post edytował Zyx 21.07.2011, 21:30:14