Czy funkcja nie łamie zasady SOLID ?

0

Cześć, stworzyłem walidację formularza rejestracji a następnie dodaję dane do bazy danych. Wszystko działa poprawnie, tylko mam pytanie czy poniższy kod jest poprawny bo mam wątpliwości. Funkcja store() moim zdaniem powinna odpowiadać za jedną rzecza a ta funkcja haszuje hasło, przekierowuje i dodaje dane do bazy więc łamie zasadę SOLID.
Kontroler

class RegistrationController extends Controller
{

    public function index()
    {
        return view('registration');
    }

    public function store(RegistrationRequest $request)
    {
       $user = $request->validated();
       $user['password'] = Hash::make($user['password']);
        return redirect()->route(
            'index.store',
            ['registration' => User::create($user)]
        )->with('success', 'Success registration');
    }
}

Model

class User extends Model
{
    use HasFactory;

    protected $fillable = [
        'login', 'password', 'email'
    ];

    public function opinions()
    {
        return $this->hasMany(Opinion::class);
    }
}

requests

class RegistrationRequest extends FormRequest
{
    public function rules()
    {
        return [
            'login'            => 'required|min:3|max:12|unique:users,login|regex:/^[a-zA-z-0-9]+$/u',
            'email'           => 'required|email|unique:users,email',
            'password'        => 'required|string|min:3|max:12',
            'password_repeat' => 'required|same:password'
        ];
    }
}

route

Route::get('registration', [\App\Http\Controllers\RegistrationController::class, 'index'])->name('index');

Route::post('registration', [\App\Http\Controllers\RegistrationController::class, 'store'])->name('index.store');
1

Łamie jak 150, podobnie jak 99.999% metod kontrolera w laravelu i innych frameworkach.

Większość przykładowego kodu wszelkich frameworków łamie wszelkie dobre praktyki, zwłaszcza DI oraz SRP.

0
Riddle napisał(a):

Łamie jak 150, podobnie jak 99.999% metod kontrolera w laravelu i innych frameworkach.

Czyli to jest po prostu wina Laravela że łamie dobre praktyki, a ten kod który napisałem jest ok ?

0
phpowiec napisał(a):
Riddle napisał(a):

Łamie jak 150, podobnie jak 99.999% metod kontrolera w laravelu i innych frameworkach.

Czyli to jest po prostu wina Laravela że łamie dobre praktyki, a ten kod który napisałem jest ok ?

Nie. Przecież to ty napisałeś ten kod, co framework czy libki do tego mają.
Rolą kontrolera jest komunikacja klient HTTP <-> aplikacja. Twój kontroler:

  • parsuje request HTTP na PHPowy obiekt
  • wyciąga usera z requestu HTTP
  • hashuje hasło
  • tworzy użytkownika

Więc łamiesz S, O i D z SOLID. L i I nie łamiesz tylko dlatego, że w twoim kodzie nie ma żadnych interfejsów :D
W idealnym świecie twój kontroler wywoływałby jakiś serwis (oczywiście poprzez interfejs), ewentualnie parsując request HTTP na jakiś DTO albo po prostu parametry wywołania tego serwisu, a potem parsowałby wynik tego wywołania na odpowiedź HTTP, koniec.

0
iksde napisał(a):
phpowiec napisał(a):
Riddle napisał(a):

Łamie jak 150, podobnie jak 99.999% metod kontrolera w laravelu i innych frameworkach.

Czyli to jest po prostu wina Laravela że łamie dobre praktyki, a ten kod który napisałem jest ok ?

Nie. Przecież to ty napisałeś ten kod, co framework czy libki do tego mają.
Rolą kontrolera jest komunikacja klient HTTP <-> aplikacja. Twój kontroler:

  • parsuje request HTTP na PHPowy obiekt
  • wyciąga usera z requestu HTTP
  • hashuje hasło
  • tworzy użytkownika

