5 komentarzy

  1. Marcin pisze:

    masz rację, jak poznałem Solida, nie tak dawno (wcześniej znałem z teorii) zaczołem się zastanawiać czy jeżeli chcę żeby aplikacja była solid to muszę stosować wszystkie pięć zasad? Z trzeciej to ja jeszcze nigdy nie skorzystałam, ale czy przez to moje aplikacje są mniej solid? Solid ro zbiór reguł nie wytycznych, a czy korzystamy i jak korzystamy z tego to wszystko zależy od nas (od kontekstu). Problem ze wszystkimi regułami i zasadami jest taki że jeżeli to wszystko zastosujemy to nasz kod będzie mniej czytelny niż wcześniej.
    Masz racje u miar trzeba znać, tylko kiedy mogę powiedzieć sobie dość?

    • Patryk pisze:

      Ja zwykłem zawsze mówić, że kod powinien być czytelny jak dobra książka fabularna, beletrystyka. Powinien się czytać jak tekst z fabułą, prawie z bohaterami. To jest, moim zdaniem, najważniejsze. Reguły takie jak SOLID, czy KISS, czy YAGNI, czy DRY są jedynie jak reguły które mówą jak powinien wyglądać artykuł w gazecie, albo jak powinno wyglądać wypracowanie. Czytelnik dzięki temu lepiej rozumie to co czyta, a pamiętajmy, że kod najczęściej jest czytany :).

  2. Tomek pisze:

    Hej, dzięki za fajny post!
    W czasach juniorskich było mi ciężko wyrobić sobie intuicję co do sformułowania „Robi jedną rzecz”, bo przecież przetwarzanie wiadomości albo edycja profilu użytkownika to w końcu jedna rzecz, prawda? Z pomocą przyszła mi alternatywna definicja, a mianowicie „Robi jedną rzecz” => „Istnieje tylko jeden powód do zmiany w klasie”. Wtedy zmiana schematu DB => zmiana w Procesorze, zmiana sposobu przetwarzania wiadomości => zmiana w Procesorze. Zatem widać, że zmiana w dwóch różnych obszarach aplikacji generuje zmianę w tej samej klasie. Zatem naruszyliśmy tutaj SRP.
    Twój post wpadł mi w oko również z innego powodu: pracuję aktualnie nad serią postów o typach i klasach w .NET/C#, i jeden z tych postów dotyczyć będzie literki L (Liskov Substitution Principle), i również omawiam go przez podanie przykładów łamania dobrych praktyk związanych z typami i projektowaniem zachowań. Podrzucę linka, gdy uda mi się skończyć serię (ach te postanowienia noworoczne;)) Co powiesz na gościnny post w Twojej serii?:)

    Pozdrawiam,
    Tomek

    • Patryk pisze:

      Zastanawiam się nad Twoją, alternatywną definicją SRP. I muszę to sobie przyswoić.
      Co do propozycji gościnnego posta – to świetny pomysł! Odezwę się jutro :).

      • aaa pisze:

        To nie jest alternatywna definicja, tylko oryginalna definicja Roberta C. Martina. To że 90% programistów ją rozumie po swojemu to inna sprawa. Tutaj wytłumaczona jeszcze raz przez autora: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

        Another wording for the Single Responsibility Principle is:

        Gather together the things that change for the same reasons. Separate those things that change for different reasons.
        If you think about this you’ll realize that this is just another way to define cohesion and coupling. We want to increase the cohesion between things that change for the same reasons, and we want to decrease the coupling between those things that change for different reasons.

        However, as you think about this principle, remember that the reasons for change are people. It is people who request changes. And you don’t want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *