Krzysztof Baranowski

Main Menu

  • Felietony
  • Xamarin
  • Programowanie
  • Autor
    • O mnie
    • Kontakt i współpraca
    • Polityka prywatności
Sign in / Join

Login

Welcome! Login in to your account
Lost your password?

Lost Password

Back to login

logo

  • Felietony
  • Xamarin
  • Programowanie
    • iOS - MvvmCross Presenter dla UISegmentedControl

      2 grudnia 2018
      0
    • Xamarin – Customers Manager – #4 – iOS

      10 listopada 2018
      0
    • Xamarin – Customers Manager – #3 – Core i Android

      30 października 2018
      0
    • Xamarin – Customers Manager – #2 – Pierwsze kroki

      7 października 2018
      0
    • Xamarin - Customers Manager - #1 - Wprowadzenie

      4 października 2018
      0
    • Co spodobało mi się w TDD?

      6 września 2018
      0
    • "Social Project" - Xamarin Workbook #2 - Refit i Akavache

      28 lutego 2018
      0
    • "Social Project" - Xamarin Workbook #1

      25 lutego 2018
      0
    • Visual Studio - Build Events

      2 lipca 2017
      2
  • Autor
    • O mnie
    • Kontakt i współpraca
    • Polityka prywatności
  • iOS – MvvmCross Presenter dla UISegmentedControl

  • Xamarin – Customers Manager – #4 – iOS

  • Xamarin – Customers Manager – #3 – Core i Android

  • Elitarny Projekt “Przyszły Programista” – opinia Piotra Woźnickiego

  • Xamarin – Customers Manager – #2 – Pierwsze kroki

Programowanie
Home›Programowanie›SOLID #1 – SRP

SOLID #1 – SRP

By Krzysztof
21 grudnia 2016
1128
0
Udostępnij:

Jest to pierwsza część cyklu o mnemoniku SOLID. SOLID jest, krótko mówiąc zbiorem pięciu założeń programowania obiektowego,  finalnie sformułowanych i opisanych przez Roberta C. Martina – wybitnego programistę. Warto zaznaczyć, że reguły na których opiera się SOLID zostały wypracowane przez developerów na przestrzeni lat ale zostały spopularyzowane właśnie przez tego Pana.

 

SOLID

S – Zasada pojedynczej odpowiedzialności (Single Responsibility Principle – SRP)
O – Zasada otwarte – zamknięte – (Open-Closed Principle – OCP)
L – Zasada podstawiania Liskov  – (Liskov Substitution Principle – LSP)
I  – Zasada segregacji interfejsu – (Interface Segregation Principle – ISP)
D – Zasada odwracania zależności – (Dependency Inversion  Principle DIP)

 

Każdą z tych zasad będę przedstawiał w kolejnych częściach cyklu. W tej zajmiemy się pierwszą z nich, czyli zasadą pojedynczej odpowiedzialności. W myśl tej zasady, klasa powinna mieć pojedynczą odpowiedzialność – jeden powód do zmiany.

 

Single Responsibility Principle

Spójrzmy na klasę przedstawioną poniżej:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class BadEmployee
{
    private readonly string _email;
    private readonly int _salary;
    private string _name;
    private string _surname;
 
    public BadEmployee(string name, string surname, string email, int salary)
    {
        _salary = salary;
        _email = email;
        _name = name;
        _surname = surname;
    }
}

Klasa ta opisuje pracownika. Zawiera imię , nazwisko, wiek oraz adres e-mail. Mając taką klasę, zapewne chcielibyśmy sprawdzać poprawność danych pracownika. Dodajmy zatem metody sprawdzające e-mail oraz to czy np. pracownik zarabia więcej niż 2500zł.

 

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
class BadEmployee
{
    private readonly string _email;
    private readonly int _salary;
    private readonly int _salaryThreshold = 2500;
    private string _name;
    private string _surname;
 
    public BadEmployee(string name, string surname, string email, int salary)
    {
        _salary = salary;
        _email = email;
        _name = name;
        _surname = surname;
    }
 
    private string ValidateEmail()
    {
        string message = string.Empty;
 
        if (string.IsNullOrWhiteSpace(_email))
            message += "brak emaila, ";
 
        if (!_email.Contains("@"))
            message += "niepoprawny email, ";
 
 
        return message;
    }
 
    private bool CheckSalary()
    {
        return _salary >= _salaryThreshold;
    }
}

 

W porządku! Mamy pracownika, potrafimy sprawdzić poprawność jego danych. Nie bez powodu nazwałem klasę BadEmployee, bo rzeczywiście jest to zły pracownik. Otwarcie łamie zasadę SRP, ponieważ klasa ta przechowuje dane pracownika oraz jest odpowiedzialna za sprawdzenie poprawności tych danych. Walidacja powinna zostać oddelegowana do innej klasy przez co zasada SRP będzie działać a odpowiedzialności zostaną jasno rozdzielone. Spójrzmy na kod poniżej:

 

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
class GoodEmployee
{
    private readonly string _email;
    private readonly int _salary;
    private readonly ValidityTool _validityTool;
    private string _name;
    private string _surname;
 
 
    public GoodEmployee(string name, string surname, string email, byte salary)
    {
        _salary = salary;
        _email = email;
        _name = name;
        _surname = surname;
 
        _validityTool = new ValidityTool();
    }
 
