[PHP]Struktura folderow OOP Opcje

[goartur]

Czesc, rozumie oop w wiekszosci wypadkow, lecz mam pewien problem, nie wiem jaka strukture powinny miec moje foldery aby caly projekt byl przejrzysty i latwy w obsludze. Macie moze jakies rady, lub ss waszych struktur?


Dzieki =]

Ten post edytował goartur 10.06.2015, 21:54:36

[Crozin]

Google: PSR-4. Właściwie to wyczerpuje temat.

[Xelah]

Wybacz @Crozin ale PSR-4 to nie wyrocznia.

Tak na prawdę wszystko zależy od Twoich preferencji. PRS-4 jest jan najbardziej na miejscu jeśli nie masz nic przeciwko temu, że struktura forlderów = namespace.
Czasami takie rozwiązanie jest nieco kłopotliwe. Dla przykładu:
Aplikacja składa się z szeregu komend (Command). Każda z nich ma detykowany routing, factory, configurację i request validator.
W PSR-4 mamy coś takiego:

Kod

Application
    Command
        Index.php
    Configuration
        Index.php
    Factory
        Index.php
    Routing
        Index.php
    Validation
        Index.php

Namespace wygląda wtedy mniej wiece tak

Kod

Application\Command\Index
Application\Configuration\Index
Application\Factory\Index
Application\Routing\Index
Application\Validation\Index

Problem w tym, że grupowanie klas w ten sposób jest co mnajmniej mało intuicyjne.

Lepszym rozwiązaniem była by taka struktura:

Kod

Application
    Index
        Command.php
        Configuration.php
        Routing.php
        Factory.php
        Validation.php

Ale wtedy PSR-4 zmusza cie do zupełnie innego namespace, który moim zdaniem, jest mniej logiczny. Fakt, że pogrupowałem pliki w jednym folderze, to nie znaczy są w tym samym namespace.

Kod

Application\Index\Command
Application\Index\Configuration
Application\Index\Factory
Application\Index\Routing
Application\Index\Validation

Podsumowując namespace != strktura folderów. Sam musisz sobie odpowiedzieć która opcja jest dla ciebie bardziej czytalna i łatwiejsza do utrzymania. Nie zawsze sztywne trzymanie się PSR-4 jest najlepszym rozwiązaniem.

[Crozin]

PSR-4 to nie wyrocznia, ale programista powinien skupić się na organizacji klas i przestrzeni nazw, a nie ich odwzorowaniu w systemie plików. Dodatkowo nie ma absolutnie nic nielogicznego/złego w drugim z proponowanych przez Ciebie wariantów. Ba! Właściwie to pod wieloma względami jest on lepszy niż "standardowy", bo faktycznie grupuje powiązane ze sobą klasy w jedną przestrzeń.

[Xelah]

...programista powinien skupić się na organizacji klas i przestrzeni nazw, a nie ich odwzorowaniu w systemie plików...

No i w PSR-4 musi się skupić właśnie na tym, bo nie możne miec plików ułożonych inaczej niż namespace.

Mając następujące klasy:

Kod

Product\Attribute\FontColor
Product\Attribute\ImageResource

muszę bezwzgędnie umieścić je w:

Product/Attribute/FontColor.php
Product/Attribute/ImageResource.php

A jak chcę je pogrupować na przykład tak:

Kod

Product/Attribute/Text/FontColor.php
Product/Attribute/Image/ImageResource.php

to w PSR-4 muszę zmienić NS. Ale po co? Bo klasa jest w innym miejscu?

Za mapowanie odpowiedzialny autoloader i to on ładuje klasę z odpowiedniego miejsca. W PSR-4 nie masz wolnej ręki odnośnie NS i struktury. NS = struktura i programista nie może o tym zapomnieć.

[Crozin]

@Xelah: Nie zrozumiałeś chyba meritum mojej wypowiedzi: niech autor nie skupia się na sprawach nieistotnych, jak struktura katalogów/plików tylko na rzeczach istotnych, tj. strukturze przestrzeni nazw. Ich odwzorowanie w systemie plików jest niemal kompletnie nieistotne, ponieważ operuje się na klasach, nie plikach.

[Xelah]

@Crozin Sęk w tym, że lokalizacja samych plików też może być istotna. Szczególnie w bardziej skomplikowanych projektach z setkami klas znaczenie zaczyna mieć nie tylko NS ale i to, jak czyta się strukturę plików, którą widzisz w katalogu. Dlatego daleki byłbym od twierdzenia, że PSR-4 wyczrpuje temat. PSR-4 to TYLKO jedna z możliwości i nie zawsze musi być najlepsza. My też we wszystkich repo (szczególne nowych) mamy PSR-4, bo jest wygodny i schludny. Ale w jednym repo zaczynamy się poważnie zastanawiać, czy aby nie wywalić PSR i zrobić zwykłego mapowania. bo zagnieżdżenie NS urosło do takich rozmiarów, że trudno jest cokolwiek z tego łatwo odczytać. Ale strukturę plików jednach chcielibyśmy mieć inną...

Wybór struktury to decyzja teamu poparta argumentami. Nie ma jednej słusznej metody.

[Crozin]

Nie ma jednej słusznej metody.

O ile autor nie ma konkretnych przeciwwskazań co do standardowej struktury PSR-4 to będzie to dla niego jedyna słuszna - dlatego w pierwszym poście napisałem "właściwie".

Ale w jednym repo zaczynamy się poważnie zastanawiać, czy aby nie wywalić PSR i zrobić zwykłego mapowania. bo zagnieżdżenie NS urosło do takich rozmiarów, że trudno jest cokolwiek z tego łatwo odczytać.

Prawdopodobnie problemem jest złe dobieranie przestrzeni nazw, a nie sam fakt ich mapowania na katalogi i pliki. Ale to temat na osobną dyskusję.

[Xelah]

O ile autor nie ma konkretnych przeciwwskazań co do standardowej struktury PSR-4 to będzie to dla niego jedyna słuszna - dlatego w pierwszym poście napisałem "właściwie".

Teraz może się czepiam, ale skoro, jak sam napisałeś, mapowanie NS do plików nie powinno interesować develowera, to co za różnica, czy ma PSR-4 czy nie w ogóle nie ma PSR? Niby dlaczego jest to jedyne słuszne rozwiązanie? Skoro nie ma żadnych konkretnych przeciwwskazań, to dlaczego nie zrobić NS kompletnie niezależnego od struktury plików?

Prawdopodobnie problemem jest złe dobieranie przestrzeni nazw, a nie sam fakt ich mapowania na katalogi i pliki. Ale to temat na osobną dyskusję.

Hehe, temat NS i nazewnictwa przerabiamy kilka razy na tydzień. Bez względu jak będziesz chciał optymalizować NS to i tak przy setkach klas i skomplikowanych strukturach skończysz z długimi NS albo uniezależnisz strukturę od NS.

Jak to mawiają:
There are two hard things in computer science:
Naming things, cache invalidation and off-by-one errors.