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 หรือ test double โดยไม่สัมผัส (D) การเพิ่มประเภท notifier ใหม่ไม่จำเป็นต้องมีการเปลี่ยนแปลง OrderService (O)
SOLID เป็นแนวทาง ไม่ใช่กฎ การนำไปใช้มากเกินไป — อินเทอร์เฟซต่อคลาส ความเป็นอ้อมค้อมทุกที่ — สร้าง "สุปน้ำแกง abstractions" ที่เป็นไปตามปัญหาที่แก้ไขได้ยากกว่า
SOLID ให้ภาษาการวินิจฉัยที่ใช้ร่วมกัน: ผู้สอบทานสามารถตั้งชื่อ ทำไม คลาสจึงเปลี่ยนแปลงได้ยาก ("สิ่งนี้ละเมิด SRP") แทนที่จะโต้แย้งตามรสนิยม
เมื่อนำไปใช้ด้วยความเป็นธรรม หลักการเหล่านี้จะลดผลการไหลของคลื่น — การเปลี่ยนแปลงยังคงเป็นท้องถิ่น ฟีเจอร์ใหม่ขยายแทนที่จะเขียนใหม่ และการทดสอบสามารถแทนที่ปลอมสำหรับการพึ่งพาจริง