Więc łamiesz S, O i D z SOLID. L i I nie łamiesz tylko dlatego, że w twoim kodzie nie ma żadnych interfejsów :D
W idealnym świecie twój kontroler wywoływałby jakiś serwis (oczywiście poprzez interfejs), ewentualnie parsując request HTTP na jakiś DTO albo po prostu parametry wywołania tego serwisu, a potem parsowałby wynik tego wywołania na odpowiedź HTTP, koniec.

Zmieniłem trochę kontroler, przeniosłem dodawanie usera do modelu, czy teraz jest trochę lepiej ?

public function store(RegistrationRequest $request, User $users)
    {
        $registration = $request->validated();
        $registration['password'] = Hash::make($registration['password']);
        
        $users->addUser($registration);
        
        return redirect()->route(
            'index.store'
        )->with('success', 'Success registration');
    }
0

To trzeba jeszcze porozbijać; poglądowo rozpiszę przykład w jaki sposób można to zrealizować.

  • UserCreateDto - obiekt DTO z danymi nowego użytkownika,
  • UserCreateDtoFactory - factory tworzące obiekt DTO np. na podstawie obiektu Request,
  • UserCreator - serwis tworzący usera, przyjmujący w/w DTO, z metodą create() (oraz oczywiście potrzebne abstrakcje bazodanowe i inne niezbędne fajerwerki),
  • UserByRequestCreator - serwis spinający całą logikę, przyjmuje w konstruktorze Request, UserCreateDtoFactory i UserCreator, ma metodę create().

W store() przyjmujesz jedynie UserByRequestCreator i odpalasz create() (odsyłasz odpowiedni Response uwzględniając wyjątki). W środku UserByRequestCreator walidujesz żądanie ($request->validated()), tworzysz DTO na jego podstawie (UserCreateDtoFactory) i w tworzysz użytkownika na podstawie DTO (UserCreator::create()). Wewnątrz UserCreator należy również zwalidować otrzymane DTO pod kątem domenowym (walidacja poprawności żądania != walidacja domenowej poprawności danych; walidacja nazw pól w żądaniu to osobny temat, a walidacja złożoności hasła - osobny) i ostatecznie zapisać usera.

Generalnie im dalej w las tym więcej klas i większa złożoność.

5

Ale w SRP nie chodzi o to że funkcja ma wywoływać jedną rzecz. Istotą SRP jest brak mieszania różnych poziomów abstrakcji w jednym czymś (funkcji, klasie, module). To że funkcja coś WYWOŁUJE nie jest uważane za to że funkcja to sama ROBI. Technicznie każda funkcja robi więcej niż jedną rzecz, ale nie jest to jeszcze łamanie SRP. Łamanie SRP masz wtedy gdy te samą jednostkę będziesz musiał zmieniać z powodu zmiany wielu niezwiązanych ze sobą powodów. Np. jeśli sposób kodowania usera w requescie się zmieni, to raczej funkcja dodająca usera do systemu nie powinna ulec zmianie. Ale może natomiast zmianie ulec funkcja parsujaca, wywoływana przez tę odpowiadającą za logiczna operacje tworzenia i zapisu użytkownika. Parsowanie powinieneś mieć w osobnej funkcji, zapis do bazy w osobnej, ale możesz mieć jedną funkcje spinajaca te dwie rzeczy i to nie łamie wtedy SRP.

Btw: klasy takie jak UserCreator to IMHO klasyczny Java deaease - przerost formy nad treścią.

0
phpowiec napisał(a):

Zmieniłem trochę kontroler, przeniosłem dodawanie usera do modelu, czy teraz jest trochę lepiej ?

Nie.

Jeśli robisz to tylko po to żeby się wpasowac w regułkę to tylko pogarszasz problem. Nie przestrzeganie tych zasad jest złe, owszem. Ale jeszcze gorsze jest ślepe dodawanie kodu nie rozumiejąc go.

