{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 zasad programowania obiektowego, kt\u00f3re ka\u017cdy programista powinien zna\u0107","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nCz\u0119sto spotykam programist\u00f3w, kt\u00f3rzy nie s\u0142yszeli o zasadach SOLID (my szczeg\u00f3\u0142owo opisywali\u015bmy je tutaj<\/a><\/noindex>. \u2014 Przyp. red.) lub programowaniu obiektowym (OOP), albo s\u0142yszeli, ale nie stosuj\u0105 ich w praktyce. W tym artykule przedstawiono korzy\u015bci z zasad OOP, kt\u00f3re pomagaj\u0105 programi\u015bcie w codziennej pracy. Niekt\u00f3re z nich s\u0105 dobrze znane, inne \u2014 mniej, wi\u0119c artyku\u0142 b\u0119dzie przydatny zar\u00f3wno dla nowicjuszy, jak i do\u015bwiadczonych programist\u00f3w.
\n<\/a><\/noindex><\/p>\n

Przypominamy:<\/b> Dla wszystkich czytelnik\u00f3w \"Habra\" \u2014 zni\u017cka 10 000 rubli przy zapisaniu si\u0119 na dowolny kurs Skillbox z u\u017cyciem kodu promocyjnego \u201eHabra\u201d.<\/i><\/p>\n

Skillbox poleca:<\/b> Edukacyjny kurs online Programista Java<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Nie Powtarzaj Si\u0119)<\/h3>\n

\nBardzo prosta zasada, kt\u00f3rej istota jest jasna z nazwy: \u201eNie powtarzaj si\u0119\u201d. Dla programisty oznacza to konieczno\u015b\u0107 unikania duplikuj\u0105cego kodu oraz mo\u017cliwo\u015b\u0107 wykorzystania abstrakcji w pracy.<\/p>\n

Je\u015bli w kodzie znajduj\u0105 si\u0119 dwa powtarzaj\u0105ce si\u0119 fragmenty, nale\u017cy je po\u0142\u0105czy\u0107 w jedn\u0105 metod\u0119. Je\u015bli ustalone na sztywno warto\u015bci s\u0105 u\u017cywane wi\u0119cej ni\u017c jeden raz, warto przekszta\u0142ci\u0107 je w publiczn\u0105 sta\u0142\u0105.<\/p>\n

To potrzebne, aby upro\u015bci\u0107 kod i u\u0142atwi\u0107 jego wsparcie, co jest g\u0142\u00f3wnym celem OOP. Jednak r\u00f3wnie\u017c nie nale\u017cy nadu\u017cywa\u0107 \u0142\u0105czenia, poniewa\u017c ten sam kod nie przejdzie walidacji ani dla OrderId, ani dla SSN.<\/p>\n

Inkapsulacja zmian<\/h3>\n

\nProdukty oprogramowania wielu firm nieustannie si\u0119 rozwijaj\u0105. Oznacza to, \u017ce kod musi by\u0107 modyfikowany, a jego wsparcie jest konieczne. Mo\u017cna sobie u\u0142atwi\u0107 \u017cycie dzi\u0119ki inkapsulacji. Pozwoli to na skuteczniejsze testowanie i utrzymanie istniej\u0105cej bazy kodu. Oto jeden z przyk\u0142ad\u00f3w<\/a><\/noindex>.<\/p>\n

Je\u015bli piszesz w Javie, to domy\u015blnie przypisuj metodom i zmiennym modyfikator private<\/a><\/noindex>.<\/p>\n

Zasada otwarto\u015bci\/zamkni\u0119cia<\/h3>\n

\nT\u0119 zasad\u0119 mo\u017cna \u0142atwo zapami\u0119ta\u0107, czytaj\u0105c nast\u0119puj\u0105ce stwierdzenie: \u201eJednostki programowe (klasy, modu\u0142y, funkcje itp.) powinny by\u0107 otwarte na rozszerzenie, ale zamkni\u0119te na zmiany\u201d. W praktyce oznacza to, \u017ce mog\u0105 pozwala\u0107 na zmian\u0119 swojego zachowania bez modyfikacji kodu \u017ar\u00f3d\u0142owego.<\/p>\n

Zasada jest wa\u017cna, gdy zmiany w kodzie \u017ar\u00f3d\u0142owym wymagaj\u0105 jego przegl\u0105du, testowania jednostkowego i innych procedur. Kod, kt\u00f3ry przestrzega zasady otwarto\u015bci\/zamkni\u0119to\u015bci, nie zmienia si\u0119 przy rozszerzaniu, dlatego wi\u0105\u017ce si\u0119 z nim znacznie mniej problem\u00f3w.<\/p>\n

Oto przyk\u0142ad kodu, kt\u00f3ry narusza t\u0119 zasad\u0119.<\/p>\n

