ในการเขียนโปรแกรมเชิงวัตถุและการเขียนโปรแกรมเชิงฟังก์ชันSOLIDเป็นตัวย่อที่ช่วยในการจำ สำหรับหลักการห้าประการที่มุ่งทำให้ซอร์สโค้ดเข้าใจง่าย ยืดหยุ่น และบำรุงรักษาได้ง่าย ขึ้น แม้ว่าหลักการเหล่า ^นี้จะใช้กับการเขียนโปรแกรมเชิงวัตถุ แต่ก็ยังเป็นปรัชญาหลักสำหรับวิธีการต่างๆ เช่นการพัฒนาซอฟต์แวร์แบบ Agileและการพัฒนาซอฟต์แวร์แบบปรับตัวได้ [ ^{1 ]}

วิศวกรซอฟต์แวร์และผู้สอนRobert C. Martin ^{[ 2 ] [ 3 ] [ 1 ]}ได้แนะนำหลักการพื้นฐานของการออกแบบ SOLID ในบทความDesign Principles and Design Patternsเกี่ยวกับซอฟต์แวร์ที่เสื่อมสภาพใน ปี 2000 ^{[ 3 ] [ 4 ] : 2–3} คำ ย่อ SOLIDถูกคิดค้นขึ้นประมาณปี 2004 โดย Michael Feathers ^{[ 5 ]}

หลักการความรับผิดชอบเดียว (SRP) ระบุว่าไม่ควรมีเหตุผลมากกว่าหนึ่งข้อสำหรับการเปลี่ยนแปลงคลาส^{[ 6 ]}กล่าวอีกนัยหนึ่งคือ ทุกคลาสควรมีความรับผิดชอบเพียงอย่างเดียว^{[ 7 ]}

ความสำคัญ:

• ความสามารถในการบำรุงรักษา: เมื่อคลาสมีหน้าที่รับผิดชอบเพียงอย่างเดียวและชัดเจน จะทำให้เข้าใจและแก้ไขได้ง่ายขึ้น
• ความสามารถในการทดสอบ: การเขียน unit test สำหรับคลาสที่มีจุดโฟกัสเดียวจะง่ายกว่า
• ความยืดหยุ่น: การเปลี่ยนแปลงความรับผิดชอบหนึ่งจะไม่ส่งผลกระทบต่อส่วนอื่น ๆ ของระบบ^{[ 7 ]}

หลักการเปิด-ปิด (OCP) ระบุว่าเอนทิตีซอฟต์แวร์ควรเปิดให้มีการขยาย แต่ปิดไม่ให้มีการแก้ไข^{[ 8 ]}

ความสำคัญ:

• ความสามารถในการขยาย: สามารถเพิ่มฟังก์ชันใหม่ได้โดยไม่ต้องแก้ไขโค้ดที่มีอยู่เดิม
• ความเสถียร: ช่วยลดความเสี่ยงในการเกิดข้อผิดพลาดเมื่อทำการเปลี่ยนแปลง
• ความยืดหยุ่น: ปรับตัวให้เข้ากับความต้องการที่เปลี่ยนแปลงได้ง่ายขึ้น

หลักการแทนที่ของ Liskov (LSP) ระบุว่าฟังก์ชันที่ใช้พอยเตอร์หรือการอ้างอิงไปยังคลาสพื้นฐานจะต้องสามารถใช้พอยเตอร์หรือการอ้างอิงของคลาสที่สืบทอดมาได้โดยไม่ต้องรู้^{[ 9 ]}

ความสำคัญ:

• โพลีมอร์ฟิซึม : ช่วยให้สามารถใช้พฤติกรรมแบบโพลีมอร์ฟิกได้ ทำให้โค้ดมีความยืดหยุ่นและนำกลับมาใช้ใหม่ได้มากขึ้น
• ความน่าเชื่อถือ: รับประกันว่าคลาสย่อยจะปฏิบัติตามข้อตกลงที่กำหนดโดยคลาสหลัก
• ความสามารถในการคาดการณ์: รับประกันว่าการแทนที่วัตถุคลาสแม่ด้วยวัตถุคลาสย่อยจะไม่ทำให้โปรแกรมเสียหาย^{[ 9 ]}

หลักการแยกอินเทอร์เฟซ (ISP) ระบุว่าลูกค้าไม่ควรถูกบังคับให้พึ่งพาวิธีการอินเทอร์เฟซที่พวกเขาไม่ได้ใช้^{[ 10 ] [ 4 ]}

ความสำคัญ:

• การแยกส่วน: ช่วยลดการพึ่งพาซึ่งกันและกันระหว่างคลาส ทำให้โค้ดมีความเป็นโมดูลาร์และดูแลรักษาง่าย ขึ้น
• ความยืดหยุ่น: ช่วยให้สามารถใช้งานอินเทอร์เฟซได้อย่างตรงเป้าหมายมากขึ้น
• หลีกเลี่ยงการพึ่งพาที่ไม่จำเป็น: ลูกค้าไม่จำเป็นต้องพึ่งพาเมธอดที่พวกเขาไม่ได้ใช้

หลักการผกผันการพึ่งพา (DIP) ระบุว่าควรพึ่งพาสิ่งที่เป็นนามธรรม ไม่ใช่สิ่งที่เป็นรูปธรรม^{[ 11 ] [ 4 ]}

ความสำคัญ:

• การเชื่อมต่อแบบหลวมๆ (Loose coupling ): ช่วยลดการพึ่งพาซึ่งกันและกันระหว่างโมดูล ทำให้โค้ดมีความยืดหยุ่นมากขึ้นและทดสอบได้ง่ายขึ้น
• ความยืดหยุ่น: ช่วยให้สามารถเปลี่ยนแปลงการใช้งานได้โดยไม่ส่งผลกระทบต่อลูกค้า
• ความสามารถในการบำรุงรักษา : ทำให้โค้ดเข้าใจและแก้ไขได้ง่ายขึ้น^{[ 11 ] [ 4 ]}

• การนำโค้ดกลับมาใช้ใหม่
• GRASP (การออกแบบเชิงวัตถุ)
• การสืบทอด (การเขียนโปรแกรมเชิงวัตถุ)
• รายชื่อปรัชญาการพัฒนาซอฟต์แวร์