Jeśli chcesz zrobić krok w stronę zrozumienia problemu, to polecam obejrzeć ten filmik (najlepiej 2 albo 3 razy):

0

@Riddle:

to jest ciekawy temat - dlaczego struktura plików ujawnia framework

według mnie dlatego, że

a) webowkę kodzi się inaczej niż resztę softu, bo zmienia się "entry point" do systemu - w webówce to są http requesty itd. Oczywiście są inne softy które też nasłuchują np. może jakaś bazka, ale tu pewnie jest inna nomenklatura.

b) framework narzuca konwencje, więc jeżeli ktoś je zna, to je dostrzega.

Czy to źle? idk

0
1a2b3c4d5e napisał(a):

@Riddle:

to jest ciekawy temat - dlaczego struktura plików ujawnia framework

według mnie dlatego, że

a) webowkę kodzi się inaczej niż resztę softu, bo zmienia się "entry point" do systemu - w webówce to są http requesty itd. Oczywiście są inne softy które też nasłuchują np. może jakaś bazka, ale tu pewnie jest inna nomenklatura.

Nie ma znaczenia jaki jest entry-point do aplikacji.

b) framework narzuca konwencje, więc jeżeli ktoś je zna, to je dostrzega.

Czy to źle? idk

Tak, to jest źle.

Polecam obejrzeć filmik który podlinkowałem, wszystko jest w nim opisane.

0

Mam jeszcze pytanie, czy takie rzeczy jak wstawianie danych, pobieranie danych z bazy powinny być w w funkcjach w modelu czy w kontrolerze, bo widzę kod innych osób i raz jest w kontrolerze a raz w modelu ?

0
phpowiec napisał(a):

Mam jeszcze pytanie, czy takie rzeczy jak wstawianie danych, pobieranie danych z bazy powinny być w w funkcjach w modelu czy w kontrolerze, bo widzę kod innych osób i raz jest w kontrolerze a raz w modelu ?

Obejrzałeś w całości filmik który podlinkowałem?

0
Krolik napisał(a):

Ale w SRP nie chodzi o to że funkcja ma wywoływać jedną rzecz. Istotą SRP jest brak mieszania różnych poziomów abstrakcji w jednym czymś (funkcji, klasie, module). To że funkcja coś WYWOŁUJE nie jest uważane za to że funkcja to sama ROBI. Technicznie każda funkcja robi więcej niż jedną rzecz, ale nie jest to jeszcze łamanie SRP. Łamanie SRP masz wtedy gdy te samą jednostkę będziesz musiał zmieniać z powodu zmiany wielu niezwiązanych ze sobą powodów. Np. jeśli sposób kodowania usera w requescie się zmieni, to raczej funkcja dodająca usera do systemu nie powinna ulec zmianie. Ale może natomiast zmianie ulec funkcja parsujaca, wywoływana przez tę odpowiadającą za logiczna operacje tworzenia i zapisu użytkownika. Parsowanie powinieneś mieć w osobnej funkcji, zapis do bazy w osobnej, ale możesz mieć jedną funkcje spinajaca te dwie rzeczy i to nie łamie wtedy SRP.

Btw: klasy takie jak UserCreator to IMHO klasyczny Java deaease - przerost formy nad treścią.

Skąd pomysł, że funkcja ma wywoływać jedną rzecz? Nie o to mi chodziło w przykładzie. Celem rozbicia logiki na kilka serwisów była prezentacja przykładowego podziału na warstwy, każdej z oddzielną odpowiedzialnością oraz własnym ograniczonym zbiorem zależności.

