Za mną pierwsza połowa mojego 30-dniowego mini projektu: Poznaj Zasady SOLID i OOP. Idzie dobrze, wszystkie zadania, które miałem do dzisiaj zrobić, zostały wykonane. Jednego dnia nie udało mi się popracować nad tym projektem, ale na szczęście kolejnego dnia mogłem to nadrobić.

W ramach tego projektu:

1. Odświeżyłem sobie zasady SOLID.
2. Przećwiczyłem zasady SOLID w praktyce (programując).
3. Napisałem posty z zadami solid, moimi praktycznymi przykładami (kilka również przetłumaczyłem na angielski).
4. Zrobiłem kurs e-mailowy: Poznaj zasady SOLID i OOP i sukcesywnie dodaję do niego kolejne lekcje.

Tutaj możesz zapisać się na kurs:

Przede mną jeszcze trochę pracy związanej z tym projektem: przede wszystkim odświeżenie zasad OOP. Stan projektu wygląda następująco (poprawiłem Excela, w którym zarządzam takim projektem, jeżeli będziecie chcieli, podzielę się nim z Wami). Zrobiłem 41 zadań i zostało mi jeszcze 45 zadań do zrobienia.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/sliced-green-fruit-on-white-surface-3550816/

SOLID

Zasady SOLID są podstawowymi dobrymi praktykami w programowaniu obiektowym. Warto jest nie tylko znać zasady SOLID, ale również je ćwiczyć. Przypomnijmy sobie jeszcze raz wszystkie zasady SOLID. Następnie przedstawię Ci sposoby, jak ćwiczyć zasady SOLID.

Single responsibility principle – Zasada jednej odpowiedzialności

Każda klasa powinna mieć tylko jedną odpowiedzialność (czyli tylko jeden powód do modyfikacji klasy) – jeden cel istnienia.

Open/closed principle – Zasada otwarte-zamknięte

Wszystkie klasy powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje.

Liskov substitution principle – Zasada podstawienia Liskov

Oprogramowanie powinno dobrze działać, gdy w miejsce klasy bazowej podstawimy jej którąkolwiek klasę potomną.

Interface segregation principle – Zasada segregacji interfejsów

Wiele dedykowanych i małych interfejsów jest lepsze niż jeden ogólny.

Dependency inversion principle – Zasada odwróconej zależności

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych, lecz zależność powinna wynikać z abstrakcji.

Ćwiczenia zasady SOLID

1. Programuj zwracając uwagę na zasady
2. Czytaj zasady
3. Czytaj kod innych osób w kontekście zasad
4. Obserwuj, jak zmienia się Twoje oprogramowanie i czy zasady SOLID ułatwiłyby jego rozwój czy odwrotnie.
5. Czytaj kod napisany w celu zaprezentowania zasad.
6. Dawaj swój kod do review (sprawdzenia) innej osobie i poproś, aby wzięła pod uwagę zasady.

Odwiedź strony z ćwiczeniami zasad SOLID

• Polecam: https://www.ii.uni.wroc.pl/~wzychla/ra2H2I/oopz3.pdf
• Polecam: https://www.ii.uni.wroc.pl/~wzychla/ra2H2I/w3.pdf
• http://devman.pl/pl/techniki/zasady-solid-wstep/
• http://itcraftsman.pl/solidny-jak-solid-pisanie-solidnych-aplikacji-w-jezyku-c/
• https://www.seeitsharp.pl/2019/01/lsp-czyli-nie-zadzieraj-z-kobietami/
• https://www.ii.uni.wroc.pl/~wzychla/ra2H2I/oop.html

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/person-holding-barbell-841130/

Materiały

• Czysta architektura — Robert C. Martin
• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• https://en.wikipedia.org/wiki/SOLID
• https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)
• https://www.samouczekprogramisty.pl/solid-czyli-dobre-praktyki-w-programowaniu-obiektowym/
• https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid/
• https://javadeveloper.pl/solid/
• https://sii.pl/blog/solid-dobre-praktyki-programowania/
• https://devcave.pl/notatnik-juniora/zasady-projektowania-kodu

Dependency inversion principle — Zasada odwróconej zależności

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych, lecz zależność powinna wynikać z abstrakcji.

Jak wykorzystywać w praktyce DIP?

Twórzmy dużo abstrakcyjnych bytów. Każda klasa niech implementuje interfejs lub dziedziczy po klasie abstrakcyjnej. Tworząc oprogramowanie, możemy najpierw stworzyć tylko interfejsy, a dopiero później je zaimplementować.

Pomocne w spełnieniu tej zasady jest przestrzeganie tych reguł:

• Każda zmienna w klasie jest referencja do abstrakcji.
• Wszystkie klasy dziedziczą po abstrakcji.
• Żadna klasy potomna nie przesłania metod z klasy bazowej.
• Ustawianie zmiennych realizowane jest przez wzorzec fabryki lub wstrzykiwania zależności.

Przykład

Poniżej mamy klasę pokazującą raport. Dane do raportu brane są za bazy danych. Implementacja wygląda następująco:

