solid examples description added

Author: maciej-nowak

_drafts/2019-10-07-solid.md

@@ -13,16 +13,16 @@ keywords: "zasady, reguły, obiektowe, solid, single responsibility, open-close,
 Zasady `SOLID` opisują pięć podstawowych reguł programowania obiektowego, których celem jest tworzenie zrozumiałego, elastycznego i łatwiejszego do utrzymania kodu. Mają zastosowanie nie tylko w projekcie zorientowanym obiektowo, ale także mogą stanowić fundamenty dla metodologi pracy takich jak np. metodyki zwinne.
 
 ## Single responsibility
-Zasada pojedynczej odpowiedzialności (`Single responsibility principle`) mówi, że nigdy nie powinno być więcej niż jednego powodu do modyfikacji klasy. Innymi słow każda klasa powinna być odpowiedzialna za realizacje pojedynczego tematu. Jest jednym z podstawowych elementów refaktoryzacji i skutkuje wydzieleniem mniejszych klas z jednej większej. Tworzenie kodu w oparciu o wiele małych klas zamiast kilku dużych pozwala przede wszysktim na uniknięcie powtórzeń tego samego fragmentu kodu. Modularyzacja znacząco przyczynia się do budowania zrozumiałej struktury projektu łatwiejszego w rozwoju i utrzymaniu.
+Zasada pojedynczej odpowiedzialności (`Single responsibility principle`) mówi, że nigdy nie powinno być więcej niż jednego powodu do modyfikacji klasy. Innymi słowy każda klasa powinna być odpowiedzialna za realizacje pojedynczego tematu. Jest jednym z podstawowych elementów refaktoryzacji i skutkuje wydzieleniem mniejszych klas z jednej większej. Tworzenie kodu w oparciu o wiele małych klas zamiast kilku dużych pozwala przede wszysktim na uniknięcie powtórzeń tego samego fragmentu kodu. Modularyzacja znacząco przyczynia się do budowania zrozumiałej struktury projektu łatwiejszego w rozwoju i utrzymaniu.
 
 {% highlight kotlin %}
 data class Person(val name: String, val surname: String, val bornYear: Int,
                   val city: String, val street: String, val houseNumber: String,
                   val email: String, val phoneNumber: String)
 {
 
-    fun createPdfSummary(): ByteArray {
-        //create pdf file with the data and return its bytes
+    fun createSummary(): ByteArray {
+        //create file with the data and return its bytes
         return byteArrayOf() //mock
     }
 
@@ -40,7 +40,7 @@ data class Person(val name: String, val surname: String, val bornYear: Int,
 }
 {% endhighlight %}
 
-//TODO
+Klasa `Person` posiada zbiór właściwości, które mogłyby zostać podzielone na mniejsze obiekty, np. klasy `Address` i `ContactDetails`. Pociąga to za sobą również przeniesienie metod `isEmailValid` i `isPhoneNumberValid` do odpowiadającej im klasy `ContactDetails` ponieważ nie leżą one teraz w obowiązku typu `Person`. Ponadto metoda `createPdfSummary` realizująca generowanie pliku przypisuje dodatkową odpowiedzialność w związku z czym należy ją oddelegować do klasy `SummaryGenerator`. Dzięki takiemu podziałowi możliwe jest ponowne wykorzystanie klas w innych miejscach aplikacji bez tworzenia nadmiarowego kodu.
 
 {% highlight kotlin %}
 data class Person(val name: String, val surname: String, val bornYear: Int,
@@ -64,10 +64,10 @@ data class ContactDetails(val email: String, val phoneNumber: String) {
     }
 }
 
-object PdfGenerator {
+object SummaryGenerator {
 
-    fun createPdfSummary(person: Person): ByteArray {
-        //create pdf file with the data and return the bytes
+    fun createSummary(person: Person): ByteArray {
+        //create file with the data and return the bytes
         return byteArrayOf() //mock
     }
 }
@@ -120,7 +120,7 @@ class Triangle(val a: Double, val b: Double, val c: Double)
 class Circle (val r: Double)
 {% endhighlight %}
 
-//TODO
+Dodanie nowej klasy z możliwością obliczenia pola i obwodu lub modyfikacja bieżących może skutkować zmianą w klasie `Calculator` co nie pozwoli na rozszerzenie funkcjonalności bez naruszenia bieżącej struktury klasy. W takiej sytuacji należy posłużyć się wspólnym typem bazowym `Figure` oraz wymusić implementacje szczegółów w klasach pochodnych `Rectangle`, `Triangle`, `Circle`. Następnie w klasie `Calculator` wystarczy wywołać metody typu bazowego co pozwoli na dodanie nowych figur do kalkulatora bez konieczności modyfikacji klasy `Calculator`.
 
 {% highlight kotlin %}
 object Calculator {
@@ -242,15 +242,30 @@ class TextNote(title: String, description: String, val text)
 }
 {% endhighlight %}
 
-//TODO
+Klient `NotesView` wykorzystuje zbiór obiektów typu `Note` w celu odtworzenia multimedialnej zawartości notatki bezpośrednio z widoku listy. Jednakże nie każdy obiekt rozszerzający typ bazowy posiada plik multimedialny. Przykładem takiej klasy jest `TextNote` której obiekty nie są zdolne do odtworzenia zawartości pomimo zgłoszonej deklaracji. `NotesView` nie musi znać szczegółów implementacji, oczekuje od wszystkich obiektów typu `Note` poprawnej implementacji i zdolności do wykonania zadania. Jednym z rozwiązań tego problemu może być stworzenie dodatkowego typu podstawowego dla notatek multimedialnych `MediaNote` rozszerzającego klasę `Note`, który przejmuje definicję funkcji `play`. Klient `NotesView` może teraz bez przeszkód wykorzystać wszystkie obiekty typu `MediaNote` do odtworzenia zawartości.
 
 {% highlight kotlin %}
+class NotesView() {
+
+    val notes = mutableListOf<MediaNote>()
+
+    fun init() {
+        notes.add(AudioNote("audio", "description", File("audio.mp3"), "transcription"))
+        notes.add(VideoNote("video", "description", File("video.mp4"), File("subtitlex.txt")))
+    }
+
+    fun playNote(index: Int) {
+        notes(index).play()
+    }
+}
+
 class Note(val title: String, val description: String) {
 
     //some methods
 }
 
-class MediaNote(title: String, description: String, val file: File) {
+class MediaNote(title: String, description: String, val file: File)
+	: Note(title, description) {
 
     //some media variables
 
@@ -323,7 +338,7 @@ interface Printable {
 }
 {% endhighlight %}
 
-//TODO
+Klasy `Exam` oraz `ExamResults` implementują interfejs `Printable`, który deklaruje możliwość generowania dokumentu tekstowego (`printDocument`) oraz arkusza kalkulacyjnego (`printSheet`). Jednakże eksportowanie obiektu klasy `Exam` do arkusza kalkulacyjnego nie ma sensu w związku z czym implementacja metody `printSheet` zgłosi wyjątek lub pozostanie pusta. Klient oczekujący stworzenia pliku arkusza kalkulacyjnego dla egzaminu spotka się z nieoczekiwanym zachowaniem lub wystąpieniem błędu. W związku z czym warto podzielić interfejs `Printable` na mniejsze dedykowane interfejsy `PrintableDocument` i `PrintableSheet`.
 
 {% highlight kotlin %}
 class Exam() : PrintableDocument {
@@ -379,7 +394,7 @@ class Downloader {
 }
 {% endhighlight %}
 
-//TODO
+Klasa `Downloader` odpowiedzialna za pobieranie informacji z serwera dokonuje szczegółowej implementacji zachowania, polegając tym samym na zależnościach niskiego poziomu. Takie podejście nie jest wskazane, gdyż silnie łączy klasę wysokiego poziomu z niskopoziomowymi obiektami. Alternatywnym podejściem będzie wprowadzenie warstwy abstrakcji w postaci interfejsu `Network` wywoływanej z klienta `Downloader`. Szczegóły implementacji niskopoziomowych obiektów zostają przeniesione do klas `RestNetwork` i `SocketNetwork` implementujących interfejs `Network` co pozwala ukryć zależności niskiego poziomu przed klientem.
 
 {% highlight kotlin %}
 class Downloader(val network: Network) {