\"10
\n
\nJe\u015bli b\u0119dzie wymagana jakakolwiek zmiana, zajmie to du\u017co czasu, poniewa\u017c trzeba b\u0119dzie zmieni\u0107 wszystkie fragmenty kodu, kt\u00f3re s\u0105 powi\u0105zane z potrzebnym fragmentem.<\/p>\n

Zreszt\u0105, otwarto\u015b\u0107-zamkni\u0119to\u015b\u0107 to jedna z zasad SOLID.<\/p>\n

Zasada pojedynczej odpowiedzialno\u015bci (SRP)<\/h3>\n

\nKolejna zasada z zestawu SOLID. Twierdzi, \u017ce \"istnieje tylko jeden pow\u00f3d, dla kt\u00f3rego klasa powinna by\u0107 zmieniana\". Klasa rozwi\u0105zuje tylko jedno zadanie. Mo\u017ce mie\u0107 kilka metod, ale ka\u017cda z nich s\u0142u\u017cy tylko do rozwi\u0105zania og\u00f3lnego problemu. Wszystkie metody i w\u0142a\u015bciwo\u015bci powinny s\u0142u\u017cy\u0107 tylko temu. <\/p>\n

\"10
\n
\nWarto\u015b\u0107 tej zasady polega na tym, \u017ce os\u0142abia ona powi\u0105zania mi\u0119dzy poszczeg\u00f3lnymi komponentami oprogramowania a kodem. Je\u015bli dodasz wi\u0119cej ni\u017c jedn\u0105 funkcjonalno\u015b\u0107 do klasy, wprowadza to powi\u0105zanie mi\u0119dzy dwiema funkcjami. W ten spos\u00f3b, je\u015bli zmienisz jedn\u0105 z nich, istnieje du\u017ca szansa, \u017ce zepsujesz drug\u0105, zwi\u0105zan\u0105 z pierwsz\u0105. A to oznacza zwi\u0119kszenie liczby cykli testowania, aby zidentyfikowa\u0107 wszystkie problemy z wyprzedzeniem.<\/p>\n

Zasada inwersji zale\u017cno\u015bci (DIP)<\/h3>\n

\n\"10
\n
\nPowy\u017cej jest przyk\u0142ad kodu, w kt\u00f3rym AppManager zale\u017cy od EventLogWriter, kt\u00f3ry z kolei jest \u015bci\u015ble zwi\u0105zany z AppManagerem. Je\u015bli potrzebny jest inny spos\u00f3b wy\u015bwietlania powiadomie\u0144, czy to push, SMS, czy e-mail, nale\u017cy zmieni\u0107 klas\u0119 AppManager.<\/p>\n

Problem mo\u017cna rozwi\u0105za\u0107 za pomoc\u0105 DIP. Tak, zamiast AppManagera, \u017c\u0105damy EventLogWriter, kt\u00f3ry zostanie wprowadzony za pomoc\u0105 frameworka.<\/p>\n

DIP umo\u017cliwia bezproblemowe zast\u0119powanie pojedynczych modu\u0142\u00f3w innymi, zmieniaj\u0105c modu\u0142 zale\u017cno\u015bci. To pozwala na modyfikacj\u0119 jednego modu\u0142u bez wp\u0142ywania na pozosta\u0142e.<\/p>\n

Kompozycja zamiast dziedziczenia<\/h3>\n

\n\"10Podstawowe sposoby ponownego u\u017cycia kodu to dziedziczenie i kompozycja, z kt\u00f3rych ka\u017cdy ma swoje zalety i wady. Zwykle preferuje si\u0119 drugi, poniewa\u017c jest bardziej elastyczny.<\/p>\n

Kompozycja pozwala na zmian\u0119 zachowania klasy w czasie wykonywania poprzez ustawianie jej w\u0142a\u015bciwo\u015bci. Przy implementacji interfejs\u00f3w wykorzystywany jest polimorfizm, co pozwala na bardziej elastyczn\u0105 realizacj\u0119.<\/p>\n

Nawet \"Effective Java\" Joshuy Blocha zaleca preferowanie kompozycji zamiast dziedziczenia.<\/p>\n

Zasada podstawienia Barbary Liskov (LSP)<\/h3>\n

\nKolejna zasada z zestawu SOLID. M\u00f3wi ona, \u017ce podtypy powinny by\u0107 wymienne dla nadtyp\u00f3w. Oznacza to, \u017ce metody i funkcje dzia\u0142aj\u0105ce z nadklas\u0105 powinny m\u00f3c dzia\u0142a\u0107 bez problemu r\u00f3wnie\u017c z jej klasami pochodnymi.<\/p>\n