    private string ValidateEmail()
    {
        return _validityTool.ValidateEmail(_email);
    }
 
    private bool IsAdult()
    {
        return _validityTool.CheckSalary(_salary);
    }
}
 
class ValidityTool
{
    private readonly int _salaryThreshold = 2500;
 
    public string ValidateEmail(string email)
    {
        string message = string.Empty;
 
        if (string.IsNullOrWhiteSpace(email))
            message += "brak emaila, ";
 
        if (!email.Contains("@"))
            message += "niepoprawna email, ";
 
 
        return message;
    }
 
    public bool CheckSalary(int salary)
    {
        return salary >= _salaryThreshold;
    }
}

 

Dodaliśmy klasę ValidityTool,  która jest odpowiedzialna za sprawdzenie poprawności danych. W klasie dobrego pracownika, oddelegowujemy zadanie walidacji do klasy ValidityTool.  Co zyskaliśmy? Podział odpowiedzialności – każda klasa ma swój jasno określony cel. Klasa GoodEmployee jest typowym przykładem klasy modelu. Tego typu klasy powinny tylko przechowywać dane, natomiast inne zadania (np. walidacja) powinny zostać oddelegowane do innych klas.

 

Na koniec

Należy pamiętać o tym aby tworzone klasy miały jedno jasno określone zadanie. Mimo, że jest to prawdopodobnie najłatwiejsza zasada w mnemoniku SOLID to stosowanie jej jest stosunkowo trudne. Często trudno jest wywnioskować czy napisana klasa rzeczywiście posiada pojedynczą odpowiedzialność. Jednakże wraz ze zdobytym doświadczenie staje się to coraz łatwiejsze.

TagiC#Czysty kodDaj się poznać 2017SOLID
Poprzedni

Szkoła C# – 1 – Delegaty i ...

Następny

SOLID #2 – OCP

1
Udostępnień
  • 1
  • +
  • 0

Krzysztof

Programista - pasjonata z dużym poczuciem humoru. Amator muzyki, sportu i dobrego starego filmu.

Powiązane Więcej

  • Programowanie

    Szkoła C# – 1 – Delegaty i wyrażenia lambda

    11 grudnia 2016
    By Krzysztof
  • Daj Się Poznać 2017Programowanie

    Jade-ERP #8 – Projektowa porażka

    23 kwietnia 2017
    By Krzysztof
  • Daj Się Poznać 2017Programowanie

    Jade-ERP #5 – Małymi kroczkami do przodu

    31 marca 2017
    By Krzysztof
  • Daj Się Poznać 2017Programowanie

    Jade-ERP #10 – Nowe ekrany

    7 maja 2017
    By Krzysztof
  • Daj Się Poznać 2017Programowanie

    SOLID #3 – LSP

    3 marca 2017
    By Krzysztof
  • Daj Się Poznać 2017Programowanie

    Jade-ERP #9 – Zaczyna coś się dziać

    30 kwietnia 2017
    By Krzysztof

Może Cię zainteresować

  • Daj Się Poznać 2017Felietony

    Daj Się Poznać 2017

  • Daj Się Poznać 2017Wydarzenia

    Hackathon Rzeszów 2017 – Relacja

  • Daj Się Poznać 2017ProgramowanieUncategorized

    MVVM – #2 – MVVM Toolkit #1

NEWSLETTER

Nie przegap kolejnych postów, informacji o rozwoju bloga lub wydarzeń z nim związanych.

Zapisz się do newslettera

programistabyc.pl!


Jednocześnie wyrażasz zgodę na otrzymywanie informacji marketingowych.

Sprawdź swoją skrzynkę odbiorczą (albo katalog na spam) i potwierdź swoją subskrypcję.

Znajdź mnie na

Ostatnie komentarze

  • Paweł Bulwan
    on
    19 sierpnia 2017
    Słomiany zapał niekoniecznie musi być zły ;) Tak naprawdę jeśli kilka razy w miesiącu wpadamy na ...

    Słomiany zapał

  • Przemek Smyrdek
    on
    4 lipca 2017
    Jeśli budujesz aplikację zdalnie, z wykorzystaniem jakiegoś narzędzia do CI/CD to możesz te eventy wykorzystać do ...

    Visual Studio – Build Events

  • Marcin Kościelniak
    on
    4 lipca 2017
    Ja np wykorzystuje czasem zdarzenie prev żeby do wersji aplikacji dobić numer rewizji svn z jakiej ...

    Visual Studio – Build Events

  • krzbb
    on
    9 czerwca 2017
    Dzięki za komentarz. Masz rację, programiści-gwiazdy nie są raczej dobrze postrzegani. Sam post (przynajmniej w moim ...

    Jak zadbać o siebie?

  • Cyan
    on
    7 czerwca 2017
    Moim zdaniem to nie ma nic wspólnego z informatyką a raczej brzmi jak artykuł z Cosmopolitana ...

    Jak zadbać o siebie?

Facebook

©2018 programistabyć.pl
Ta strona korzysta z ciasteczek, aby świadczyć usługi na najwyższym poziomie. Dalsze korzystanie ze strony oznacza, że zgadzasz się na ich użycie.RozumiemPolityka prywatności