Włączanie plików + autoloader, chętnie bym posłuchał ciekawych pomysłów Opcje

[hawk]

Problem stary jak świat: system wymaga włączenia sporej liczby plików i zarządzanie tym jest upierdliwe. Do tego nie należy włączać więcej kodu niż potrzeba, a najlepiej zrobić jakieś lazy load.

Oczywiście, technik jest wiele:

1) require_once rozsiane po plikach, najlepiej poprzedzone jakąś stałą, np. require_once ROOT_DIR . '/foo/Foo.class.php';

2) Prado: deklarujemy namespacy - np. za pomocą funkcji using(), co dodaje nam ścieżki do include_path, a potem niech php znajdzie klasę.

3) Autoloader + mapa (nazwa klasy => ścieżka do pliku); autoloader wczytuje mapę i na jej podstawie jest w stanie znaleźć każdą klasę

Są jeszcze jakieś inteligentne sposoby? Dobry mechanizm powinien być odporny na "przemeblowanie" struktury plików (np. chcemy połączyć kilka klas w jeden plik).

BTW, włączanie plików bez klas (tylko funkcje i kod) jest gorsze, bo nie ma tego czegoś, czego można szukać po plikach... kolejna zaleta OOP? (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[hawk]

Hawk: Wykorzystales 10 plikow na to co mozna zrobic w jednej klasie (i nie powiedziane ze gorzej).

No dobrze, porozmawiajmy wobec tego konkretnie. Na przykładach. Zaraz zobaczymy, czy rzeczywiście nie gorzej.

1. Chcę włączyć do mapy pliki z katalogów foo/first i foo/second, ale absolutnie nie z foo/third, bo tam są przykłady, które niepotrzebnie zaśmiecałyby mapę.

2. Chcę przeparsować tylko pliki o rozszerzeniu .class.php. Wszystko inne jest niepotrzebne.

3. Chcę, żeby w mojej mapie klasy były posortowane alfabetycznie. Dzięki temu mogę łatwo sprawdzić, jakie klasy są w moim pakiecie, a ponieważ jest to bez różnicy dla przetwarzania, nie ma żadnego powodu, żeby tego nie zrobić. No chyba że narzędzie jest gorsze...

4. Chcę wygenerować mapę dla zewnętrznego pakietu, który inaczej nazywa swoje klasy. Jak narzędzie, to uniwersalne, a nie ograniczone do mojego kodu, prawda? Pakiet jest w zupełnie innym miejscu na dysku.

5. Chcę w wersji produkcyjnej wrzucić kilka klas, które zawsze zawsze są używane, do jednego pliku, żeby przyspieszyć działanie i żeby prościej to wyglądało dla użytkownika końcowego. To częsta praktyka - weźmy np. mojavi.

6. Chcę za pomocą mojego autoloadera wygenerować mapę, która może być od razu wykorzystana w twoim systemie. Czyli plik wygląda tak samo. Chcę mieć uniwersalny autoloader, którego mogą używać inni, a nie nieprzenośne narzędzie.

7. Mam 2 mapy, do 2 różnych pakietów, i chcę obydwie naraz wbić do autoloadera.

Wierzę ci, że można to zrobić w jednej klasie. Która do tego będzie mniejsza niż suma tych plików i w ogóle lepsza. Tylko nie wiem, jak...

A co do tych 10 plików... rozmijasz się z prawdą (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . To są cztery pliki, plus trzy interfejsy (do niczego niepotrzebne, możesz je spokojnie wywalić, ale ja mam do interfejsów sentyment), plus trzy klasy dziedziczące z klas podstawowych (miałem kaprys zrobić coś extra, ale przecież w ogóle nie musisz ich wykorzystywać). Na podobnej zasadzie możemy zacząć liczyć unit testy i pliki readme.

---------------------------------------------

OOP ma sens owszem, ale nie w przypadku gdy tworzy sie klasy na 1-3 metod

Wiesz, co to jest Observer? Abstract Factory? Iterator? Registry? Intercepting Filter? Chain of Responsibility? Command? Strategy? Takie różne wzorce projektowe, ale niestety bez sensu, bo mają za mało metod.

Oczywiscie ze rozbijanie problemu na mniejsze czescie jest bardzo dobra technika ale sa pewne granice. Czasami mozna kilka z tych czesci polaczyc w jedna wieksza calosc bez szkody dla ostatecznego rozwiazania.

To ty zacząłeś tą dyskusję, więc odpowiedz: dlaczego rozbijanie problemu na mniejsze klasy jest szkodliwe? Bo z tego, co piszesz, wynika, że wg ciebie jest.