Zasady SOLID - jak programować zgodnie z dobrymi praktykami

W świecie programowania, zwłaszcza w programowaniu obiektowym, istnieje wiele zasad i praktyk, które pomagają programistom pisać kod, który jest łatwiejszy do zrozumienia, utrzymania i dalszego rozwijania.

Czym jest SOLID ?

Jednym z najbardziej znanych zestawów takich zasad jest SOLID – akronim, który składa się z pierwszych liter pięciu kluczowych zasad programowania obiektowego:

Single Responsibility Principle (zasada pojedynczej 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ócenia zależności).

Zasady SOLID zostały po raz pierwszy przedstawione przez Roberta C. Martina, znanego również jako "Uncle Bob", i stanowią fundament dla tworzenia dobrze zaprojektowanego i czystego kodu.

Celem tych zasad jest ułatwienie programistom tworzenia kodu, który jest bardziej elastyczny, łatwiejszy do testowania i mniej podatny na błędy.

W tym wpisie przyjrzymy się bliżej każdej z tych zasad, omówię ich znaczenie i przekonasz się, jak stosowanie zasad SOLID może przynieść korzyści w Twojej codziennej pracy.

Jeśli jesteś początkującym programistą, ten przewodnik pomoże Ci zrozumieć, dlaczego warto stosować zasady SOLID i jak mogą one wpłynąć na jakość Twojego kodu.

Zasada pojedynczej odpowiedzialności (Single Responsibility Principle - SRP)

Wyobraź sobie, że masz klasę w swoim kodzie, która robi mnóstwo różnych rzeczy – zapisuje dane do bazy, wysyła e-maile, generuje raporty, i tak dalej.

Taki kod może szybko stać się trudny do ogarnięcia i utrzymania. SRP mówi nam, że każda klasa powinna mieć tylko jeden powód do zmiany, czyli jedną odpowiedzialność.

Innymi słowy, klasa powinna zajmować się tylko jednym zadaniem. Jeśli masz klasę, która zajmuje się zapisaniem danych do bazy, to niech ona zajmuje się tylko tym. Jeśli inna klasa wysyła e-maile, to niech zajmuje się tylko wysyłaniem e-maili.

Po co to wszystko? Kiedy każda klasa ma tylko jedną odpowiedzialność, kod staje się bardziej przejrzysty i łatwiejszy do zarządzania.

Jeśli coś przestanie działać albo trzeba będzie coś zmienić, wiesz dokładnie, gdzie szukać i co zmieniać. Unikasz też sytuacji, gdzie zmiana jednej rzeczy powoduje lawinę zmian w różnych miejscach kodu.

W skrócie, SRP to zasada, która mówi, że każda klasa powinna mieć tylko jedną odpowiedzialność. Dzięki temu kod jest prostszy, bardziej przejrzysty i łatwiejszy w utrzymaniu. To taka złota zasada, która pomaga utrzymać porządek w projekcie.

Przykład zastosowania Single Responsibility Principle - SRP

Załóżmy, że mamy klasę UserManager, która zajmuje się tworzeniem użytkowników, zapisywaniem ich do bazy danych i wysyłaniem e-maili powitalnych.

Przed zastosowaniem SRP mogłoby to wyglądać tak:

javascript

class UserManager {
  createUser(username, email) {
    const user = { username, email };
    this.saveUserToDatabase(user);
    this.sendWelcomeEmail(user);
    return user;
  }

  saveUserToDatabase(user) {
    // Kod do zapisywania użytkownika do bazy danych
    console.log(`User ${user.username} saved to database.`);
  }

  sendWelcomeEmail(user) {
    // Kod do wysyłania e-maila powitalnego
    console.log(`Welcome email sent to ${user.email}.`);
  }
}

const userManager = new UserManager();
userManager.createUser('john_doe', 'john@example.com');

Ta klasa UserManager ma zbyt wiele odpowiedzialności. Teraz podzielimy ją na trzy klasy, z których każda ma jedną odpowiedzialność:

javascript

class UserCreator {
  createUser(username, email) {
    return { username, email };
  }
}

class UserRepository {
  saveUserToDatabase(user) {
    // Kod do zapisywania użytkownika do bazy danych
    console.log(`User ${user.username} saved to database.`);
  }
}

class EmailService {
  sendWelcomeEmail(user) {
    // Kod do wysyłania e-maila powitalnego
    console.log(`Welcome email sent to ${user.email}.`);
  }
}

// Użycie klas zgodnie z SRP
const userCreator = new UserCreator();
const userRepository = new UserRepository();
const emailService = new EmailService();

const user = userCreator.createUser('john_doe', 'john@example.com');
userRepository.saveUserToDatabase(user);
emailService.sendWelcomeEmail(user);

Co tutaj się dzieje w kodzie:

UserCreator zajmuje się tylko tworzeniem obiektu użytkownika.
UserRepository zajmuje się tylko zapisywaniem użytkownika do bazy danych.
EmailService zajmuje się tylko wysyłaniem e-maili.

Każda klasa ma teraz tylko jedną odpowiedzialność, co jest zgodne z zasadą SRP. Dzięki temu kod jest bardziej modularny, łatwiejszy do zrozumienia i utrzymania.

Zasada otwarte-zamknięte (Open-Closed Principle - OCP)

Zasada otwarte-zamknięte, czyli Open-Closed Principle (OCP), to jedna z podstawowych zasad SOLID, która mówi, że kod powinien być otwarty na rozszerzenia, ale zamknięty na modyfikacje.

Co to oznacza w praktyce?

Chodzi o to, że kiedy chcesz dodać nową funkcjonalność do swojego programu, powinieneś móc to zrobić, dodając nowy kod, a nie zmieniając istniejący.

Dlaczego to ważne? Kiedy modyfikujesz istniejący kod, ryzykujesz wprowadzenie nowych błędów i problemów.

Lepiej jest dodać nową funkcjonalność w sposób, który nie narusza już działających części programu.

Przykład przed zastosowaniem OCP

Załóżmy, że mamy klasę Employee z metodą calculateBonus, która określa wysokość premii dla zwykłych pracowników i menedżerów.

javascript

class Employee {
  constructor(name, type) {
    this.name = name;
    this.type = type;
  }

  calculateBonus(salary) {
    if (this.type === 'regular') {
      return salary * 0.1;
    } else if (this.type === 'manager') {
      return salary * 0.2;
    }
    return 0;
  }
}

const regularEmployee = new Employee('John Doe', 'regular');
const managerEmployee = new Employee('Jane Smith', 'manager');

console.log(regularEmployee.calculateBonus(1000)); // 100
console.log(managerEmployee.calculateBonus(1000)); // 200

Jeśli chcielibyśmy dodać nowy typ pracownika, na przykład stażystę, musielibyśmy zmodyfikować metodę calculateBonus, co narusza zasadę OCP.

Przykład po zastosowaniu OCP

Zastosujemy zasadę OCP, tworząc nową strukturę kodu, która pozwoli nam dodawać nowe typy pracowników bez modyfikowania istniejącego kodu.

javascript

class Employee {
  constructor(name) {
    this.name = name;
  }

  calculateBonus(salary) {
    throw new Error('calculateBonus method should be implemented');
  }
}

class RegularEmployee extends Employee {
  calculateBonus(salary) {
    return salary * 0.1;
  }
}

class ManagerEmployee extends Employee {
  calculateBonus(salary) {
    return salary * 0.2;
  }
}

class InternEmployee extends Employee {
  calculateBonus(salary) {
    return salary * 0.05;
  }
}

const regularEmployee = new RegularEmployee('John Doe');
const managerEmployee = new ManagerEmployee('Jane Smith');
const internEmployee = new InternEmployee('Jim Brown');

console.log(regularEmployee.calculateBonus(1000)); // 100
console.log(managerEmployee.calculateBonus(1000)); // 200
console.log(internEmployee.calculateBonus(1000)); // 50

Co dzieje się w kodzie:

Mamy klasę Employee, która definiuje interfejs (metodę calculateBonus).
Tworzymy podklasy RegularEmployee, ManagerEmployee i InternEmployee, które rozszerzają klasę Employee i implementują metodę calculateBonus.

Dzięki temu, jeśli w przyszłości będziemy chcieli dodać nowy typ pracownika, wystarczy stworzyć nową podklasę, bez konieczności modyfikowania istniejącego kodu.