Wykonywanie wszystkiego w kontrolerze nie jest poprawną praktyką ponieważ zadaniem kontrolera jest obsługa żądania i odpowiedzi HTTP. Wydzielenie logiki tworzenia użytkownika do oddzielnej klasy/funkcji jest więc naturalne, z resztą sam to poniekąd sugerujesz. UserCreator pełni na tyle uniwersalną funkcję, że nie widzę powodu dla którego jego wydzielenie miałoby być objawem jakiegoś błędu; może być szereg innych scenariuszy w których będziemy chcieli stworzyć użytkownika w aplikacji, więc zaszywanie tej logiki w kontrolerze jest bez sensu (zakładając dalszy rozwój systemu, bo przy tak prostym przykładzie wiele elementów może wydawać się przerostem formy nad treścią).

0
Szado napisał(a):
Krolik napisał(a):

Ale w SRP nie chodzi o to że funkcja ma wywoływać jedną rzecz. Istotą SRP jest brak mieszania różnych poziomów abstrakcji w jednym czymś (funkcji, klasie, module). To że funkcja coś WYWOŁUJE nie jest uważane za to że funkcja to sama ROBI. Technicznie każda funkcja robi więcej niż jedną rzecz, ale nie jest to jeszcze łamanie SRP. Łamanie SRP masz wtedy gdy te samą jednostkę będziesz musiał zmieniać z powodu zmiany wielu niezwiązanych ze sobą powodów. Np. jeśli sposób kodowania usera w requescie się zmieni, to raczej funkcja dodająca usera do systemu nie powinna ulec zmianie. Ale może natomiast zmianie ulec funkcja parsujaca, wywoływana przez tę odpowiadającą za logiczna operacje tworzenia i zapisu użytkownika. Parsowanie powinieneś mieć w osobnej funkcji, zapis do bazy w osobnej, ale możesz mieć jedną funkcje spinajaca te dwie rzeczy i to nie łamie wtedy SRP.

Btw: klasy takie jak UserCreator to IMHO klasyczny Java deaease - przerost formy nad treścią.

Skąd pomysł, że funkcja ma wywoływać jedną rzecz? Nie o to mi chodziło w przykładzie. Celem rozbicia logiki na kilka serwisów była prezentacja przykładowego podziału na warstwy, każdej z oddzielną odpowiedzialnością oraz własnym ograniczonym zbiorem zależności.

Wykonywanie wszystkiego w kontrolerze nie jest poprawną praktyką ponieważ zadaniem kontrolera jest obsługa żądania i odpowiedzi HTTP. Wydzielenie logiki tworzenia użytkownika do oddzielnej klasy/funkcji jest więc naturalne, z resztą sam to poniekąd sugerujesz. UserCreator pełni na tyle uniwersalną funkcję, że nie widzę powodu dla którego jego wydzielenie miałoby być objawem jakiegoś błędu; może być szereg innych scenariuszy w których będziemy chcieli stworzyć użytkownika w aplikacji, więc zaszywanie tej logiki w kontrolerze jest bez sensu (zakładając dalszy rozwój systemu, bo przy tak prostym przykładzie wiele elementów może wydawać się przerostem formy nad treścią).

Nie jestem przekonany tym argumentem. Twój przykład z "rozbiciem na warstwy" również nie wydaje się wcale lepszy niż kod autora wątku. Zgadzam się z @Krolik tutaj.

Chociażby dlatego że samo użycie RegistrationRequest łamie SRP, bo miesza walidację request HTTP z walidacją logiki biznesowej. Jak już wspomniałem - większość przykładowego kodu frameworków łamie wszelkie dobre praktyki.

0

@Riddle:

Imo ma znaczenie, bo przy sofcie typu INPUT -> OUTPUT nie bawiłbym się w żadne kontrolery, które w web appkach gdzie masz START -> LISTENING -> END

i input przychodzi jak i kiedy chce do LISTENING, to kontroler jest tą warstwą, która odbiera dane z HTTP, a następnie przekazuje do handlera

0

Prawidłowe rozbicie logiki na warstwy załatwi nam problemy o których pisał @iksde czyli złamanie zasad SR, OC i DI.
O pomieszaniu walidacji pisałem już w pierwszym poście i tak, jest to błąd. Chociaż raczej programisty, a nie samego frameworka.