class Program
   {
       static void Main(string[] args)
       {
 
           var reportImporter = new ReportDatabaseImporter();
           var reportPresenter = new ReportPresenter(reportImporter);
           reportPresenter.ShowReport();
       }
   }
 
   internal class ReportPresenter
   {
 
       private readonly ReportDatabaseImporter importer;
 
 
       public ReportPresenter(ReportDatabaseImporter importer)
       {
           this.importer = importer;
       }
 
       public void ShowReport()
       {
           Console.WriteLine(importer.GetReportData());
       }
   }
 
 
 
   internal class ReportDatabaseImporter
 
   {
       public string GetReportData()
 
       {
           return "Report from Database";
       }
   }

Po jakimś czasie dostaliśmy prośbę o wyświetlanie danych również z pliku Excel w taki sam sposób. Niestety, nie jesteśmy w stanie zrobić tego łatwo. Musimy zmienić klasę prezentującą raport. Takie rozwiązanie pozwala nam dodawać łatwiej kolejne źródła raportu:

using System;
 
namespace SRP.Bad
{
    class Program
    {
        static void Main(string[] args)
        {
            var reportImporter = new ReportDatabaseImporter();
            var reportPresenter = new ReportPresenter(reportImporter);
            reportPresenter.ShowReport();
 
 
 
            var reportImporter2 = new ReportExcelImporter();
            var reportPresenter2 = new ReportPresenter(reportImporter2);
            reportPresenter2.ShowReport();
        }
    }
 
    internal class ReportPresenter : IReportPresenter
    {
        private readonly IReportImporter importer;
 
        public ReportPresenter(IReportImporter importer)
        {
            this.importer = importer;
        }
        public void ShowReport()
        {
            var reportData = importer.GetReportData();
            Console.WriteLine(reportData.GetContent());
        }
    }
 
    internal class ReportDatabaseImporter : IReportImporter
    {
        public IReportData GetReportData()
        {
            return new ReportData("Report from Database");
        }
    }
    internal class ReportExcelImporter : IReportImporter
    {
        public IReportData GetReportData()
        {
            return new ReportData("Report from Excel");
        }
    }
    internal class ReportData : IReportData
    {
        private readonly string content;
 
        public ReportData(string content)
        {
            this.content = content;
        }
        public string GetContent()
        {
            return content;
        }
    }
    internal interface IReportData
    {
        string GetContent();
    }
    internal interface IReportImporter
    {
        IReportData GetReportData();
    }
 
    internal interface IReportPresenter
    {
        void ShowReport();
    }
}

Mamy tutaj dużą liczbę interfejsów. Ułatwiają one jednak rozwój aplikacji oraz testowanie. W testach będziemy mogli pod interfejs podstawić mocka.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/batch-books-document-education-357514/

Materiały

• Czysta architektura — Robert C. Martin
• https://code.tutsplus.com/tutorials/solid-part-4-the-dependency-inversion-principle–net-36872
• https://lukaszkosiorowski.pl/programowanie/solid-zasada-odwracania-zaleznosci/
• http://tomaszjarzynski.pl/solid-czesc-5-zasada-odwrocenia-zaleznosci/
• http://devman.pl/pl/techniki/zasady-solid-5-zasada-odwrocenia-zaleznoscidependency-inversion/
• https://www.modestprogrammer.pl/solid-interface-segregation-principle-isp-wszystko-co-powinienes-wiedziec-o-zasadzie-segregacji-interfejsow

Interface segregation principle – Zasada segregacji interfejsów

Wiele dedykowanych i małych interfejsów jest lepsze niż jeden ogólny.

Jak wykorzystywać w praktyce ISP?

Należy rozdzielać interfejsy na mniejsze i przyłożyć się do projektowania abstrakcyjnych elementów w aplikacji. Za granicę podziału najlepiej wybierać jest miejsce, które pozwala wydzielić obszary zgodne z zasadą pojedynczej odpowiedzialności. Każdy obszar powinien mieć jeden powód do zmiany. Powinien zmniejszać zależności i zwiększać spójność. Interfejsy powinny zawierać taki zbiór metod, aby klasy je implementujące nie musiały implementować metod, których nie chcą implementować.

Przykład

class Program
  {
      static void Main(string[] args)
      {
          IDataImporter reportImporter = new ReportImporter();
          Console.WriteLine(reportImporter.GetDataFromPdf());
          Console.WriteLine(reportImporter.GetDataFromExcel());
 
          IDataImporter pictureImporter = new TableImporter();
          Console.WriteLine(pictureImporter.GetDataFromPdf());
          Console.WriteLine(pictureImporter.GetDataFromExcel());
      }
  }
 
  internal class TableImporter : IDataImporter
  {
      public string GetDataFromExcel()
      {
          return "Table from Excel";
      }
 
      public string GetDataFromPdf()
      {
          //We do not return a table from pdf file
          return string.Empty;
      }
  }
 
  internal class ReportImporter : IDataImporter
  {
      public string GetDataFromExcel()
      {
          return "Report from Excel";
      }
 
      public string GetDataFromPdf()
      {
          return "Report from Pdf";
      }
  }
 
  internal interface IDataImporter
  {
      string GetDataFromExcel();
      string GetDataFromPdf();
  }