To właśnie jest zasada otwarte-zamknięte w praktyce – nasz kod jest otwarty na rozszerzenia (dodawanie nowych typów pracowników), ale zamknięty na modyfikacje (nie musimy zmieniać istniejącej logiki).

Zasada podstawienia Liskov (Liskov Substitution Principle - LSP)

Zasada podstawienia Liskov, czyli Liskov Substitution Principle (LSP), to jedna z kluczowych zasad SOLID. Mówi ona, że obiekty klasy bazowej powinny być wymienialne z obiektami klasy pochodnej bez wpływu na poprawność programu.

Chodzi o to, że jeśli klasa B dziedziczy po klasie A, powinniśmy móc zastąpić obiekty klasy A obiektami klasy B bez powstania błędów.

Dlaczego to ważne? Dzięki LSP możemy tworzyć bardziej elastyczny i łatwiejszy do utrzymania kod.

Klasy pochodne powinny w pełni respektować kontrakt określony przez klasę bazową, co oznacza, że nie powinny zmieniać zachowania metod odziedziczonych w sposób, który zaskoczy użytkowników tych klas.

Przykład bez zastosowania LSP

Załóżmy, że mamy klasę Bird z metodą fly, oraz klasy Sparrow (wróbel) i Penguin (pingwin), które dziedziczą po Bird.

javascript

class Bird {
  fly() {
    console.log('I am flying!');
  }
}

class Sparrow extends Bird {
  // Wróbel potrafi latać, więc nie ma potrzeby nadpisywania metody fly
}

class Penguin extends Bird {
  fly() {
    throw new Error('Penguins cannot fly!');
  }
}

function makeBirdFly(bird) {
  bird.fly();
}

const sparrow = new Sparrow();
const penguin = new Penguin();

makeBirdFly(sparrow); // Works fine: 'I am flying!'
makeBirdFly(penguin); // Throws error: 'Penguins cannot fly!'

W tym przypadku, Penguin dziedziczy po Bird, ale nie może latać, co łamie zasadę LSP. Funkcja makeBirdFly przestaje działać poprawnie, gdy przekażemy do niej obiekt Penguin.

Przykład z zastosowaniem zasady LSP

Teraz zastosujemy zasadę LSP, aby klasy były zgodne z tym co pochodzi od klasy bazowej:

javascript

class Bird {
  move() {
    console.log('I am moving!');
  }
}

class FlyingBird extends Bird {
  fly() {
    console.log('I am flying!');
  }
}

class Sparrow extends FlyingBird {
  // Wróbel potrafi latać, więc nie ma potrzeby nadpisywania metody fly
}

class Penguin extends Bird {
  // Penguins cannot fly, but they can move
  move() {
    console.log('I am swimming!');
  }
}

function makeBirdMove(bird) {
  bird.move();
}

const sparrow = new Sparrow();
const penguin = new Penguin();

makeBirdMove(sparrow); // Działa prawidłowo: 'I am moving!'
makeBirdMove(penguin); // Działa prawidłowo: 'I am swimming!'

Wyjaśnienie kodu powyżej

Mamy klasę Bird, która ma metodę move.
Mamy klasę FlyingBird, która dziedziczy po Bird i dodaje metodę fly.
Sparrow dziedziczy po FlyingBird i może latać.
Penguin dziedziczy po Bird i może się poruszać (pływać), ale nie może latać.

Dzięki temu, każda klasa pochodna w pełni respektuje kontrakt określony przez klasę bazową, a obiekty klasy bazowej mogą być bezpiecznie zastępowane obiektami klas pochodnych, co jest zgodne z zasadą LSP.

Zasada segregacji interfejsów (Interface Segregation Principle - ISP)

Zasada segregacji interfejsów, czyli Interface Segregation Principle (ISP) mówi, że interfejsy powinny być małe i specyficzne dla danego klienta, zamiast jednego dużego, który zmusza klasy do implementacji metod, których nie potrzebują.

Chodzi o to, że lepiej jest mieć wiele wyspecjalizowanych interfejsów niż jeden duży.

Dlaczego to ważne? Jeśli klasa musi implementować metody, których nie używa, staje się bardziej skomplikowana i trudniejsza w utrzymaniu. ISP pomaga unikać tego problemu, dzieląc duże interfejsy na mniejsze, bardziej spójne.

Przykład przed zastosowaniem ISP

