ในการพัฒนา Software Architecture ระดับ Enterprise ที่ต้องรองรับการ Scaling และจัดการกับ Business Logic ที่ซับซ้อน ปัญหาที่เหล่านักพัฒนา (Developer) มักพบเจอคือ "Fragile Code" หรือโค้ดที่เปราะบาง แตะจุดหนึ่งแต่กลับส่งผลกระทบพังไปอีกจุดหนึ่ง ทำให้การซ่อมบำรุงหรือเพิ่มฟีเจอร์ใหม่กลายเป็นเรื่องยาก
PRIMO Tech-a-break วันนี้ เราจะมาเจาะลึกแนวคิดคลาสสิกอย่าง SOLID Principles ซึ่งเป็นเข็มทิศสำคัญในการเขียน Clean Code เพื่อให้ระบบของคุณยืดหยุ่นและพร้อมเติบโตอย่างมั่นคง
1. S: Single Responsibility Principle (SRP)
"หนึ่งคลาส หนึ่งหน้าที่" ทุก Component หรือ Class ควรมีเหตุผลในการแก้ไขเพียงเหตุผลเดียวเท่านั้น หลีกเลี่ยงการสร้าง 'God Object' ที่รวมทุกอย่างตั้งแต่วิธีคำนวณ Logic ไปจนถึงการจัดการ Database ไว้ในที่เดียว
-
SEO Tip: การแยก Responsibility ช่วยให้โค้ดอ่านง่าย (Readability) และทำ Unit Testing ได้เจาะจงมากขึ้น
2. O: Open/Closed Principle (OCP)
"เปิดรับส่วนขยาย แต่ปิดการแก้ไขโค้ดหลัก" ซอฟต์แวร์ที่ดีควรถูกออกแบบให้เพิ่มฟีเจอร์ใหม่ได้ผ่านการทำ Extension โดยไม่ต้องเข้าไปแก้ไขโค้ดเดิมที่ทำงานเสถียรอยู่แล้ว เพื่อลดความเสี่ยงในการเกิด Regression Bug
-
Technical Detail: ใช้ Abstraction หรือ Polymorphism แทนการเขียน if-else หรือ switch-case ซ้ำซ้อน เพื่อให้ระบบรองรับ Implementation ใหม่ๆ ได้ทันที
3. L: Liskov Substitution Principle (LSP)
"คลาสลูกต้องแทนที่คลาสแม่ได้สมบูรณ์" หากคุณใช้การสืบทอด (Inheritance) คลาสลูก (Subtype) จะต้องสามารถทำงานแทนที่คลาสแม่ (Base Type) ได้ 100% โดยที่พฤติกรรมของโปรแกรมไม่ผิดเพี้ยนไปจากเดิม
-
Warning: อย่าใช้ Inheritance เพียงเพื่อต้องการแชร์โค้ด หากพฤติกรรมต่างกันเกินไป การเลือกใช้ Composition อาจเป็นทางเลือกที่ดีกว่า
4. I: Interface Segregation Principle (ISP)
"อย่าบังคับให้ Client ต้องพึ่งพา Interface ที่ไม่ได้ใช้งาน" การสร้าง Interface ขนาดใหญ่ (Fat Interface) ทำให้ผู้ใช้งานต้อง Implement ฟังก์ชันที่ไม่จำเป็น วิธีแก้คือการแตกเป็น Specific Interfaces ที่มีขนาดเล็กและ Lean กว่า
-
Benefit: ช่วยลด Dependency ที่ไม่จำเป็น และทำให้การเชื่อมต่อระหว่างโมดูลมีความคล่องตัวสูง
5. Dependency Inversion Principle (DIP)
"ยึดติดกับ Abstraction อย่ายึดติดกับ Concretion" โมดูลระดับสูงไม่ควรขึ้นตรงกับโมดูลระดับต่ำ แต่ทั้งคู่ควรขึ้นตรงกับ Interface เท่านั้น การเขียนโค้ดผูกติดกับ Library หรือ Database แบรนด์ใดแบรนด์หนึ่งโดยตรง จะทำให้ขาดความยืดหยุ่นในอนาคต
-
Solution: ใช้เทคนิค Dependency Injection (DI) เพื่อให้โค้ดเป็นแบบ Decoupled ซึ่งง่ายต่อการบำรุงรักษาและการทำ Automated Test
สรุปหัวใจสำคัญ (Key Takeaway)
การนำหลักการ S.O.L.I.D. มาใช้ ไม่ใช่เพียงเพื่อให้โค้ดดูสวยงาม แต่เป็นการลด Cognitive Load ให้กับทีมงาน และสร้างระบบที่ยืดหยุ่นพอจะตอบโจทย์ธุรกิจที่เปลี่ยนแปลงตลอดเวลา นี่คือหัวใจของการพัฒนาซอฟต์แวร์ให้เป็น High-Quality Code อย่างแท้จริง
Happy Coding! แล้วพบกับสาระดีๆ ใน Tech-a-break ครั้งหน้าครับ