Witam,

chciałbym poznać waszą opinię na temat superklas. Ponieważ ostatnio babrałem się w IPB zauważyłem, że wykorzystuje on taką klasę gdzie można było znaleźć praktycznie wszystko. Stąd moje pytanie [czysto retoryczne]- czy warto pakować się w superklasy?

ps. dla jasności dodam, że chciałbym wykorzystać takową klasę przy tworzeniu panelu admina [coś na wzór grida]

Pozdrawiam

Superklasa to nie jest "klasa do wszystkiego", ale zwykła klasa rodzica przy dziedziczeniu. I nie wiem, co tu jest do dyskutowania. Klasy do wszystkiego to zło, a dziedziczenie to normalny mechanizm, którego wystarczy używać z rozwagą i tyle.

Chodzi Ci dokładnie o superklasę do wszystkiego czy superklasę mającą wszystko ? Widziałem podejście gdzie jedna wielka klasa obsługiwała bazę danych, użytkownika, newsy itp...
Autorowi grzecznie napisałem że to co robi to programowanie funkcyjne czy jak to tam nazwać. Wystarczyło usunąć sprzed nazw metod nazwy obiektów ($obj->metoda() zamienic na metoda()), potem z klasy wywalić class ... { i public, private itp i masz... zestaw funkcji. Więc jak widzisz, podejście głupie, bezsensowne i nie mające nic wspólnego z OOP.

Co innego klasa mająca wszystko. W rozbudowanym systemie na ogół mamy tzw rdzeń i całą resztę która go otacza. Poszczególne możliwości są rozbite na moduły. Ale... obsługa sesji, uwierzytelnianie, obsługa bazy danych, obsługa formularzy i inne standardowe akcje systemu są wykorzystywane przez moduły i ogólnie przez wszystko co ten rdzeń otacza. Więc wygodnym sposobem jest zrobić klasę takiego rdzenia systemu gdzie masz dostęp do jego mechanizmów.
Tylko że taki rdzeń nie jest klasą od wszystkiego tylko zbiorem klas wykonujących różne rzeczy w tym systemie.

Jak określić co powinno się znaleźć w takim "rdzeniu" ? Nic prostszego. Zbierz wszystkie elementy systemu które są stałe i które nie będą wymagać modyfikacji dla poszczególnych modułów dla przykładu. Są to najczęściej takie mechanizmy jak obsługa sesji, bazy danych itp.

dariuszp -> chyba raczej "programowanie strukturalne" . Języki funkcyjne oraz programowanie funkcyjne to zupełnie inny świat i inna filozofia .

Natomiast to, co piszesz dalej, jest oczywiście przydatne, ale nie do końca w takiej formie, jak napisałeś. Po pierwsze, taka klasa główna nie zawierałaby zbioru klas, a zbiór obiektów (jest zasadnicza różnica). Zakodowywanie na sztywno, że w systemie mamy np. system autoryzacji, mechanizm sesji itd. nie jest najszczęśliwszym pomysłem, ponieważ jest to zbyt mało elastyczne. O wiele lepiej zrobić coś w stylu kontenera wstrzykiwania zależności, który potrafi utworzyć obiekt konkretnego typu na żądanie przy pomocy zewnętrznych reguł.

Czepiasz się terminów jakich użyłem ale masz rację. Zresztą wiesz o co mi chodzi. Co do elastyczności to bym nie przesadzał. Kwestia potrzeb.

Jedni "zaszywają" na sztywno odpowiednie mechanizmy ograniczając się do wymaganego minimum. Inni jak Ty najwidoczniej starają się niczego nie usztywniać. Ja stosuje taki swój złoty środek. Mechanizmy są wpisane na sztywno z możliwością ich wymiany. Wspomagając się interfejsami dajemy programistą pewność że coś nagle z "rdzenia" nie zniknie jednocześnie dając im możliwość podmiany tych mechanizmów. I nikomu to nie przeszkadza tak długo jak sam interfejs klasy pozostaje taki jak być powinien. Tyle że sam system ma zachowane minimum poniżej którego nie zejdzie a rozbudowany może być tylko do góry.

A co do tematu to jeszcze zostaje jedna możliwość. Termin jaki podłapałem od programistów C++ bodajże. Superklasa jako klasa po której wszystkie inne dziedziczą. Coś takiego ma swoje zastosowanie głównie we frameworkach gdzie na ogół mamy zestaw metod wszelakich które muszą się zawsze i wszędzie znaleźć. Podejście bardzo pomocne jednocześnie mogące kopnąć nas w tyłek jeżeli stosujemy je bezmyślnie.
Bo nie ma to jak budować coś na superklasie (a nie raz klasy dziedziczą po sobie 3-5 poziomów w dół) tylko po to by sobie uzmysłowić że przez własną bezmyślność coś w niej trzeba zmienić poważniejszego co spowoduje grzebanie w CAŁYM kodzie systemu który jest na niej oparty.

Także podejście wygodne ale nieprzemyślane może się zemścić.

Dzięki za wyczerpujące odpowiedzi.

Z jednej strony faktycznie pakowanie "wszystkiego" do jednej klasy mija się z celem- natomiast [moim skromnym] zdaniem upakowanie do jednej klasy przydatnych funkcjonalności jest chyba tym czego potrzebuję. Dla rozjaśnienia mały przykład:

[PHP] pobierz, plaintext 
 
class funkcje {
 
   public function getIP() {
       // kod pobierajacy IP uzytkownikow
   }
 
   public function checkDirExists($dir) {
       // kod sprawdzający czy dany folder istnieje i czy nie jest pusty
   }
 
   public function checkNumber($int) {
       // kod sprawdzający czy zmienna $int jest liczbą
   }
// itd
}
[PHP] pobierz, plaintext 

Powyższy przykład ukazuje to czego potrzebuje- różne "pomocnicze" metody w jednym miejscu. Myślałem również nad podziałem takiej klasy na dwie statyczną i dynamiczną. Statyczna zwraca wyniki do klasy nadrzędnej natomiast dynamiczna zapisuje je do mysql, cookie itp. co o ty sądzicie?

Może ktoś już pisał podobną klasę i ma dla mnie jakieś przydatne rady? czego się ustrzegać, na co zwrócić szczególną uwagę?

A nie prościej po prostu zostawić funkcje? Nie będziesz musiał inicjować klasy, czy też pamiętać o dziedziczeniu. Ewentualnie zmień public na static, dzięki czemu jeśli używasz autoload, będziesz mógł w prosty sposób wywoływać te metody z dowolnego miejsca operatorem :: np. funkcje::getIP().

@Cuteone bo takie cos nie ma sensu.

[PHP] pobierz, plaintext 
class file {
 
    public function chedDirExists($dir) { }
 
}
 
class Validate {
 
    public function checkNumber($nr) { }
 
}
[PHP] pobierz, plaintext 

itp..itd...
SuperKlasa moglaby byc glowna rdzen klasa(Core,Apllication) ktore robia "wiele" na raz.....

Dokładnie, to co proponujesz lepiej zrobić z użyciem funkcji. W końcu po to są. Nie wiem też po co pisać funkcje typu chedDirExists skoro PHP ma od tego gotowe funkcje które na pewno zadziałają szybciej. Wystarczy sobie sprawdzić czy plik istnieje (file_exists) a potem tylko czy jest katalogiem (is_dir). Do rzeczy takich jak checkNumber( jeżeli dobrze zrozumiałem masz ctype_digit itp...
Pamiętaj pisząc cokolwiek - NIE KOMBINUJ. Tylko na firmach super hakerzy tworzą super haksiorskie systemy wszystko zamieniające na kolorowe 3D i durne animacje. Rzeczywistość jest o wiele prostsza. Problem nie może być bardziej skomplikowany niż być powinien. Bo się zorientujesz za pół roku że gubisz się we własnym kodzie. A co dopiero będzie jak ktoś inny zacznie z nim pracować.

Pozdrawiam

To nie jest kombinowanie- pisząc kilka projektów na raz nie mam czasu na przepisywanie w kółko tego samego. Tym bardziej na szukanie danej metody w stosie plików. Ot przykład z katalogiem

[PHP] pobierz, plaintext 
[...]
 
public $dir;
 
public function checkExists() {  return is_dir($this->dir) ? true : false; }
 
public function checkFile() { }
 
public function deleteDir() { return ($this->checkExists()) ? $this->checkFile() : return false; }
 
[..itd]
[PHP] pobierz, plaintext 

do tego dodać file_exists + usunięcie plików i jednym wywołaniem usuwam katalog nie martwiąc się czy istnieje lub czy jest pusty. Takl więc niezawodność w połączeniu z oszczędnością czasu to chyba dobre rozwiązanie.

Jasne normalnie robię to rozpisując wszystko na poszczególne klasy ale nazbierało mi się tego tyle, że właśnie teraz 'gubię się we własnym kodzie' szukając jednej metody przez kilka minut. Tak mam wszystko na wyciągnięcie ręki

Superklasy w takiej postaci jak chcesz ją zrobić, czyli klasa od wszystkiego, to kompletna porażka. Pomysł bardzo zły.
Jest to niemal w całości złamanie zasad programowania obiektowego z zasadą pojedynczej odpowiedzialności na czele.

Możesz napisać klasą typu Utils narzędziową z pakietem statycznych funkcji. To jest często pożądane. Ale niech to nie będzie wszystko naraz: baza danych, operacje plikowe, logowanie ciasteczka, e.t.c.

A nie lepiej zastapic to helperami?

A co za różnica jak to nazwiesz?
Ja mówię o ogólnym programowaniu w OOP i to o czym mowa to Utility class a nie Helper. No ale jak Ci nazwa nie pasuje ...

I właśnie tu pojawia się sprzeczność [czas pisania skryptu] <-> [jakość napisanego skryptu]. W mojej sytuacji gdzie codziennie mam na głowie ~5 aplikacji nad którymi pracuję nie mogę sobie pozwolić na choćby minimalne opóźnienia. Dlatego pyta czego mam się ustrzegać a na co zwrócić szczególną uwagę podczas pisania takiej klasy.
Myślę, że faktycznie nie ma co pakować się w cookie, sessje i bazy danych ale obsługę plików sobie zostawię zawsze to te 30 sekund zaoszczędzonego czasu.

Tak się zastanawiam- skoro superklasy do wszystkiego są złe to połowa znanych mi skryptów również jest zła choćby wcześniej przywołany IPB.

Tak oftopem znacie jakieś dobre rozwiązanie na podczepienie pluginów tylko i wyłącznie dla takiej superklasy? Czytałem wszystkie[a przynajmniej większość] tematy na ten temat ale nie widzę zastosowania podanych przykładów w mojej aplikacji.

Pozdrawiam i dzięki za wszelkie odpowiedzi

Alt, "zla" w pewnym sensie jako funkcjonalnosc wiele oferuje ale ze strony kodu to porazka, tak jak php-fusion, joomla czy inne cms/cmf.



Nie nie, masz racje mam zwyczaj mowic na proste i przydatne klasy(ogolnego uzytku widoki jak i kontrolery) wlasnie helpery ;p

Zalezy od twojego systemu i co plugin moze rozszerzac, do jakiego stopnia i na ile ma byc zalezny od systemu w ktorym dziala.
Najszybsze i najlatwiejsze rozwiazanie wedlug mnie to hooki, jednak ja hooki wole uzywac to czegos innego, a sam jestem na etapie przepisania calego silnika mojego "fw" zeby jeszcze lepiej moc zaimplemetowac plugin'y w mojej aplikacji.

ps: @CuteOne a nie lepiej napisac prosty szkielet i zbior klas ktory bedziesz mogl wykorzystac w kazdym projekcie? nie musi to byc odrazy framework.