Najpierw zobaczmy, jak to mogłoby wyglądać bez zastosowania ISP:

javascript

class Worker {
  work() {
    console.log('Working...');
  }

  eat() {
    console.log('Eating...');
  }
}

class Programmer extends Worker {
  // Programista musi pracować, ale niekoniecznie jeść
}

class Chef extends Worker {
  // Szef kuchni musi zarówno pracować, jak i jeść
}

function makeWorkerWork(worker) {
  worker.work();
}

const programmer = new Programmer();
const chef = new Chef();

makeWorkerWork(programmer); // Działa prawidłowo: 'Working...'
makeWorkerWork(chef); // Działa prawidłowo: 'Working...'

W tym przypadku Programmer dziedziczy metody work i eat, mimo że metoda eat może nie być dla niego istotna.

Przykład po zastosowaniu ISP

Teraz zastosujemy zasadę ISP, aby nasze interfejsy były bardziej spójne i specyficzne:

javascript

class Worker {
  work() {
    console.log('Working...');
  }
}

class Eater {
  eat() {
    console.log('Eating...');
  }
}

class Programmer extends Worker {
  // Programista musi pracować
}

class Chef extends Worker {
  // Szef kuchni musi pracować i jeść
}

Object.assign(Chef.prototype, new Eater());

function makeWorkerWork(worker) {
  worker.work();
}

function makeWorkerEat(eater) {
  eater.eat();
}

const programmer = new Programmer();
const chef = new Chef();

makeWorkerWork(programmer); // Działa prawidłowo: 'Working...'
makeWorkerWork(chef); // Działa prawidłowo: 'Working...'
makeWorkerEat(chef); // Działa prawidłowo: 'Eating...'

Jak działą kod powyżej:

Mamy osobne klasy Worker i Eater z odpowiednimi metodami.
Programmer dziedziczy tylko po Worker i ma tylko metodę work.
Chef dziedziczy po Worker i dodatkowo implementuje interfejs Eater, aby mieć metodę eat.

Dzięki temu podziale, klasy implementują tylko te interfejsy i metody, które są dla nich istotne, co jest zgodne z zasadą ISP.

Programista nie musi implementować metody eat, a kucharz może mieć zarówno metodę work, jak i eat, bez zbędnego kodu.

Zasada odwrócenia zależności (Dependency Inversion Principle - DIP)

Zasada odwrócenia zależności, czyli Dependency Inversion Principle (DIP) mówi, że moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych.

Oba rodzaje modułów powinny zależeć od abstrakcji (interfejsów).

Mówiąc prościej, zależności w kodzie powinny być odwrócone tak, aby konkretne implementacje zależały od abstrakcji, a nie na odwrót.

Dlaczego to ważne? Dzięki DIP możemy tworzyć bardziej elastyczny i łatwiejszy do utrzymania kod.

Kiedy nasze moduły wysokopoziomowe zależą od abstrakcji, a nie od konkretnych implementacji, łatwiej jest zmieniać lub zastępować te implementacje bez wpływu na resztę systemu.

Przykład przed zastosowaniem DIP

Najpierw zobaczmy, jak mogłoby to wyglądać bez zastosowania DIP:

javascript

class EmailService {
  sendEmail(message) {
    console.log(`Sending email: ${message}`);
  }
}

class NotificationManager {
  constructor() {
    this.emailService = new EmailService();
  }

  sendNotification(message) {
    this.emailService.sendEmail(message);
  }
}

const notificationManager = new NotificationManager();
notificationManager.sendNotification('Hello, World!'); // Sending email: Hello, World!

W tym przypadku NotificationManager jest bezpośrednio zależny od EmailService. Jeśli chcielibyśmy zmienić sposób wysyłania powiadomień (np. na SMS), musielibyśmy zmodyfikować NotificationManager.

Przykład po zastosowaniu DIP

Teraz zastosujemy zasadę DIP, aby nasze moduły były niezależne od konkretnych implementacji:

javascript

// Definiujemy interfejs
class Notifier {
  send(message) {
    throw new Error('Method not implemented');
  }
}

class EmailService extends Notifier {
  send(message) {
    console.log(`Sending email: ${message}`);
  }
}

class SMSService extends Notifier {
  send(message) {
    console.log(`Sending SMS: ${message}`);
  }
}