Klasa TableImporter implementuje metodę, z której w ogóle nie korzysta. Lepiej jest oddzielić interfejs DataImporter na mniejsze interfejsy. Wtedy wszystkie klasy będą implementowały tylko to, co chcą.

class Program
{
    static void Main(string[] args)
    {
        var reportImporter = new ReportImporter();
        Console.WriteLine(reportImporter.GetDataFromPdf());
        Console.WriteLine(reportImporter.GetDataFromExcel());
 
        IExcelParser pictureImporter = new TableImporter();
        Console.WriteLine(pictureImporter.GetDataFromExcel());
    }
}
 
internal class TableImporter : IExcelParser
{
    public string GetDataFromExcel()
    {
        return "Table from Excel";
    }
}
 
internal class ReportImporter : IExcelParser, IPdfParser
{
    public string GetDataFromExcel()
    {
        return "Report from Excel";
    }
 
    public string GetDataFromPdf()
    {
        return "Report from Pdf";
    }
}
internal interface IExcelParser
{
    string GetDataFromExcel();
}
internal interface IPdfParser
{
    string GetDataFromPdf();
}

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/person-holding-paper-in-left-hand-and-pen-on-right-hand-sitting-beside-desk-2058132/

Materiały

• Czysta architektura — Robert C. Martin
• https://code.tutsplus.com/tutorials/solid-part-3-liskov-substitution-interface-segregation-principles–net-36710
• https://code.tutsplus.com/tutorials/solid-part-4-the-dependency-inversion-principle–net-36872
• https://lukaszkosiorowski.pl/programowanie/solid-zasada-segregacji-interfejsow/
• http://tomaszjarzynski.pl/solid-czesc-4-zasada-segregacji-interfejsow/
• http://devman.pl/pl/techniki/zasady-solid-4-zasada-segregacji-interfejsowinterface-segregation/
• https://www.modestprogrammer.pl/solid-interface-segregation-principle-isp-wszystko-co-powinienes-wiedziec-o-zasadzie-segregacji-interfejsow
• https://www.ifcode.pl/php-solid-i-zasada-segregacji-interfejsow/

Liskov substitution principle – Zasada podstawienia Liskov

Oprogramowanie powinno dobrze działać, gdy w miejsce klasy bazowej podstawimy jej którąkolwiek klasę potomną.

Jak wykorzystywać w praktyce LSP?

Należy dobrze zastanowić się przed skorzystaniem z dziedziczenia. Zazwyczaj lepszą opcją jest użycie kompozycji. Warto jest również zrobić proste eksperymenty: próbować podstawić w klasach korzystających z naszego drzewa klas, wszystkie klasy potomne oraz klasę bazową i zobaczyć, czy nadal program zachowuje się odpowiednio, czy może jednak oczekuje tylko jednego konkretnego rodzaju klasy.

Przykład

Rozważmy takie zadanie:

Mamy napisać aplikację, który wyświetla obraz z kamery video. Do naszej aplikacji możemy podłączyć wiele kamer. Nie wszystkie z nich potrafimy obsłużyć. Na szczęście wiemy to już na początku. Tworzymy klasę bazową Camera oraz klasy dziedziczące po kamerze, w tym również klasę dla kamery nieobsługiwanej.

class Program
   {
       static void Main(string[] args)
       {
           var cameras = new List<Camera>();
           var cameraNC1 = new CameraNC1("Front camera");
           cameras.Add(cameraNC1);
           var cameraShower = new CameraShower(cameraNC1);
           cameraShower.Show();
 
 
           var cameraNC2 = new CameraNC2("Back camera");
           cameras.Add(cameraNC2);
           cameraShower = new CameraShower(cameraNC2);
           cameraShower.Show();
 
           var unsupportedCamera = new UnsupportedCamera(null);
           cameras.Add(unsupportedCamera);
           cameraShower = new CameraShower(unsupportedCamera);
           cameraShower.Show();
       }
   }
 
   internal class CameraShower
   {
       private Camera camera;
 
       public CameraShower(Camera camera)
       {
           this.camera = camera;
       }
 
       internal void Show()
       {
           if (!(camera is UnsupportedCamera))
               Console.WriteLine($"Camera name: {camera.GetName()}");
       }
   }
 
   internal class CameraNC2 : Camera
   {
       public CameraNC2(string name) : base(name)
       {
       }
   }
   internal class CameraNC1 : Camera
   {
       public CameraNC1(string name) : base(name)
       {
       }
 
   }
   internal class UnsupportedCamera : Camera
   {
       public UnsupportedCamera(string name) : base(name)
       {
       }
 
       internal override string GetName()
       {
           throw new Exception("This camera does not have name. It is not supported.");
       }
   }
 
   internal abstract class Camera
   {
       protected readonly string name;
 
       public Camera(string name)
       {
           this.name = name;
       }
       internal virtual string GetName()
       {
           return name;
       }
   }

Wszystko pięknie działa. Ale musieliśmy kamerę niewspieraną specjalnie obsłużyć. Jeżeli byśmy tego nie zrobili, dostalibyśmy wyjątek. Możemy trochę inaczej zaimplementować metodę GetName w klasie dla kamery niewspieranej:

