jak pisac jadro ? Opcje

[Balin]

Witam, ostatnio zastanawiam sie w jaki sposob napisac jadro systemu webowego w php - doszedlem do wniosku, ze najlepiej uzyc singletonow do tworzenia instancji klas (db, io, klasa sesji, szablonow itp.) czy jednak lepiej aby jadro bylo rozproszone (wiele klas, kazda posiadajaca metode instance() ) czy raczej napisac jeszcze jednak klase Kernela, ktora to klasa przechowywala by w sobie metody tworzenia instancji i instancje wszystkich podsystemow, oraz kontrolowala wszelkie proby uzyskania takiej instancji ?
Jestem ciekaw jak wy to widzicie ? w jaki sposob wy pisaliscie rdzen systemu ?

[hawk]

1. Jest nieobiektowe (ale to sam wiesz...)

2. Sypie się, gdy developerów jest więcej, bo jeden nie wie gdzie co wstawił drugi, a obiekt jednak ma swój interfejs i łatwiej jest zorientować się jak się do tego dostać.

3. Może się sypać, gdy nie tylko ty masz taki pomysł, ale też twórca drivera do bazy danych, systemu szablonów, itd. i pechowo 2 ludzi wybierze sobie te same nazwy -> wtedy systemy są całkowicie niekombatybilne.

4. Mało modyfikowalne. Jak już masz to zaimplementowane to zmiana rozwala cały kod. A np. treść metody możesz wymienić, byleby tylko dalej zwracała co trzeba.

5. Mało dokumentowalne. Jak masz metodę getLogin() to dokumentacja tego jest prosta. Ale jak masz tablicę w $GLOBALS, to np. nie ma gdzie podczepić komentarzy phpdoc. A nawet jak już gdzieś się je umieści, to wyjasnienie, co będzie wstawiane w poszczególne pola, wymaga dłuższych elaboratów. A z metodą - proste.

6. Powiązania każdy-każdy. Nie masz pojęcia które pliki/klasy korzystają z których, bo jak coś siedzi w $GLOBALS to każdy kawałek kodu ma do tego dostęp. Łatwość dodawania modułów, o której piszesz, wynika właśnie z tego, że wszystko ma dostęp do wszystkiego. A design obiektowy wymusza zastanowienie się, komu dać dostęp (referencję) do danego obiektu. Jak zrobisz coś podobnego w podanym przykładzie, to wyjdzie z tego chaos.

Czyli ogólnie... nie, nie mam przeciwwskazań jeżeli system jest na tyle mały (w sensie ilości kodu i liczby developerów) że da się tym zarządzać przy użyciu kodu nieobiektowego.