class NotificationManager {
  constructor(notifier) {
    this.notifier = notifier;
  }

  sendNotification(message) {
    this.notifier.send(message);
  }
}

const emailService = new EmailService();
const smsService = new SMSService();

const notificationManagerWithEmail = new NotificationManager(emailService);
const notificationManagerWithSMS = new NotificationManager(smsService);

notificationManagerWithEmail.sendNotification('Hello, World!'); // Sending email: Hello, World!
notificationManagerWithSMS.sendNotification('Hello, World!'); // Sending SMS: Hello, World!

Co dzieje się w kodzie:

Definiujemy interfejs Notifier z metodą send.
EmailService i SMSService implementują interfejs Notifier.
NotificationManager jest zależny od abstrakcji Notifier, a nie od konkretnej implementacji.

Dzięki temu, jeśli chcemy zmienić sposób wysyłania powiadomień, możemy po prostu podać inną implementację Notifier do NotificationManager, bez konieczności modyfikowania samego NotificationManager.

To jest właśnie zasada odwrócenia zależności w praktyce – nasze moduły wysokopoziomowe (takie jak NotificationManager) są niezależne od modułów niskopoziomowych (takich jak EmailService czy SMSService), a zależą tylko od abstrakcji (interfejsu Notifier).

Podsumowanie: Jak stosowanie zasad SOLID wpływa na jakość kodu

Stosowanie zasad SOLID w programowaniu ma ogromny wpływ na jakość kodu, a także na jego utrzymanie i rozwój.

Jakie są główne korzyści wynikające z przestrzegania zasad SOLID:

Lepsza modularność:
- Single Responsibility Principle (SRP): Każda klasa ma tylko jedną odpowiedzialność, co sprawia, że kod jest bardziej przejrzysty i łatwiejszy do zrozumienia. Moduły są małe i skupione na jednym zadaniu, co ułatwia ich modyfikację i rozwój.
Łatwiejsze rozszerzanie funkcjonalności:
- Open/Closed Principle (OCP): Kod jest otwarty na rozszerzenia, ale zamknięty na modyfikacje. Nowe funkcje można dodawać poprzez rozszerzanie istniejących klas lub modułów, bez konieczności ingerowania w już działający kod, co minimalizuje ryzyko wystąpienia błędów.
Poprawiona kompatybilność i elastyczność:
- Liskov Substitution Principle (LSP): Klasy pochodne mogą zastępować klasy bazowe bez zmiany poprawności programu. To umożliwia tworzenie elastycznych hierarchii klas i ułatwia zarządzanie kodem, który jest bardziej zgodny z zasadą DRY (Don't Repeat Yourself).
Unikanie zbędnych zależności:
- Interface Segregation Principle (ISP): Preferowanie wielu specyficznych interfejsów zamiast jednego dużego sprawia, że klasy implementują tylko te metody, które naprawdę są im potrzebne. Dzięki temu kod jest bardziej zwięzły i mniej skomplikowany.
Luźne powiązania między komponentami:
- Dependency Inversion Principle (DIP): Moduły wysokopoziomowe nie zależą od modułów niskopoziomowych, lecz od abstrakcji. To prowadzi do luźniejszych powiązań między komponentami, co ułatwia ich wymianę i testowanie.

Jak to wpływa na jakość kodu?

Łatwiejsze utrzymanie:
- Kod zgodny z zasadami SOLID jest bardziej przewidywalny i łatwiejszy do zrozumienia. Mniejsze klasy z jasno zdefiniowanymi odpowiedzialnościami są łatwiejsze do testowania i debugowania.
Większa skalowalność:
- Dzięki modularnej strukturze kodu, nowe funkcjonalności można dodawać w sposób łatwy i bezpieczny. Unikanie modyfikacji istniejącego kodu zmniejsza ryzyko wprowadzania błędów i ułatwia skalowanie aplikacji.
Poprawiona czytelność:
- Zasady SOLID promują pisanie kodu, który jest intuicyjny i czytelny dla innych programistów. Jasno zdefiniowane odpowiedzialności i użycie abstrakcji sprawiają, że kod jest bardziej zrozumiały.
Ulepszona testowalność:
- Moduły, które są zgodne z zasadami SOLID, są bardziej niezależne i łatwiejsze do testowania jednostkowego. Luźne powiązania i zależności od abstrakcji umożliwiają łatwiejsze mockowanie podczas testowania.
Większa elastyczność:
- Kod napisany zgodnie z zasadami SOLID jest bardziej elastyczny w kontekście zmian. Możliwość wprowadzania nowych funkcji bez modyfikowania istniejącego kodu pozwala na szybsze reagowanie na zmieniające się wymagania biznesowe.

Podsumowując, stosowanie zasad SOLID prowadzi do tworzenia wysokiej jakości kodu, który jest łatwiejszy do utrzymania, bardziej skalowalny, czytelniejszy, łatwiej testowalny i elastyczny. To fundament, na którym warto budować każdą aplikację.

FAQ: Co to jest SOLID?

1. Co oznacza akronim SOLID?

SOLID to akronim składający się z pierwszych liter pięciu zasad programowania obiektowego, które mają na celu poprawę jakości kodu. Te zasady to:

Single Responsibility Principle (SRP) – Zasada pojedynczej odpowiedzialności
Open/Closed Principle (OCP) – Zasada otwarte-zamknięte
Liskov Substitution Principle (LSP) – Zasada podstawienia Liskov
Interface Segregation Principle (ISP) – Zasada segregacji interfejsów
Dependency Inversion Principle (DIP) – Zasada odwrócenia zależności

2. Dlaczego zasady SOLID są ważne?

Zasady SOLID pomagają programistom pisać kod, który jest łatwiejszy do zrozumienia, utrzymania i rozwijania. Dzięki stosowaniu tych zasad, kod staje się bardziej modularny, elastyczny i mniej podatny na błędy.

3. Co to jest Zasada pojedynczej odpowiedzialności (SRP)?

Zasada pojedynczej odpowiedzialności mówi, że każda klasa powinna mieć tylko jedną odpowiedzialność, czyli jeden powód do zmiany. Dzięki temu kod jest bardziej przejrzysty i łatwiejszy do utrzymania.

4. Co to jest Zasada otwarte-zamknięte (OCP)?

Zasada otwarte-zamknięte mówi, że kod powinien być otwarty na rozszerzenia, ale zamknięty na modyfikacje. Oznacza to, że możemy dodawać nowe funkcje poprzez rozszerzanie istniejących klas, bez konieczności zmieniania już istniejącego kodu.

5. Co to jest Zasada podstawienia Liskov (LSP)?

Zasada podstawienia Liskov mówi, że obiekty klasy bazowej powinny być wymienialne z obiektami klasy pochodnej bez wpływu na poprawność programu. Klasy pochodne powinny w pełni respektować kontrakt określony przez klasę bazową.

6. Co to jest Zasada segregacji interfejsów (ISP)?

Zasada segregacji interfejsów mówi, że interfejsy powinny być małe i specyficzne dla danego klienta, zamiast jednego dużego, który zmusza klasy do implementacji metod, których nie potrzebują. Dzięki temu kod jest bardziej spójny i łatwiejszy do zarządzania.

7. Co to jest Zasada odwrócenia zależności (DIP)?

Zasada odwrócenia zależności mówi, że moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Oba rodzaje modułów powinny zależeć od abstrakcji (interfejsów). Dzięki temu nasze moduły są bardziej elastyczne i łatwiejsze do testowania.

8. Jakie są korzyści ze stosowania zasad SOLID?

Stosowanie zasad SOLID prowadzi do tworzenia kodu, który jest:

Łatwiejszy do utrzymania
Bardziej skalowalny
Czytelniejszy
Łatwiejszy do testowania
Bardziej elastyczny w kontekście wprowadzania zmian

9. Czy zasady SOLID są stosowane tylko w programowaniu obiektowym?

Choć zasady SOLID zostały stworzone z myślą o programowaniu obiektowym, ich idea może być zastosowana również w innych paradygmatach programowania, aby poprawić strukturę i jakość kodu.

10. Jak zacząć stosować zasady SOLID w swoim kodzie?

Najlepiej zacząć od zrozumienia każdej zasady i stopniowo wprowadzać je do swojego kodu. Możesz także przeglądać i refaktoryzować istniejący kod, aby był bardziej zgodny z zasadami SOLID. Ważne jest, aby stosować te zasady z umiarem i zawsze dążyć do pisania przejrzystego i zrozumiałego kodu.