0

@Szado: Ale walidację robię w klasie RegistrationRequest a nie w kontrolerze, więc jak pomieszane ? Czy chodzi o to że z kontrolera powinienem wydzielić jeszcze request->validated() do klasy RegistrationRequest ?

1
phpowiec napisał(a):

@Szado: Ale walidację robię w klasie RegistrationRequest a nie w kontrolerze, więc jak pomieszane ? Czy chodzi o to że z kontrolera powinienem wydzielić jeszcze request->validated() do klasy RegistrationRequest ?

@phpowiec: walidacje w requestach laravelowych (w idealnym świecie) powinny służyć tylko do walidacji struktury żądania (obecności wymagalnych pól, ew. poprawności typów). Niestety łatwo je nadużyć i tym samym złamać SRP przez władowanie tam walidatorów biznesowych, np. sprawdzania wymaganej długości hasła lub czy weryfikacji dozwolonych znaków w loginie. Te dwa rodzaje walidacji powinny być przeprowadzane w dwóch odrębnych miejscach bo dotyczą dwóch różnych rzeczy.

0

@Szado: mam taki pomysł żeby wydzielić dodanie usera do modelu, haszowanie hasła do modelu do innej funkcji a funkcję validated() zwrócić w innej funkcji w RegistrationRequest. Czy wtedy będzie lepiej?

0
Szado napisał(a):

Prawidłowe rozbicie logiki na warstwy załatwi nam problemy o których pisał @iksde czyli złamanie zasad SR, OC i DI.
O pomieszaniu walidacji pisałem już w pierwszym poście i tak, jest to błąd. Chociaż raczej programisty, a nie samego frameworka.

Prawidłowe rozbicie tak, załatwi.

Tylko nie sądzę że przykład który podałeś kwalifikuje się jako takie.

phpowiec napisał(a):

@Szado: mam taki pomysł żeby wydzielić dodanie usera do modelu, haszowanie hasła do modelu do innej funkcji a funkcję validated() zwrócić w innej funkcji w RegistrationRequest. Czy wtedy będzie lepiej?

To zależy czy mówiąc masz na myśli "model" w kontekście klasy biznesowej, czy "model" w kontekście klasy ORM'owej która dziedziczy z Laravelowego Model.

Jeśli to pierwsze, to jest to dobry pomysł. Jeśli to drugie, to jest to zły pomysł.

@phpowiec: Pytanie zasadnicze, które zadaję już któryś raz - czy obejrzałeś filmik który podesłałem o czystej architekturze? Jest tam wiele przykładów, które opisuje problem z którym się borykasz.

1a2b3c4d5e napisał(a):

@Riddle:

Imo ma znaczenie, bo przy sofcie typu INPUT -> OUTPUT nie bawiłbym się w żadne kontrolery, które w web appkach gdzie masz START -> LISTENING -> END

i input przychodzi jak i kiedy chce do LISTENING, to kontroler jest tą warstwą, która odbiera dane z HTTP, a następnie przekazuje do handlera

Nic nie rozumiem z tego co napisałeś ;|

"Imo ma znaczenie" - ale co? Do czego się odnosi to zdanie?
"które w web appkach gdzie masz START -> LISTENING -> END" - nie rozumiem co tu jest napisane w ogóle

0

@Riddle:

Zwykły soft wykonuje się "od góry, do dołu"

Web appki tak nie mają, one się odpalają i czekają na przychodzące requesty, do których web fremjłorki przydzielają kontrolery, które to dopiero dostają jakieś byty rozumiane przez te aplikację i tutaj jest ten entry point. Spójrz sobie na Springowe czy ASPowe MVC flow diagramy

screenshot-20230104194752.png

screenshot-20230104194732.png

0
Riddle napisał(a):