class Program
{
    static void Main(string[] args)
    {
        var cameras = new List<Camera>();
        var cameraNC1 = new CameraNC1("Front camera");
        cameras.Add(cameraNC1);
        var cameraShower = new CameraShower(cameraNC1);
        cameraShower.Show();
 
 
        var cameraNC2 = new CameraNC2("Back camera");
        cameras.Add(cameraNC2);
        cameraShower = new CameraShower(cameraNC2);
        cameraShower.Show();
 
        var unsupportedCamera = new UnsupportedCamera();
        cameras.Add(unsupportedCamera);
        cameraShower = new CameraShower(unsupportedCamera);
        cameraShower.Show();
    }
}
 
internal class CameraShower
{
    private Camera camera;
 
    public CameraShower(Camera camera)
    {
        this.camera = camera;
    }
 
    internal void Show()
    {
        Console.WriteLine($"Camera name: {camera.GetName()}");
    }
}
 
internal class CameraNC2 : Camera
{
    public CameraNC2(string name) : base(name)
    {
    }
}
internal class CameraNC1 : Camera
{
    public CameraNC1(string name) : base(name)
    {
    }
 
}
internal class UnsupportedCamera : Camera
{
    public UnsupportedCamera() : base("Unknown - this camera is not supported")
    {
    }
}
 
internal abstract class Camera
{
    protected readonly string name;
 
    public Camera(string name)
    {
        this.name = name;
    }
    internal virtual string GetName()
    {
        return name;
    }
}

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/black-and-gray-computer-tower-3624294/

Materiały

• Czysta architektura — Robert C. Martin
• https://medium.com/hackernoon/the-liskov-substitution-principle-and-why-you-might-want-to-enforce-it-6f5bbb05c06d
• https://code.tutsplus.com/tutorials/solid-part-3-liskov-substitution-interface-segregation-principles–net-36710

Open/closed principle – Zasada otwarte-zamknięte

Wszystkie klasy powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje.

Jak wykorzystywać w praktyce OCP?

Warto jest stosować interfejsy oraz operować na abstrakcji, a nie uzależniać się od szczegółów implementacyjnych.

Trudności związane z OCP

Ciężko jest czasami zdecydować, co jest szczegółem implementacyjnym oraz w którą stronę będzie rozszerzała się nasza aplikacja.

Przykład

Ćwiczenia tej metody wykonałem na bardzo prostym przykładzie. Mamy kalkulator, który ma za zadanie obliczyć powierzchnię figur. W pierwszej wersji używa on switcha, do rozpoznania, jaka jest to klasa.

class AreaCalculator
 {
     private readonly List<object> figures;
     public AreaCalculator(List<object> figures)
     {
         this.figures = figures;
     }
     public double Calculate()
     {
         double area = 0;
         foreach (var figure in figures)
         {
             switch (figure)
             {
                 case Square square:
                     area += square.GetWidth() * square.GetWidth();
                     break;
                 case Rectangle rectangle:
                     area += rectangle.GetWidth() * rectangle.Getheight();
                     break;
                 case Circle circle:
                     area += Math.PI * Math.Pow(circle.GetRadius(), 2);
                     break;
                 default:
                     area += area;
                     break;
             }
         }
         return area;
     }
 }
 
 class Square
 {
     private readonly double width;
     public Square(double width)
     {
         this.width = width;
     }
     internal double GetWidth()
     {
         return width;
     }
 }
 class Rectangle
 {
     private readonly double width;
     private readonly double height;
 
     public Rectangle(double width, double height)
     {
         this.width = width;
         this.height = height;
     }
     internal double GetWidth()
     {
         return width;
     }
     internal double Getheight()
     {
         return height;
     }
 }
 class Circle
 {
     private readonly double radius;
     public Circle(double radius)
     {
         this.radius = radius;
     }
     internal double GetRadius()
     {
         return radius;
     }
 }
 class Program
 {
     static void Main(string[] args)
     {
         List<object> figures = new List<object>()
         {
             new Square(5),
 
         };
         AreaCalculator areaCalculator = new AreaCalculator(figures);
 
         Debug.Assert(areaCalculator.Calculate() == 25);
 
         List<object> figures2 = new List<object>()
         {
             new Square(5),
             new Rectangle(5,3),
 
         };
         Debug.Assert(new AreaCalculator(figures2).Calculate() == (25 + 15));
         List<object> figures3 = new List<object>()
         {
             new Square(5),
             new Rectangle(5,3),
             new Circle(5),
 
         };
         Debug.Assert(new AreaCalculator(figures3).Calculate() 
           == (25 + 15 + Math.PI * 25));
     }
 }

W drugim przypadku klasy figur implementują interfejs, który ma metodę do liczenia pola powierzchni klasy. Każda klasa sama implementuję liczenie swojego pola powierzchni. Kalkulator jedynie sumuje pola powierzchni.

