SOLID ხუთი დიზაინის პრინციპია მდგრადი და მოქნილი OOP სისტემების აგებისთვის. თითოეული ეხება მყარი და მტკიცე კოდის საერთო მიზეზს.
SOLID ხუთი დიზაინის პრინციპია მდგრადი და მოქნილი OOP სისტემების აგებისთვის. თითოეული ეხება მყარი და მტკიცე კოდის საერთო მიზეზს.
| ასო | პრინციპი | ერთი სტრიქონის მნიშვნელობა |
|---|
| S | Single Responsibility | კლასს უნდა ჰქონდეს ცვლილების მხოლოდ ერთი მიზეზი |
| O | Open/Closed | გახსნილი გაფართოებისთვის, დახურული შეცვლისთვის |
| L | Liskov Substitution | ქვეტიპები უნდა იყოს გამოყენებული ყველგან, სადაც ფუძე ტიპი არის |
| I | Interface Segregation | მრავალი მცირე ინტერფეისი სჯობს ერთ დიდ ინტერფეისს |
| D | Dependency Inversion | დამოკიდებული აბსტრაქციებზე, კი არა კონკრეტულ კლასებზე |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService არ არის დამოკიდებული ელფოსტაზე კონკრეტულად — ჩაანაცვლეთ SMS-ით ან ტესტის დუბლით მისი შეხების გარეშე (D). ახალი გამოყვანის ტიპის დამატება OrderService-ის შეცვლას არ მოითხოვს (O).
SOLID არის ხელმძღვანელი, არა კანონი. მისი გადამეტებული გამოყენება — ინტერფეისი თითოეული კლასისთვის, არის მოშორებულობა ყველგან — ქმნის "აბსტრაქციის супს" რომელიც უფრო რთული გასაანალიზია, ვიდრე პრობლემა რომელსაც აგვარებს.
SOLID იძლევა საერთო დიაგნოსტიკური ენას: რეცენზენტებს შეუძლიათ დაასახელონ რატომ არის კლასი რთული შეცვლისთვის ("ეს ეწინააღმდეგება SRP-ს") იმის ნაცვლად, რომ აზრი დავკამათოთ.
გადამიჯნულად გამოყენებული, პრინციპები ამცირებენ ტალღისებრი ეფექტებს — ცვლილებები რჩება ლოკალური, ახალი მახასიათებლები ვრცელდება აღადგენის მაგივრად, და ტესტები შეუძლიათ დამცავი ის შეცვალონ რეალური დამოკიდებულებებისთვის.