To zależy czy mówiąc masz na myśli "model" w kontekście klasy biznesowej, czy "model" w kontekście klasy ORM'owej która dziedziczy z Laravelowego Model.

@Riddle: jestem początkujący i wiem że jest model dziedziczący po Modelu Laravela, natomiast model w kontekście biznesowej nie wiedziałem tego, a w którym miejscu mogę taką klasę stworzyć i wydzielić tam ten kod ?

0
phpowiec napisał(a):
Riddle napisał(a):

To zależy czy mówiąc masz na myśli "model" w kontekście klasy biznesowej, czy "model" w kontekście klasy ORM'owej która dziedziczy z Laravelowego Model.

@Riddle: jestem początkujący i wiem że jest model dziedziczący po Modelu Laravela, natomiast model w kontekście biznesowej nie wiedziałem tego, a w którym miejscu mogę taką klasę stworzyć i wydzielić tam ten kod ?

Wszystkie odpowiedzi znajdziesz w filmiku który podlinkowałem, nie rozumiem czemu nie chcesz go obejrzeć:

2

@phpowiec: Ja tak napiszę trochę z innej strony, źle na początku zadałeś pytanie. Nie powinieneś pytać czy kod napisany w Laravelu jest napisany zgodnie z SOLID tylko czy kod, który napisałeś jest zgodny z zasadami pisania w Laravel. Wpisz sobie w google coś na kształt "laravel architecture best practices" i poczytaj.

Czemu tak? A to dlatego, że tak jak już wspomniano wcześniej, "prawie każdy framework nie jest zgodny z SOLID". To czy to prawda czy nie, nie ma w tym wypadku żadnego sensu ponieważ dopiero zaczynasz przygodę i ważne jest abyś podłapał PODSTAWOWE zasady pisania czytelnego kodu. O ile same uwagi, które tutaj dostajesz są dla Ciebie kierunkiem w jakim powinieneś pójść o tyle uważam, że otrzymując tyle informacji na raz i to z "głębokiej wody" może trochę Ciebie przytłoczyć (a może i zniechęcić do pisania poprawnego kodu).

@Riddle: Obejrzałem filmik (nie dzisiaj ale już wcześniej gdzieś mi się przewinął) i o ile film jest o architekturze o tyle uważam, że sam przekaz nie jest dla początkujących. Tutaj jest od razu pokazanie "jak powinno wyglądać tworzenie aplikacji" w wielozespołowej grupie. To tak jakby profesor matematyki uczył pierwszoklasistów podstawówki i się jeszcze dziwił "to nie znacie wzorów skróconego mnożenia? Przecież to łatwe..."

@phpowiec: Jeżeli będziesz chciał to sobie zerknij tutaj: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html - tu masz tekst a dotyczy to prawie tego samego co w filmie. Problem leży w tym, że kod napisany w Laravel jest dla Ciebie "architekturą" to dla Uncle Bob'a jest tak naprawdę "dodatkiem" - i tu jest największa różnica.
Podsumowując - korzystasz z Laravela (czy tam z innego frameworka) i chcesz "tworzyć" kod czytelny i zgodny z SOLID to ok, ucz się tego na tym framweorku i zacznij najpierw od zdobycia jak największego skill'a w granicach właśnie tego framworka.

Osobiście uważam, że samo korzystanie z jakiegoś frameworka jest całkiem przydatne bo już na starcie można nauczyć się "dobrych zasad" (chociaż złych także :) ) programowania.

A teraz odnośnie samego tematu i Twojego kodu.

public function store(RegistrationRequest $request)
    {
       $user = $request->validated();
       $user['password'] = Hash::make($user['password']);
        return redirect()->route(
            'index.store',
            ['registration' => User::create($user)]
        )->with('success', 'Success registration');
    }

nie uważasz, że lepiej by było zapisać:

public function store(RegistrationRequest $request)
    {
       $user = $this->userService->create($request);
       // i coś tam dalej
    }

