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 =]

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

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:



Namespace wygląda wtedy mniej wiece tak



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

Lepszym rozwiązaniem była by taka struktura:



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.



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.

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ń.

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:



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

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

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



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ć.

@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.

@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.

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".
Prawdopodobnie problemem jest złe dobieranie przestrzeni nazw, a nie sam fakt ich mapowania na katalogi i pliki. Ale to temat na osobną dyskusję.

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?


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.