class AreaCalculator
   {
       private readonly IEnumerable<IFigureAreaCalculator> figures;
       public AreaCalculator(IEnumerable<IFigureAreaCalculator> figures)
       {
           this.figures = figures;
       }
 
       public double Calculate()
       {
           return figures.Sum(x => x.GetArea());
       }
   }
   interface IFigureAreaCalculator
   {
       double GetArea();
   }
   class Square : IFigureAreaCalculator
   {
       private readonly double width;
       public Square(double width)
       {
           this.width = width;
       }
 
       public double GetArea()
       {
           return width * width;
       }
 
       internal double GetWidth()
       {
           return width;
       }
   }
   class Rectangle : IFigureAreaCalculator
   {
       private readonly double width;
       private readonly double height;
 
       public Rectangle(double width, double height)
       {
           this.width = width;
           this.height = height;
       }
       internal double GetWidth()
       {
           return width;
       }
       internal double Getheight()
       {
           return height;
       }
 
       public double GetArea()
       {
           return width * height;
       }
   }
   class Circle : IFigureAreaCalculator
   {
       private readonly double radius;
       public Circle(double radius)
       {
           this.radius = radius;
       }
 
       public double GetArea()
       {
           return Math.PI * Math.Pow(radius, 2);
       }
 
       internal double GetRadius()
       {
           return radius;
       }
   }
   class Program
   {
       static void Main(string[] args)
       {
           var figures = new List<IFigureAreaCalculator>()
           {
               new Square(5),
 
           };
           AreaCalculator areaCalculator = new AreaCalculator(figures);
 
           Debug.Assert(areaCalculator.Calculate() == 25);
 
           var figures2 = new List<IFigureAreaCalculator>()
           {
               new Square(5),
               new Rectangle(5,3),
 
           };
           Debug.Assert(new AreaCalculator(figures2).Calculate() == (25 + 15));
 
           var figures3 = new List<IFigureAreaCalculator>()
           {
               new Square(5),
               new Rectangle(5,3),
               new Circle(5),
 
           };
           Debug.Assert(new AreaCalculator(figures3).Calculate() == (25 + 15 + Math.PI * 25));
       }
   }

Dodanie nowej figury nie będzie wymagało zmiany w klasie AreaCalculator.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/green-and-black-wallpaper-2268535/

Materiały

• Czysta architektura — Robert C. Martin
• https://hackernoon.com/why-the-open-closed-principle-is-the-one-you-need-to-know-but-dont-176f7e4416d
• https://code.tutsplus.com/tutorials/solid-part-2-the-openclosed-principle–net-36600

Single responsibility principle — Zasada jednej odpowiedzialności

Każda klasa powinna mieć tylko jedną odpowiedzialność (czyli tylko jeden powód do modyfikacji klasy) – jeden cel istnienia.

Jak wykorzystywać w praktyce SRP?

Łącz w jedno kod, który ma ten sam jeden powód do zmiany. Rozdzielaj od siebie kod, który ma wiele powodów do zmiany.

Trudności związane z SRP

Z zasadą jednej odpowiedzialności związane są pewne trudności:

• Nie jest zdefiniowane, czym jest zmiana.
• Nie jest zdefiniowane, czym jest odpowiedzialność.
• Wymaga przewidywania przyszłości.

Zasadę pojedynczej odpowiedzialności można przedefiniować.

Klasa, funkcja, metoda itp. powinna odpowiadać za pojedynczą logikę biznesową na jednym poziomie abstrakcji. (http://adam.wroclaw.pl/2014/12/zasada-pojedynczej-odpowiedzialnosci/)

Klasy powinny być organizowane tak, aby minimalizować złożoność. Powinny:

• Być na tyle małe, aby zmniejszać zależności.
• Być na tyle duże, aby maksymalizować spójność.

Domyślnie powinno się wybierać grupowanie funkcjonalności na rzecz rozdzielania kodu. (https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle)

Przykład

Klasa książka ma dwie odpowiedzialności:

1. Posiadanie informacji o sobie.
2. Drukowanie siebie.

   class Book
    {
        private string title;
        private string content;
        public Book(string title, string content)
        {
            this.title = title;
            this.content = content;
        }



        public void PrintBook()
        {
            Console.WriteLine(title);
            Console.WriteLine(content);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Book book = new Book("Interesting title", "Nice content");
            book.PrintBook();
        }
    }

W ramach refaktoryzacji wydzieliłem odpowiedzialność związaną z książką do oddzielnej klasy.

class Book
    {
        private string title;
        private string content;

        public Book(string title, string content)
        {
            this.title = title;
            this.content = content;
        }

        public string GetBookToPrint()
        {
            return $"{title}{Environment.NewLine}{content}";
        }
    }


    interface IPrinter
    {
        void Print(string content);
    }

    class BookPrinter : IPrinter
    {
        public void Print(string content)
        {
            Console.WriteLine(content);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IPrinter printer = new BookPrinter();
            Book book = new Book("Interesting title", "Nice content");
            var bookToPrint = book.GetBookToPrint();
            printer.Print(bookToPrint);
        }
    }

    }

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/pile-of-books-159866/

Materiały

• Czysta architektura — Robert C. Martin
• https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137
• https://code.tutsplus.com/tutorials/solid-part-1-the-single-responsibility-principle–net-36074
• http://adam.wroclaw.pl/2014/12/zasada-pojedynczej-odpowiedzialnosci/
• https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle

Dependency inversion principle — Zasada odwrócenia zależności

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych i detali, lecz zależność powinna wynikać z abstrakcji.

Wszystkie wysokopoziomowe moduły powinny być związane z niskopoziomowymi za pomocą abstrakcji. Abstrakcje nie powinny zależeć od detali, lecz to detale powinny być zależne od abstrakcji.

Pomocne w spełnieniu tej zasady jest przestrzeganie tych reguł:

• Każda zmienna w klasie jest referencja do abstrakcji.
• Wszystkie klasy dziedziczą po abstrakcji.
• Żadna klasy potomna nie przesłania metod z klasy bazowej.
• Ustawianie zmiennych realizowane jest przez wzorzec fabryki lub wstrzykiwania zależności.

Regułę tę można stosować do metod, funkcji, klas, modułów oraz pakietów.

Zalety

• Łatwiejsze wymienianie komponentów.
• Łatwiejsze wprowadzanie zmian w oprogramowaniu.
• Łatwiejsze ponowne wykorzystywanie komponentów.
• Łatwiejsze testowanie.

Wady

• Konieczność korzystania z interfejsów i klas abstrakcyjnych.
• Pracochłonność w tworzeniu stabilnych abstrakcji.
• Konieczność korzystania z fabryk lub wstrzykiwania zależności.

Przykład

• Klasa generująca raport (wysoki poziom) korzysta klasy logującej informacje o wyjątkach w aplikacji (niski poziom). Musi przekazać m.in. ścieżkę do folderu z logami. Zmiana klasy logującej do pliku na klasę logującą do bazy danych wymusi zmianę w klasie generującej raport, bo trzeba będzie przekazać inne dane do konstruktora klasy logującej.
• Klasa Kopiarka wykorzystująca klasę Czytnika i klasę Zapisywacza. Jeżeli mamy użyte klasy, a będziemy chcieli zmienić sposób zapisywania (z drukowania na drukarce, w generowanie pdfa), to będziemy musieli zmienić również klasę Kopiarka albo stworzyć nową klasę KopiarkaPdf. Gdyby klasa Kopiarka miała referencje do interfejsów IZapisywacz, to wystarczyłoby wstrzyknąć w nią odpowiednią implementację IZapisywacza, aby osiągnąć nasz cel.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/industry-metal-technology-manufacturing-50691/

Materiały

• Czysta architektura — Robert C. Martin
• https://sii.pl/blog/solid-dobre-praktyki-programowania/
• https://javadeveloper.pl/solid/
• https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid/
• https://www.samouczekprogramisty.pl/solid-czyli-dobre-praktyki-w-programowaniu-obiektowym/
• https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)
• https://en.wikipedia.org/wiki/SOLID
• https://en.wikipedia.org/wiki/Dependency_inversion_principle
• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• https://www.samouczekprogramisty.pl/dependency-inversion-principle-dependency-injection-i-inversion-of-control/
• https://programista-doswiadczony.pl/nie-solid-nie-05-dependency-inversion-principle/
• The Dependency Inversion Principle – Robert C. Martin – https://drive.google.com/file/d/0BwhCYaYDn8EgMjdlMWIzNGUtZTQ0NC00ZjQ5LTkwYzQtZjRhMDRlNTQ3ZGMz/view

Interface segregation principle — Zasada segregacji interfejsów

Wiele dedykowanych i małych interfejsów jest lepsze niż jeden ogólny.

Celem zasady segregacji interfejsów jest wyzbycie się z oprogramowania interfejsów, które odpowiadają za robienie wielu rzeczy. Źle zaprojektowane interfejsy mają tendencje do rozrastania się do zbyt wielkich rozmiarów, stają się one przez to  niespójne. Klasy, które je implementują, muszą implementować metody, których nie powinny. Zależne są one od metod, których nie używają.

Regułę tę można stosować do metod, funkcji, klas, modułów oraz pakietów.

Zalety

• Łatwiejsze zapewnienie Zasady podstawienia Liskov oraz Zasady pojedynczej odpowiedzialności.
• Łatwiejsze utrzymanie kodu.
• Większa czytelność kodu.
• Łatwiejsze zmienianie kodu.
• Brak konieczności implementacji niepotrzebnych metod w klasach, które nie powinny ich mieć.
• Brak interfejsów-bogów.
• Mniejsza zależność kodu od innego kodu.

Wady

• Duża liczba interfejsów.
• Większa pracochłonność podczas tworzenia oprogramowania.

Przykład

• Interfejs Zwierzę ma metodę Biegnij. Ten interfejs implementuje klasa Pies i Ryba. W klasie Ryba metoda Biegnij jest zbędna.
• Interfejs File ma dwie metody: Zapisz i Czytaj. Klasa PlikTylkoDoOdczytu implementuje ten interfejs i w metodzie Zapisz nie zapisuje nic do pliku, ponieważ nie może — jest to przecież plik tylko do odczytu.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/black-camera-accessory-lot-1476316/

Materiały

