{"id":29845,"date":"2023-05-17T08:51:48","date_gmt":"2023-05-17T06:51:48","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/zasady-solid-dobre-praktyki-w-programowaniu\/"},"modified":"2024-11-07T15:15:00","modified_gmt":"2024-11-07T14:15:00","slug":"zasady-solid-dobre-praktyki-w-programowaniu","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/zasady-solid-dobre-praktyki-w-programowaniu\/","title":{"rendered":"Zasady SOLID w programowaniu obiektowym"},"content":{"rendered":"\n
\n

PRZEJD\u0179 DO:<\/p>\n

    \n
  1. 1. Po pierwsze, czysty kod <\/a><\/li>\n
  2. 2. Czym jest SOLID w programowaniu? <\/a><\/li>\n
  3. 3. Najwa\u017cniejsze zasady SOLID <\/a><\/li>\n
  4. 4. SOLID \u2013 przyk\u0142ady z wykorzystaniem Angulara <\/a><\/li>\n
  5. 5. Podsumowanie\u00a0<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    Po pierwsze, czysty kod<\/h2>\n\n\n\n

    Pisanie czystego kodu (ang. clean code<\/strong>) powinno by\u0107 kluczowym elementem w pracy ka\u017cdego programisty. To w\u0142a\u015bnie czysty kod pozwala nam utrzymywa\u0107 nasze systemy w dobrym stanie, zapewniaj\u0105c \u0142atwo\u015b\u0107 w utrzymaniu i rozwoju oraz wi\u0119ksz\u0105 elastyczno\u015b\u0107. Dlaczego jeszcze dbanie o czysty kod jest tak wa\u017cne? Wed\u0142ug raportu \u201eThe state of software code”, 40% developer\u00f3w przyznaje, \u017ce najbardziej frustruje ich wykrywanie i naprawiane b\u0142\u0119d\u00f3w w kodzie<\/strong>, co nieraz mo\u017ce przyczynia\u0107 si\u0119 do przepracowania, a nawet wypalenia zawodowego. Nie wspominaj\u0105c o op\u00f3\u017anieniach w rozwoju oprogramowania.<\/p>\n\n\n\n

    Czysty kod to taki, kt\u00f3ry jest czytelny, \u0142atwy do zrozumienia, modyfikacji i testowania. \u0141atwo\u015b\u0107 w zrozumieniu kodu jest szczeg\u00f3lnie wa\u017cna w przypadku wi\u0119kszych projekt\u00f3w, gdzie nad tymi samymi plikami pracuje zwykle wiele os\u00f3b. Zw\u0142aszcza w tego typu projektach powinni\u015bmy d\u0105\u017cy\u0107 do tego, aby pisany przez nas kod by\u0142 przejrzysty i klarowny, nawet dla os\u00f3b, kt\u00f3re nie pracowa\u0142y nad danym projektem od samego pocz\u0105tku. Tu z pomoc\u0105 przychodz\u0105 zasady znane jako SOLID.<\/p>\n\n\n\n

    Czym jest SOLID w programowaniu?<\/h2>\n\n\n\n

    SOLID to zestaw pi\u0119ciu zasad, kt\u00f3re zosta\u0142y opracowane przez Roberta C. Martina, znanego jako \u201eUncle Bob<\/strong>\u201d, w latach 90. XX wieku. Dzi\u0119ki tym zasadom otrzymali\u015bmy narz\u0119dzia, kt\u00f3re nie tylko pomagaj\u0105 w projektowaniu i implementacji system\u00f3w, ale tak\u017ce umo\u017cliwiaj\u0105 ich utrzymywanie, rozw\u00f3j i skalowanie. Korzystanie z tych zasad cz\u0119sto pozwala znacz\u0105co skr\u00f3ci\u0107 czas pracy nad projektem oraz zmniejszy\u0107 ilo\u015b\u0107 b\u0142\u0119d\u00f3w, co przek\u0142ada si\u0119 na zwi\u0119kszenie efektywno\u015bci i jako\u015bci samego kodu.<\/p>\n\n\n\n

    Najwa\u017cniejsze zasady SOLID<\/h2>\n\n\n\n

    W tym artykule o SOLID om\u00f3wi\u0119 zasady, na kt\u00f3rych opiera si\u0119 filozofia pisania czystego kodu. SOLID to skr\u00f3towiec utworzony od pi\u0119ciu zasad projektowania obiektowego, kt\u00f3rych celem jest u\u0142atwienie modyfikowania, skalowania i utrzymywania kodu. <\/p>\n\n\n\n

    Single Responsibility Principle <\/h3>\n\n\n\n

    Pierwsz\u0105 z zasad SOLID jest zasada pojedynczej odpowiedzialno\u015bci (ang. Single Responsibility Principle \u2013 SPR<\/strong>). Zgodnie z ni\u0105 klasa powinna mie\u0107 tylko jedn\u0105 odpowiedzialno\u015b\u0107, czyli powinna by\u0107 odpowiedzialna tylko za jedn\u0105 rzecz. O ile nie mo\u017cna jednoznacznie stwierdzi\u0107, kt\u00f3ra zasada SOLID jest najwa\u017cniejsza, poniewa\u017c ka\u017cda zasada wp\u0142ywa na jako\u015b\u0107 kodu w r\u00f3\u017cny spos\u00f3b, o tyle wielu programist\u00f3w uwa\u017ca, \u017ce to w\u0142a\u015bnie zasada pojedynczej odpowiedzialno\u015bci jest absolutnym minimum, kt\u00f3re ka\u017cdy z nas powinien stosowa\u0107 w swoim kodzie. <\/p>\n\n\n\n

    Open\/Closed Principle <\/h3>\n\n\n\n

    Drug\u0105 wa\u017cn\u0105 zasad\u0105 jest zasada otwarte\/zamkni\u0119te (ang. Open\/Closed Principle \u2013 OCP<\/strong>). Wed\u0142ug tej zasady klasa powinna by\u0107 otwarta na rozszerzanie, ale jednocze\u015bnie zamkni\u0119ta na modyfikacj\u0119. To oznacza, \u017ce gdy chcemy doda\u0107 now\u0105 funkcjonalno\u015b\u0107 do naszej aplikacji, nie powinni\u015bmy modyfikowa\u0107 istniej\u0105cego kodu, a jedynie dodawa\u0107 nowy. Dzi\u0119ki temu zmiany w jednej cz\u0119\u015bci systemu nie spowoduj\u0105 awarii w innych jego cz\u0119\u015bciach. <\/p>\n\n\n\n

    Liskov Substitution Principle <\/h3>\n\n\n\n

    Kolejn\u0105 zasad\u0105 jest zasada podstawienia Liskov (ang. Liskov Substitution Principle \u2013 LSP<\/strong>). Zasada ta okre\u015bla, \u017ce obiekty typu pochodnego powinny by\u0107 zawsze zast\u0119powalne przez obiekty typu bazowego. To oznacza, \u017ce klasa dziedzicz\u0105ca powinna by\u0107 w pe\u0142ni zgodna z klas\u0105, po kt\u00f3rej dziedziczy. Dzi\u0119ki tej zasadzie mo\u017cemy unikn\u0105\u0107 b\u0142\u0119d\u00f3w wynikaj\u0105cych z niezgodno\u015bci mi\u0119dzy klasami, a tak\u017ce u\u0142atwi\u0107 sobie przysz\u0142y rozw\u00f3j aplikacji. <\/p>\n\n\n\n

    Interface Segregation Principle <\/h3>\n\n\n\n

    Czwart\u0105 zasad\u0105 jest zasada segregacji interfejs\u00f3w (ang. Interface Segregation Principle \u2013 ISP<\/strong>). Wed\u0142ug niej interfejsy powinny by\u0107 ma\u0142e i jednorodne, a klienci powinni korzysta\u0107 tylko z tych, kt\u00f3rych potrzebuj\u0105. Oznacza to, \u017ce klasa powinna implementowa\u0107 tylko te metody, kt\u00f3rych potrzebuje, a wi\u0119c interfejs nie powinien zmusza\u0107 jej do implementacji pozosta\u0142ych metod. To pozwala unikn\u0105\u0107 skomplikowania kodu. <\/p>\n\n\n\n

    Dependency Inversion Principle <\/h3>\n\n\n\n

    Pi\u0105t\u0105 i ostatni\u0105 zasad\u0105 SOLID jest zasada odwr\u00f3cenia zale\u017cno\u015bci (ang. Dependency Inversion Principle \u2013 DIP<\/strong>). Zgodnie z ni\u0105 zale\u017cno\u015bci mi\u0119dzy klasami powinny by\u0107 odwr\u00f3cone. Oznacza to, \u017ce klasy powinny zale\u017ce\u0107 od abstrakcji, a nie od konkretnych implementacji. Dzi\u0119ki temu kod jest \u0142atwiejszy do testowania i modyfikowania.  <\/p>\n\n\n\n

    Dlaczego zasady SOLID s\u0105 tak wa\u017cne?  <\/h3>\n\n\n\n

    Podsumowuj\u0105c, zasady SOLID s\u0105 kluczowe dla tworzenia skalowalnych, elastycznych i \u0142atwych w utrzymaniu aplikacji. Wymagaj\u0105 one od nas abstrakcyjnego my\u015blenia, projektowania i wdra\u017cania czytelnego kodu. W\u0142a\u015bciwe stosowanie zasad SOLID pozwala unikn\u0105\u0107 licznych problem\u00f3w, takich jak trudno\u015b\u0107 we wprowadzaniu zmian i testowaniu czy nieczytelno\u015b\u0107 i niejednoznaczno\u015b\u0107 kodu. <\/p>\n\n\n\n

    W kolejnych rozdzia\u0142ach skupi\u0119 si\u0119 na ka\u017cdej z zasad SOLID, rozwin\u0119 ich znaczenie i om\u00f3wi\u0119 przyk\u0142ady, dzi\u0119ki czemu b\u0119dziemy w stanie lepiej zrozumie\u0107, jak mo\u017cna stosowa\u0107 je w praktyce.<\/p>\n\n\n\n

    Przeczytaj tak\u017ce: <\/strong>Kt\u00f3ry\u00a0framework frontendowy jest najlepszy?<\/a><\/p>\n\n\n\n

    SOLID \u2013 przyk\u0142ady z wykorzystaniem Angulara  <\/h2>\n\n\n\n

    Zasada pojedynczej odpowiedzialno\u015bci <\/h3>\n\n\n\n

    Zasada pojedynczej odpowiedzialno\u015bci ma na celu popraw\u0119 jako\u015bci kodu i u\u0142atwienie jego rozwijania. Zgodnie z ni\u0105 ka\u017cdy element kodu powinien mie\u0107 tylko jedn\u0105 odpowiedzialno\u015b\u0107, a zmiany w jednej funkcjonalno\u015bci nie powinny wp\u0142ywa\u0107 na pozosta\u0142e. Innymi s\u0142owy, klasa, funkcja czy modu\u0142 powinny robi\u0107 tylko to, do czego zosta\u0142y stworzone i nie powinny mie\u0107 dodatkowych zada\u0144, kt\u00f3re nie s\u0105 zwi\u0105zane z ich g\u0142\u00f3wn\u0105 odpowiedzialno\u015bci\u0105.  <\/p>\n\n\n\n

    Zastosowanie zasady pojedynczej odpowiedzialno\u015bci przynosi wiele korzy\u015bci. Przede wszystkim u\u0142atwia utrzymywanie i rozwijanie kodu<\/strong>, poniewa\u017c kod staje si\u0119 bardziej modularny i \u0142atwiej jest zidentyfikowa\u0107 miejsca, w kt\u00f3rych nale\u017cy dokona\u0107 zmian. Ponadto, dzi\u0119ki temu, \u017ce ka\u017cdy element ma tylko jedn\u0105 odpowiedzialno\u015b\u0107, \u0142atwiej jest go testowa\u0107 i staje si\u0119 on du\u017co bardziej zrozumia\u0142y dla innych programist\u00f3w. <\/p>\n\n\n\n

    W jaki spos\u00f3b mo\u017cemy rozpozna\u0107, \u017ce zasada pojedynczej odpowiedzialno\u015bci nie jest spe\u0142niona? Cz\u0119sto nie jest \u0142atwo zidentyfikowa\u0107 miejsce, w kt\u00f3rym ko\u0144czy si\u0119 odpowiedzialno\u015b\u0107 jednego komponentu, a zaczyna drugiego. Z pomoc\u0105 przychodzi regu\u0142a wykorzystuj\u0105ca sp\u00f3jnik \u201ci\u201d. Je\u015bli opisuj\u0105c odpowiedzialno\u015b\u0107 danego elementu u\u017cyjemy s\u0142owa \u201ci\u201d, mo\u017cemy potraktowa\u0107 to jako sygna\u0142, \u017ce nasz element zajmuje si\u0119 zbyt wieloma rzeczami \u2013 jego odpowiedzialno\u015b\u0107 nie jest pojedyncza.  <\/p>\n\n\n\n

    Zar\u00f3wno ten przyk\u0142ad, jak i wszystkie kolejne b\u0119d\u0105 napisane we frameworku Angular. We\u017amy komponent DataComponent<\/strong>, kt\u00f3rego zadaniem jest pobranie danych z serwera i<\/strong> ich przetworzenie i <\/strong>ich wy\u015bwietlenie. W opisie odpowiedzialno\u015bci natrafili\u015bmy na s\u0142owo \u201ci\u201d, co mo\u017ce oznacza\u0107, \u017ce b\u0119dziemy potrzebowali udoskonali\u0107 nasz kod. <\/p>\n\n\n\n

    <\/div>\n\n\n\n
    @Component({ \n\n  selector: 'app-data', \n\n  template: ` \n\n    <ul> \n\n      <li *ngFor=\"let item of items\"> \n\n        {{ item }} \n\n      <\/li> \n\n    <\/ul> \n\n  `, \n\n}) \n\nexport class DataComponent implements OnInit { \n\n  items: string[] = []; \n\n \n\n  constructor(private http: HttpClient) {} \n\n \n\n  ngOnInit(): void { \n\n    this.http.get<Item[]>('http:\/\/example.com\/data').subscribe((data: Item[]) => { \n\n      this.items = data.map((item) => item.name.toUpperCase()); \n\n    }); \n\n  }   \n\n}<\/pre>\n\n\n\n
    I faktycznie takie podej\u015bcie \u0142amie zasad\u0119 pojedynczej odpowiedzialno\u015bci, poniewa\u017c komponent ten powinien by\u0107 odpowiedzialny tylko za prezentacj\u0119 danych. Aby go poprawi\u0107 i spe\u0142ni\u0107 zasad\u0119 pojedynczej odpowiedzialno\u015bci, mo\u017cemy wydzieli\u0107 logik\u0119 pobierania danych i ich przetwarzania do oddzielnych serwis\u00f3w. Nasz komponent i wydzielone serwisy b\u0119d\u0105 wtedy wygl\u0105da\u0142y tak: <\/p>\n\n\n\n
    <\/div>\n\n\n\n
    @Component({ \n\n  selector: 'app-data', \n\n  template: ` \n\n    <ul> \n\n      <li *ngFor=\"let item of items\"> \n\n        {{ item }} \n\n      <\/li> \n\n    <\/ul> \n\n  `, \n\n}) \n\nexport class DataComponent implements OnInit { \n\n  items: string[] = []; \n\n \n\n  constructor(private itemsService: ItemsService,  \n\n    private dataService: DataService) {} \n\n \n\n  ngOnInit(): void { \n\n    this.itemsService.getItems().subscribe((items) => { \n\n      this.items = this.dataService.processData(items); \n\n    }); \n\n  }   \n\n} \n\n \n\n@Injectable() \n\nexport class ItemsService { \n\n  constructor(private http: HttpClient) { } \n\n \n\n  getItems(): Observable<Item[]> { \n\n    return this.http.get<Item[]>('http:\/\/example.com\/data'); \n\n  } \n\n} \n\n \n\n@Injectable() \n\nexport class DataService { \n\n  processData(data: Item[]): string[] { \n\n    return data.map((item) => item.name.toUpperCase()); \n\n  } \n\n}<\/pre>\n\n\n\n
    Dzi\u0119ki takiemu podej\u015bciu odpowiedzialno\u015b\u0107 zosta\u0142a rozproszona, a ka\u017cdy z obiekt\u00f3w ma tylko jedn\u0105. <\/p>\n\n\n\n