LSP jest zwi\u0105zana zar\u00f3wno z zasad\u0105 pojedynczej odpowiedzialno\u015bci, jak i zasad\u0105 podzia\u0142u odpowiedzialno\u015bci. Je\u015bli klasa zapewnia wi\u0119cej funkcji ni\u017c jej podklasa, to ta ostatnia nie b\u0119dzie wspiera\u0107 niekt\u00f3rych funkcji, naruszaj\u0105c t\u0119 zasad\u0119.<\/p>\n

Oto fragment kodu, kt\u00f3ry narusza LSP.<\/p>\n

\"10
\n
\nMetoda area(Rectangle r) oblicza pole Rectangle. Program zako\u0144czy dzia\u0142anie po wykonaniu Square, poniewa\u017c Square nie jest tutaj Rectangle. Zgodnie z zasad\u0105 LSP, funkcje, kt\u00f3re u\u017cywaj\u0105 odniesie\u0144 do klas bazowych, powinny mie\u0107 mo\u017cliwo\u015b\u0107 korzystania tak\u017ce z obiekt\u00f3w klas pochodnych bez dodatkowych instrukcji.<\/p>\n

Ta zasada, kt\u00f3ra jest specyficznym okre\u015bleniem podtypu, zosta\u0142a zaproponowana przez Barbar\u0119 Liskov w 1987 roku na konferencji w referacie g\u0142\u00f3wnym zatytu\u0142owanym \u201eAbstrakcja danych i hierarchia\u201d \u2014 st\u0105d jej nazwa.<\/p>\n

Zasada podzia\u0142u interfejsu (ISP)<\/h3>\n

\nKolejna zasada SOLID. Zgodnie z ni\u0105 interfejs, kt\u00f3ry nie jest u\u017cywany, nie powinien by\u0107 realizowany. Przestrzeganie tej zasady pomaga systemowi pozosta\u0107 elastycznym i odpowiednim do refaktoryzacji przy wprowadzaniu zmian w logice dzia\u0142ania.<\/p>\n

Najcz\u0119\u015bciej taka sytuacja wyst\u0119puje, gdy interfejs zawiera kilka funkcjonalno\u015bci, z kt\u00f3rych klient potrzebuje tylko jedn\u0105.<\/p>\n

Poniewa\u017c napisanie interfejsu jest skomplikowanym zadaniem, po zako\u0144czeniu pracy jego zmiana, bez naruszania istniej\u0105cego kodu, mo\u017ce stanowi\u0107 problem.<\/p>\n

Zalet\u0105 zasady ISP w Javie jest to, \u017ce najpierw nale\u017cy zaimplementowa\u0107 wszystkie metody, a dopiero potem mog\u0105 by\u0107 one u\u017cywane przez klasy. Dlatego zasada pozwala na zmniejszenie liczby metod.<\/p>\n

\"10
\n <\/p>\n

Programowanie dla interfejsu, a nie implementacji<\/h3>\n

\nTutaj wszystko jest jasne z nazwy. Zastosowanie tej zasady prowadzi do tworzenia elastycznego kodu, kt\u00f3ry b\u0119dzie dzia\u0142a\u0142 z ka\u017cd\u0105 now\u0105 implementacj\u0105 interfejsu.<\/p>\n

Nale\u017cy u\u017cywa\u0107 typu interfejsu dla zmiennych, typ\u00f3w zwracanych lub typu argumentu metody. Przyk\u0142ad \u2014 u\u017cycie SuperClass, a nie SubClass.<\/p>\n

To znaczy:<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

A nie:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Oto praktyczna realizacja tego, o czym mowa powy\u017cej.<\/p>\n

\"10
\n <\/p>\n

Zasada delegacji<\/h3>\n

\nPowszechnym przyk\u0142adem s\u0105 metody equals() i hashCode() w Java. Gdy konieczne jest por\u00f3wnanie dw\u00f3ch obiekt\u00f3w, akcja ta jest delegowana odpowiedniej klasie zamiast klienta.<\/p>\n

Zalet\u0105 zasady jest brak duplikacji kodu i stosunkowo \u0142atwa zmiana zachowania. Stosuje si\u0119 j\u0105 r\u00f3wnie\u017c do delegacji zdarze\u0144.<\/p>\n

\"10
\n
\nWszystkie te zasady pozwalaj\u0105 pisa\u0107 bardziej elastyczny, estetyczny i niezawodny kod z wysok\u0105 sp\u00f3jno\u015bci\u0105 i niskim sprz\u0119\u017ceniem. Oczywi\u015bcie, teoria jest dobra, ale aby programista naprawd\u0119 zacz\u0105\u0142 wykorzystywa\u0107 zdobyt\u0105 wiedz\u0119, potrzebna jest praktyka. Nast\u0119pnym krokiem po opanowaniu zasad OOP mo\u017ce by\u0107 nauka wzorc\u00f3w projektowych do rozwi\u0105zywania powszechnych problem\u00f3w w rozwoju oprogramowania.<\/p>\n

Skillbox poleca:<\/b><\/p>\n