SOLID a Piotr Gankiewicz

0

Cześć. Kurcze mam do was takie pytanie bo Piotr Gankiewicz w swoim kursie https://piotrgankiewicz.com/courses/becoming-a-software-developer/ mówił że modele domenowepowinny być rozbudowane nie powinny być anemiczne i dodaje walidację itd:
wygląda to mniej wiecej tak:

    public class Category
    {
        public long Id { get; protected set; }
        public string Name { get; protected set; }
        public string Description { get; protected set; }
        public virtual ICollection<Tenure> Tenures { get; protected set; }

        protected Category()
        {

        }

        public Category(string name, string description)
        {
            SetName(name);
            SetDescription(description);
        }

        public void SetName(string name)
        {
            if (string.IsNullOrWhiteSpace(name))
            {
                throw new Exception(Errors.IncorrectNameCategory);
            }
            Name = name;
        }

        public void SetDescription(string description)
        {
            if (string.IsNullOrWhiteSpace(description))
            {
                throw new Exception(Errors.IncorrectDescription);
            }
            Description = description;
        }
    }

a czytałem ostatnio o SOLID a dokładnie o regułę Single responsibility a dokładnie że każda klasa powinna być odpowiedzialna za jedną konkretną rzecz. i teraz się trochę pogubiłem :(

5

SRP nie polega na tym, że klasa może mieć jedną metodę albo trzymać tylko dane ;)
Tutaj nadal wg mnie jest SRP bo jedyną odpowiedzialnością tej klasy jest trzymanie danych kategorii i po prostu dba o to, żeby ktoś jej syfu nie nawrzucał.
Gdyby ta klasa nagle miała funkcję, która by np. modyfikowała pola w Tenure to bym uznał, że SRP faktycznie jest wątpliwe.

EDIT do komentarza:
Różnica pomiędzy walidacją w Twoim pierwszym poście, a tą robioną w linku z komentarza jest taka, że w pierwszym przypadku klasa tylko sprawdza czy ktoś nie próbuje ustawić jej pól na puste, czyli chroni się przed nullem.
W drugim przypadku - tym z linka - ten Email powinien być osobnym value objectem i sam dbać o swoją poprawność, a klasa Person by nadal mogła sprawdzać czy nie dostaje nulla ;)

1

SRP mówi o tym, że klasa powinna mieć tylko jeden powód do zmiany. I tak:

  1. Jedynym powodem do zmiany klasy z kursu Piotra jest zmiana danych opisujących kategorię (np. dodanie nowej właściwości ją opisującą).
  2. Tymczasem klasa z blogu Karola może mieć dwa możliwe powody do zmiany: zmiana danych opisujących osobę, albo zmianę algorytmu walidacji emaila. Dlatego właśnie łamie SRP.

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