Generalnie - tworzeniem użytkownika niech się zajmie serwis (a nie model, @Riddle chodzi mi o ten Laravelowy :D ). Linijka

$user = $request->validated();

nie powinna być tutaj wcale, niech RegistrationRequest zwraca odpowiedni wynik jeżeli coś pójdzie nie tak. Musisz tylko pamiętać aby za bardzo nie "rozwarstwiać" kodu na coraz mniejsze kawałki bo w końcu gdzieś "przekroczysz" granicę "dibrych zasad".

0
leonpro778 napisał(a):

Generalnie - tworzeniem użytkownika niech się zajmie serwis (a nie model, @Riddle chodzi mi o ten Laravelowy :D ). Linijka

$user = $request->validated();

nie powinna być tutaj wcale, niech RegistrationRequest zwraca odpowiedni wynik jeżeli coś pójdzie nie tak. Musisz tylko pamiętać aby za bardzo nie "rozwarstwiać" kodu na coraz mniejsze kawałki bo w końcu gdzieś "przekroczysz" granicę "dibrych zasad".

Ja bym dał inną radę.

Albo wydzielać dobrze, albo wcale. Skoro autor wątku nie wie jak dobrze rozdzielić kod, to lepiej żeby próbował rozdzielać na siłe bo zrobi tylko bałagan.

0

@Riddle: No ale autor przecież pokazał Ci "nie wydzielony" kod (w pierwszym poście) :) Teraz prosi o pomoc przy "poprawieniu" :) Sam pomysł nauki podstaw SOLID opierając się na stworzeniu metody do utworzenia użytkownika nie jest taki zły i tak, wiem, że w 99% będzie zawsze coś do poprawy (w końcu to framework) ale od czegoś trzeba zacząć.

@pehapowiec: Odpowiadając na Twój komentarz - nie, nie wrzucaj tego do repository.

2

Abstrahując troszkę od tematu, a może i nie.
Nie wiem, czy do nauki SOLID nie spróbować czystego OOP bez framworka. Tak dochodzą jeszcze warstwy architektura. Jak się ogarnie podstawy to potem łatwiej to zobaczyć w bardziej rozbudowanym kodzie.

0

@jurek1980: Też bardzo dobry sposób ale założyłem, że autor tematu chce rozwijać umiejętności w Laravel

0
jurek1980 napisał(a):

Abstrahując troszkę od tematu, a może i nie.
Nie wiem, czy do nauki SOLID nie spróbować czystego OOP bez framworka. Tak dochodzą jeszcze warstwy architektura. Jak się ogarnie podstawy to potem łatwiej to zobaczyć w bardziej rozbudowanym kodzie.

@jurek1980: nie mam problemu ze stosowaniem solid w projekcie napisanym w czystym php, problem jaki mi sprawia to do jakich katalogów powinienem wydzielić odpowiednie funkcje

0

@jurek1980: nie mam problemu ze stosowaniem solid w projekcie napisanym w czystym php, problem jaki mi sprawia to do jakich katalogów powinienem wydzielić odpowiednie funkcje — phpowiec 9 minut

Spoko, tylko struktura katalogów nie ma nic do SOLID. Ale inaczej, co ma podstawienie Liskov do tego czy klasę nazwiesz Kupa a umieścisz w katalogu Marzenia.
Wybrałeś jeszcze Laravel które oparty jest o ActiveRecord i w zasadzie każdy model łamie SRP.
Dlatego czym innym jest SOLID a czym innym struktura frameworka, co już kilka razy było tu mówione.
Kiedyś chyba na kanale Laravel daily było ładnie omówione cos o SOLID w kontekście samego Laravel`a.
Problemem masz z np. określeniem odpowiedzialności klasy IMHO, czyli z podstawami SOLID. I tutaj jest bardzo często różna walka, czy robić serwisy DTO inne cuda. Czy lecieć tak jak zalecają tutoriale i zgodnie z jakimś tam schematem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1