• Czysta architektura — Robert C. Martin
• https://sii.pl/blog/solid-dobre-praktyki-programowania/
• https://javadeveloper.pl/solid/
• https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid/
• https://www.samouczekprogramisty.pl/solid-czyli-dobre-praktyki-w-programowaniu-obiektowym/
• https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)
• https://en.wikipedia.org/wiki/SOLID
• https://en.wikipedia.org/wiki/Interface_segregation_principle
• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• The Interface Segregation Principle – Robert C. Martin – https://drive.google.com/file/d/0BwhCYaYDn8EgOTViYjJhYzMtMzYxMC00MzFjLWJjMzYtOGJiMDc5N2JkYmJi/view

Liskov Substitution Principle — zasada podstawień Barbary Liskov

Oprogramowanie powinno dobrze działać, gdy w miejsce klasy bazowej podstawimy jej którąkolwiek klasę potomną. Wymagana jest pełna zgodność interfejsu oraz metod. Projektując hierarchię klas, należy zrobić to tak, aby każda klasa pochodna mogła wykorzystywać wszystkie metody klasy bazowej bez konieczności ich przesłaniania. Metody klas pochodnych powinny najwyżej rozszerzać działanie metod z klasy bazowej (wywołując je w swojej implementacji). Dziedziczenie należy wykonać tak, aby klasa pochodna wykorzystała wszystkie metody implementowanej klasy bazowej.

Regułę tę można stosować do metod, funkcji, klas, modułów oraz pakietów.

Zalety

• Czytelniejszy i łatwiejszy w utrzymaniu kod.
• Możliwość podstawienia dowolnej klasy pochodnej w miejsce klasy bazowej bez obaw, że program źle zadziała.
• Mniej zależności w kodzie — obsługiwanie kolekcji obiektów danego typu bazowego nie wymaga sprawdzania, czy dany typ jest specjalnym typem i należy potraktować go inaczej.

Wady

• Konieczność lepszego przemyślenia struktury klas i ich dziedziczenia.

Przykład

• Kwadrat dziedziczący z klasy Prostokąt — metoda liczenia pola powierzchni jest nadpisana w kwadracie. Zasada Liskov jest złamana.
• Ryba dziedzicząca po klasie Zwierzę, gdzie Klasa Zwierzę ma metodę Biegnij. Ryba oczywiście nie biega. Zasada Liskov jest złamana.
• Klasa PlikTylkoDoOdczytu i PlikDoZapisuIOdczytu, dziedzicząca po klasie Plik. Klasa Plik ma metody Czytaj i Zapisuj. W klasie PlikTylkoDoOdczytu metoda Zapisuj nie będzie robiła tego, czego od niej oczekujemy, ponieważ nie można zapisać nic do pliku tylko do odczytu.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/people-wall-blur-inside-218445/

Materiały

• Czysta architektura — Robert C. Martin
• https://sii.pl/blog/solid-dobre-praktyki-programowania/
• https://javadeveloper.pl/solid/
• https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid/
• https://www.samouczekprogramisty.pl/solid-czyli-dobre-praktyki-w-programowaniu-obiektowym/
• https://pl.wikipedia.org/wiki/Zasada_podstawienia_Liskov
• https://en.wikipedia.org/wiki/Liskov_substitution_principle
• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• The Liskov Substitution Principle – Robert C. Martin – https://drive.google.com/file/d/0BwhCYaYDn8EgNzAzZjA5ZmItNjU3NS00MzQ5LTkwYjMtMDJhNDU5ZTM0MTlh/view
• https://dev-hobby.pl/csharp/liskov-substitution-principle-lsp/

Open-closed principle — Zasada otwarte/zamknięte

Każdy składnik oprogramowania powinien być otwarty na rozszerzenia i zamknięty na modyfikacje.

Dotyka ona dwóch zagadnień:

1. Zagadnienie otwarte — Składniki powinny być stworzone w sposób umożliwiający łatwe rozszerzenie ich zachowania. Zmiana ich zachowania nie wymaga zmiany istniejącego kodu, lecz dopisanie nowego.
2. Zagadnienie zamknięte — Modyfikacja zachowania nie powinna wiązać się ze zmianą już istniejącego kodu.

Regułę tę można stosować do metod, funkcji, klas, modułów oraz pakietów. Do jej stosowania wykorzystuje się zasadę Pojedynczej odpowiedzialności oraz regułę odwróconych zależności.

Zalety

• Większa elastyczność.
• Ponowne wykorzystywanie kodu.
• Łatwiejsze utrzymanie oprogramowania.
• Łatwiejsza rozbudowa systemu.
• Zapewnianie wstecznej kompatybilności.

Wady

• Duża trudność i pracochłonność podczas tworzenia oprogramowania.

Przykład

• Kalkulator liczący powierzchnię figur iteruje po liście obiektów implementujących interfejs IFigure, zamiast korzystania z switcha rozróżniającego po typie każdą klasę.
• Generatory raportów generujący raport implementujący interfejs IReportGenerator, którego można wstrzykiwać w klientów w zależności, jaki raport chcą (Pdf, Html).

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/door-green-closed-lock-4291/

Materiały

