[sarveniusz]

#1 SOLID - Zasada pojedynczej odpowiedzialności.
Omówienie jednej z pięciu ważnych zasad programowania obiektowego.

https://sarvendev.com/2017/08/1-solid-single-responsibility-principle/

#programowanie #webdev #php #javascript #sarvendev

[w.....j]

@sarveniusz: możesz robić przykład złego kodu i jak to naprawić żeby się do solida stosowało, o wiele łatwiej tak ludzie przyswajają

[sarveniusz]

@wczoraj: W następnych wpisach tak będzie, tutaj jako niepoprawny przykład jest akurat kod z ORMa Eloquent, a uznałem, że do zrozumienia zasady SRP więcej przykładów nie potrzeba, bo raczej wiadomo o co chodzi.

[w.....j]

@sarveniusz: mi chwile zajęło zrobienie przykładu dobrze oddającego problem i jednocześnie jak najprostszego do niektórych zasad, powodzenia

[sarveniusz]

@wczoraj: Podrzuć w komentarzu na blogu, więcej przykładów nie zaszkodzi.

[mozetenbedziewolny]

@sarveniusz: > Odpowiedzialnością modelu powinna być jedynie reprezentacja danych oraz relacji z innymi modelami.

Czy po prostu źle przelałeś swoje myśli na tekst, czy otwarcie namawiasz do Anemic Domain Model?

[sarveniusz]

@mozetenbedziewolny: skrót myślowy, pod reprezentacją danych miałem na myśli również logikę biznesową.

[mozetenbedziewolny]

@sarveniusz: kumam, w takim razie chyba do poprawy - średnio to oczywiste, a bardziej kontrowersyjne :P

[wojtek656]

wpis taktyczny

[MQs]

@sarveniusz: Nie wiem czy Active Record to najlepszy przykład na łamanie SRP, bo to nie jest takie jednoznaczne. Sam obiekt mógłby bez łamania SRP wyszukiwać, zapisywać i reprezentować dane, pod warunkiem, że wyszukiwanie i zapisywanie odbywałoby się bez wiedzy/udziału klienta. Z tak "naprawioną" enkapsulacją jest inny problem - nie jest to w zasadzie już obiekt, a struktura danych, więc masz połączenie niestabilnego interfejsu i (jednego) wewnętrznego reason to change, czyli

[rabulex]

@sarveniusz:

Przekładając tę analogię na programowanie, gdy mamy niewielki projekt, który nie będzie rozwijany (np. szybki prototyp, który później leci do kosza) tworzenie takich klas wykonujących kilka czynności nie napędzi nam ogromnych kłopotów. Natomiast przy tworzeniu projektu, który ma być porządnie przetestowany oraz w przyszłości rozwijany powinniśmy mieć tą zasadę na uwadze i starać się pisać kod tak, aby jej nie łamać.

Takie troche Captain Obvious te 2 zdania ;)

Aczkolwiek

[sarveniusz]

@rabulex: Oczywiście, że lepiej trzymać się pewnych zasad, nigdzie nie napisałem, żeby robić byle jak :) Po prostu w pewnych sytuacjach zaciągnięcie długu technologicznego nie jest niczym złym, ważne aby mieć tego świadomość.