{"id":449,"date":"2020-02-29T11:11:00","date_gmt":"2020-02-29T11:11:00","guid":{"rendered":"https:\/\/www.juniorjavadeveloper.pl\/?p=449"},"modified":"2023-11-02T09:39:23","modified_gmt":"2023-11-02T09:39:23","slug":"dlaczego-kod-w-jezyku-java-powinien-byc-solidny-oraz-suchy-dry","status":"publish","type":"post","link":"https:\/\/www.juniorjavadeveloper.pl\/en\/2020\/02\/29\/dlaczego-kod-w-jezyku-java-powinien-byc-solidny-oraz-suchy-dry\/","title":{"rendered":"Why should Java code be SOLID and DRY?"},"content":{"rendered":"

In this article I will try to introduce two principles of good programming, namely SOLID<\/a> and DRY<\/a>. On the Internet you can find many technical descriptions and examples of the use of SOLID and DRY. I will present these concepts from a less technical perspective so that they are understandable to people who are just starting their adventure with programming or are wondering whether to learn programming, especially in Java.<\/p>\n\n\n\n

Why are the principles of good programming so important? Is the integrated development environment IDE<\/a> e.g. IntelliJ IDEA<\/a> shouldn't do this automatically for the developer? Unfortunately, or perhaps fortunately, this is not the case, when writing code, a programmer must follow the set rules and standards and at the same time be creative. The rules of good programming allow you to create good, readable and easy-to-modify code.<\/p>\n\n\n\n

Kod napisany w dowolnym j\u0119zyku programowania powinien czyta\u0107 si\u0119 jak dobra ksi\u0105\u017cka. Osoba czytaj\u0105ca ksi\u0105\u017ck\u0119 nie chcia\u0142by przecie\u017c by\u0107 zanudzana dok\u0142adn\u0105 kopi\u0105 fragment\u00f3w ksi\u0105\u017cki umieszczan\u0105 w wielu miejscach tej samej ksi\u0105\u017cki (DRY – Don’t Repeat Yourself). Ci\u0119\u017cko by\u0142oby czyta\u0107 ksi\u0105\u017ck\u0119, kt\u00f3ra ma pomieszane rozdzia\u0142y, akcja nie jest sp\u00f3jna i ma si\u0119 wra\u017cenie, \u017ce autor chyba nie wiedzia\u0142 co pisze (SOLID). <\/p>\n\n\n\n

Nie chodzi tu o kreatywn\u0105 form\u0119 prezentacji ksi\u0105\u017cki, ani nowy typ powie\u015bci. Za\u0142\u00f3\u017cmy, \u017ce ksi\u0105\u017cka ma pi\u0119\u0107 rozdzia\u0142\u00f3w i ka\u017cdy z nich czytany po kolei tworzy ci\u0105g przyczynowo skutkowy. Teraz wyobra\u017amy sobie sytuacj\u0119, \u017ce wydawca ksi\u0105\u017cki pomiesza\u0142 rozdzia\u0142y i z\u0142o\u017cy\u0142 ksi\u0105\u017ck\u0119 z rozdzia\u0142ami w kolejno\u015bci losowej. Czytanie takiej ksi\u0105\u017cki nie b\u0119dzie niemo\u017cliwe, ale na pewno nie b\u0119dzie nale\u017ca\u0142o do przyjemno\u015bci.<\/p>\n\n\n\n

It's the same with source code, when a programmer reads someone else's code, he or she must first arrange the code he or she is reading chronologically in his head (code sections), then find the characters in the book (variables) and understand how they interact (methods) with each other ( dependence). Correctly constructed A Java class according to Oracle<\/a> should have members in the following order:
\u2013 constants,
\u2013 variables,
\u2013 constructors,
\u2013 methods,
\u2013 first constants, variables and public methods, then private ones.<\/p>\n\n\n\n

public class GoodBook {\n    public static final int pages = 120;\n\n    private int currentPage = 1;\n    private int progress = 0;\n\n    public GoodBook() {\n    }\n\n    public void nextPage() {\n        currentPage++;\n    }\n\n    private void saveProgress() {\n        \/\/ calculate reading progress...\n    }\n}<\/pre>\n\n\n\n
public class BadBook {\n\n    \/\/ prywatna metoda\n    private void saveProgress() {\n        \/\/ calculate reading progress...\n    }\n \n   \/\/ publiczna sta\u0142a\n    public static final int pages = 120;\n\n    \/\/ konstruktor\n    public GoodBook() {\n    }\n\n    \/\/ prywatne zmienne\n    private int currentPage = 1;\n    private int progress = 0;\n\n    \/\/ publiczna metoda\n    public void nextPage() {\n        currentPage++;\n    }\n}<\/pre>\n\n\n\n
DRY<\/strong><\/a>, czyli ang. Don’t Repeat Yourself, pol. Nie powtarzaj si\u0119, dotyczy zar\u00f3wno samego kodu jak i czynno\u015bci wykonywanych przez programist\u00f3w. Wiele czynno\u015bci wykonywanych przez programist\u0119 mo\u017cna zautomatyzowa\u0107, czyli np. napisa\u0107 niewielki program, skrypt, kt\u00f3ry wykona automatycznie powtarzalne czynno\u015bci. Skrypty dla Windows to batch file<\/a>, a dla Linux shell script<\/a>. Je\u017celi chodzi o sam kod, to podstawowym sposobem na unikni\u0119cie duplikowania kodu jest wydzielanie powtarzaj\u0105cych si\u0119 fragment\u00f3w kodu do metod, przez metod\u0119 rozumiemy blok kodu, kt\u00f3ry dla wprowadzanych danych zwraca okre\u015blony wynik.<\/p>\n\n\n\n
SOLID<\/a><\/strong> okre\u015bla podstawowe za\u0142o\u017cenia programowania obiektowego, gdzie ka\u017cda litera oznacza konkretn\u0105 zasad\u0119 programowania. Tak jak pisa\u0142em w Internecie mo\u017cna znale\u017a\u0107 bardzo du\u017co przyk\u0142ad\u00f3w zastosowania SOLID, np. w j\u0119zyku Java – Baeldung.com<\/a>, java2blog.com<\/a>, howtodoinjava.com<\/a>. Ja skupi\u0119 si\u0119 na wyja\u015bnieniu tych regu\u0142 dla os\u00f3b zaczynaj\u0105cych przygod\u0119 z programowaniem w j\u0119zyku Java.
S – Single responsibility principle,
O – Open-closed principle,
L – Liskov substitution principle,
I – Interface segregation principle,
D – Dependency inversion principle.<\/p>\n\n\n\n
S jak zasada jednej odpowiedzialno\u015bci<\/strong> – wyobra\u017amy sobie sytuacj\u0119, w kt\u00f3rej jedna osoba (klasa Java) prowadzi biuro rachunkowe, ale jednocze\u015bnie jest jego w\u0142a\u015bcicielem. Czynno\u015bci kt\u00f3re wykonuje (metody w klasie Java), to m.in. obs\u0142uga ksi\u0119gowa firm, zatrudnianie pracownik\u00f3w, marketing i pozyskiwanie nowych klient\u00f3w. Ci\u0119\u017cko jest zweryfikowa\u0107, co i kiedy tak na prawd\u0119 robi (testy jednostkowe dla klasy Java, np. JUnit) ta osoba. W sytuacji, gdy w\u0142a\u015bciciel zrezygnuje z prowadzenia swojego biura rachunkowego (zmienia kod metody w klasie Java), zmiany nale\u017cy wprowadzi\u0107 we wszystkich firmach (klasach Java), kt\u00f3re korzysta\u0142y z jego us\u0142ug, czyli znale\u017a\u0107 nowe biuro rachunkowe. Podobnie jest z klasami w kodzie Java, je\u017celi jedna klasa robi za du\u017co, to zmiana jednej jej funkcji wp\u0142ywa na wszystkie klasy korzystaj\u0105ce z tej funkcji.<\/p>\n\n\n\n
O jak zasada otwarte-zamkni\u0119te<\/strong> – bardzo dobrze obrazuj\u0105 to elementy, kt\u00f3re mo\u017cna modyfikowa\u0107, rozszerza\u0107 bez zmiany samego elementu. Dla przyk\u0142adu firma obs\u0142uguj\u0105ca paczkomaty (klasa j\u0119zyka Java) chce obs\u0142ugiwa\u0107 nowe wi\u0119ksze paczki (metoda w klasie Java), dla kt\u00f3rych nie ma miejsca w obecnych paczkomatach (algorytm obs\u0142ugi paczek w klasie Java). Zmiana wszystkich istniej\u0105cych paczkomat\u00f3w by\u0142aby bardzo kosztowna, a czasem niemo\u017cliwa. Dlatego dobrym rozwi\u0105zanie jest takie zaprojektowanie paczkomatu (klasy j\u0119zyka Java), aby mo\u017cna by\u0142o bez zmiany samego paczkomatu dostawi\u0107 kolejny element, modu\u0142, kt\u00f3ry b\u0119dzie obs\u0142ugiwa\u0142 wi\u0119ksze paczki (algorytm obs\u0142ugi paczek w klasie Java pozostanie ten sam). Tak samo jest z klasami j\u0119zyka Java, projektujemy je tak, aby mo\u017cna by\u0142o je wykorzystywa\u0107 dla nowo pojawiaj\u0105cych si\u0119 element\u00f3w, bez konieczno\u015bci modyfikacji kodu samej klasy.<\/p>\n\n\n\n
L jak zasada podstawienia Liskov<\/strong> – przyk\u0142adem mo\u017ce by\u0107 ko\u0142o rowerowe (klasa j\u0119zyka Java), kt\u00f3re je\u017celi ma odpowiednie wymiary (atrybuty w klasie j\u0119zyka Java), \u015brednic\u0119, grubo\u015b\u0107 i wysoko\u015b\u0107 bie\u017cnika mo\u017cna zamontowa\u0107 w dowolnym rowerze, do kt\u00f3rego ko\u0142o b\u0119dzie pasowa\u0107. Oczywi\u015bcie ko\u0142a mog\u0105 mie\u0107 inne dodatkowe cechy (atrybuty w klasie j\u0119zyka Java) takie jak, np. rodzaj i kolor bie\u017cnika, dodatkowe szprychy, odblaski. Ale nadal b\u0119d\u0105 spe\u0142nia\u0107 swoj\u0105 funkcj\u0119 jako ko\u0142a. Podobnie jest z klasami j\u0119zyka Java dobrze przemy\u015blana klasa mo\u017ce wymienia\u0107 jeden element (atrybuty w klasie j\u0119zyka Java) na inny pochodz\u0105cy (dziedzicz\u0105cy) z tej samej grupy element\u00f3w.<\/p>\n\n\n\n
I jak zasada segregacji interfejs\u00f3w<\/strong> – krawiec (interfejs w j\u0119zyku Java) bior\u0105c miar\u0119 na marynark\u0119 dla m\u0119\u017cczyzny lub na \u017cakiet dla kobiety w inny spos\u00f3b obs\u0142uguje (r\u00f3\u017cne metody w r\u00f3\u017cnych interfejsach w j\u0119zyku Java) ka\u017cd\u0105 osob\u0119. M\u0119\u017cczyzna (klasa implementuj\u0105ca interfejs j\u0119zyka Java) nie musi wiedzie\u0107 jakie czynno\u015bci wykonuje krawiec dla kobiety (klasa implementuj\u0105ca intrfejs j\u0119zyka Java) i odwrotnie, ich interesuje us\u0142uga (metody w interfejsie w j\u0119zyku Java) jak\u0105 wykonuje krawiec. To samo dotyczy segregacji interfejs\u00f3w. Ka\u017cdy interfejs musi by\u0107 uszyty na miar\u0119 konkretnego klienta, czyli klasy, kt\u00f3ra b\u0119dzie go obs\u0142ugiwa\u0107.<\/p>\n\n\n\n
D jak zasada odwr\u00f3cenia zale\u017cno\u015bci<\/strong> – zasad\u0119 t\u0119 dobrze obrazuje roczny przegl\u0105d samochodu i sprawy z tym zwi\u0105zane. Jad\u0105c na przegl\u0105d do serwisu (framework z Inversion of Control, IoC) nie musimy zna\u0107 wszystkich czynno\u015bci, kt\u00f3re wchodz\u0105 w sk\u0142ad przegl\u0105du oraz wiedzie\u0107 kt\u00f3ra osoba (zale\u017cno\u015bci mi\u0119dzy klasami j\u0119zyka Java), co i kiedy b\u0119dzie wykonywa\u0107. Takie rzeczy wie serwis (IoC), do kt\u00f3rego jedziemy na przegl\u0105d, to w serwisie wiedz\u0105 jakie czynno\u015bci, w jakiej kolejno\u015bci nale\u017cy wykona\u0107 i kto ma wykona\u0107 (klasy w j\u0119zyku Java). My tylko przyje\u017cd\u017camy do serwisu (korzystamy z framework’u z Inversion of Control, IoC) i podajemy numery rejestracyjne, mark\u0119, model oraz przebieg samochodu. W kodzie j\u0119zyka Java sprawa wygl\u0105d tak samo, korzystamy z framewokr’a np. Spring Framework, kt\u00f3ry implementuje mechanizm odwr\u00f3cenia zale\u017cno\u015bci (ang. Inversion of Control) i to on za nas wie kiedy i jak stworzy\u0107 obiekty, przekaza\u0107 innym obiektom oraz kiedy je usun\u0105\u0107.<\/p>\n\n\n\n
\n
Contact<\/a><\/blockquote>