• Czysta architektura — Robert C. Martin
• https://sii.pl/blog/solid-dobre-praktyki-programowania/
• https://javadeveloper.pl/solid/
• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid/
• https://www.samouczekprogramisty.pl/solid-czyli-dobre-praktyki-w-programowaniu-obiektowym/
• https://pl.wikipedia.org/wiki/Zasada_otwarte-zamkni%C4%99te
• https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle
• The Open-Closed Principle – Robert C. Martin – https://drive.google.com/file/d/0BwhCYaYDn8EgN2M5MTkwM2EtNWFkZC00ZTI3LWFjZTUtNTFhZGZiYmUzODc1/view

Single responsibility principle — Zasada jednej odpowiedzialności

Każda klasa powinna mieć tylko jeden powód do zmiany.

Zgodnie z tą zasadą, każda klasa powinna:

• Tylko jeden cel istnienia.
• Tylko jedną odpowiedzialność.
• Tylko jedno zadanie do wykonania.
• Tylko jeden powód do modyfikacji.

Regułę tę można stosować do metod, funkcji, klas, modułów oraz pakietów.

Zalety

• Czytelniejszy kod.
• Łatwiejsze do zrozumienia.
• Brak klas-bogów — klas, które robią wszystko (albo bardzo dużo) i są zmieniane przy prawie każdej zmianie w oprogramowaniu.
• Łatwiejsze modyfikowanie i utrzymywanie oprogramowania.
• Mała zmiana oprogramowania dotyka tylko jednej klasy.
• Modyfikacja dotyka tylko obszaru, który chcemy zmienić. Nie dotyka innych obszarów.
• Mniejsza podatność na błędy.

Wady

• Dużo klas.

Przykład

1. Walidator adresu e-mail w oddzielnej klasie, a nie w klasie z danymi użytkownika.
2. Walidator numeru telefonu w oddzielnej klasie, a nie w klasie z danymi użytkownika.
3. Klasa zapisująca dane w bazie danych w oddzielnej klasie, a nie w klasie z tymi danymi.
4. Klasa przechowująca adres oddzielona od klasy z firmą, pracownikiem, klientem.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/black-and-white-chess-chess-piece-figurine-411195/

Materiały

• • Czysta architektura — Robert C. Martin
  • https://sii.pl/blog/solid-dobre-praktyki-programowania/
  • https://javadeveloper.pl/solid/
  • https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid/
  • https://www.samouczekprogramisty.pl/solid-czyli-dobre-praktyki-w-programowaniu-obiektowym/

• https://pl.wikipedia.org/wiki/Zasada_jednej_odpowiedzialno%C5%9Bci
• https://en.wikipedia.org/wiki/Single_responsibility_principle
• SRP: The Single Responsibility Principle – Robert C. Martin – https://drive.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/view

SOLID

SOLID jest podstawowym pojęciem w programowaniu obiektowym. Został przedstawiony przez Roberta C. Martina, który zebrał 5 zasad w skrót SOLID. Jest to akronim 5 zasad dobrego programowania obiektowego:

• Single responsibility principle – Zasada jednej odpowiedzialności.
• Open/closed principle – Zasada otwarte-zamknięte.
• Liskov substitution principle – Zasada podstawienia Liskov.
• Interface segregation principle – Zasada segregacji interfejsów.
• Dependency inversion principle – Zasada odwróconej zależności.

Single responsibility principle – Zasada jednej odpowiedzialności

Każda klasa powinna mieć tylko jedną odpowiedzialność (czyli tylko jeden powód do modyfikacji klasy) – jeden cel istnienia.

Open/closed principle – Zasada otwarte-zamknięte

Wszystkie klasy powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje.

Liskov substitution principle – Zasada podstawienia Liskov

Oprogramowanie powinno dobrze działać, gdy w miejsce klasy bazowej podstawimy jej którąkolwiek klasę potomną.

Interface segregation principle – Zasada segregacji interfejsów

Wiele dedykowanych i małych interfejsów jest lepsze niż jeden ogólny.

Dependency inversion principle – Zasada odwróconej zależności

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych, lecz zależność powinna wynikać z abstrakcji.

Zalety

• Większa czytelność kodu.
• Wyższa jakość kodu.
• Tańsze utrzymywanie.
• Mniej błędów podczas rozwoju.
• Łatwiejsze testowanie.
• Łatwiejsze rozwijanie kodu.
• Brak klas-bogów.

Wady

• Większa pracochłonność podczas tworzenia kodu.

Podsumowanie

Stosuj zasady SOLID wszędzie tam, gdzie możesz. Są to najlepsze praktyki, jakie możesz wykorzystać. W wyjątkowych sytuacjach pozwalaj sobie na odejście od tych reguł, na rzecz szybszego napisania aplikacji. Postaraj się, łamiąc zasady SOLID, napisać i tak w miarę dobry kod.

Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:

Źródła

Obraz główny

• https://www.pexels.com/photo/person-s-left-fist-punching-water-821037/

Materiały

• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• https://en.wikipedia.org/wiki/SOLID
• https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)
• https://www.samouczekprogramisty.pl/solid-czyli-dobre-praktyki-w-programowaniu-obiektowym/
• https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid/
• https://javadeveloper.pl/solid/
• https://sii.pl/blog/solid-dobre-praktyki-programowania/
• https://devcave.pl/notatnik-juniora/zasady-projektowania-kodu