ความเชี่ยวชาญด้านความรับผิดชอบเดียวและการเปิดรับการขยาย
เพิ่มพูนความเข้าใจในหลักการสองข้อแรกของ SOLID โดยเรียนรู้การระบุขอบเขตความรับผิดชอบและการขยายพฤติกรรมโดยไม่แก้ไขโค้ดที่มีอยู่
ความเชี่ยวชาญด้านความรับผิดชอบเดียวและการเปิดรับการขยาย เป็นบทเรียน Clean Architecture & Design Patterns in Practice ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clean Architecture & Design Patterns in Practice และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
Back to the Foundations
You have explored Dependency Inversion and Interface Segregation. This lesson masters the remaining pair:
- Single Responsibility Principle (SRP)
- Open-Closed Principle (OCP)
These two drive most everyday refactoring decisions.
SRP Defined Precisely
SRP says a class should have one reason to change. A reason to change maps to a single actor or stakeholder.
If billing rules and report formatting can change independently, they belong in different classes.
Spotting an SRP Violation
This class mixes calculation, persistence, and presentation.
class Employee {
double calculatePay() { return 0; }
void save() { /* DB code */ }
String reportHtml() { return "<html>"; }
}Refactoring Toward SRP
Split responsibilities so each changes for one reason.
class PayCalculator { double calculate(Employee e) { return 0; } }
class EmployeeRepository { void save(Employee e) {} }
class EmployeeReporter { String html(Employee e) { return "<html>"; } }The Cohesion Payoff
After the split, each class is more cohesive: everything inside relates to one job.
Changes are localized, tests are focused, and accidental coupling between unrelated concerns disappears.
OCP Defined
The Open-Closed Principle: software entities should be open for extension but closed for modification.
You should be able to add new behavior by writing new code, not editing existing, tested code.
An OCP Violation
Adding a shape forces editing this method every time.
double area(Shape s) {
if (s.type.equals("circle")) return 3.14 * s.r * s.r;
else if (s.type.equals("square")) return s.side * s.side;
return 0;
}Closing It With Polymorphism
Make each shape compute its own area. New shapes require no edits to existing code.
interface Shape { double area(); }
class Circle implements Shape {
double r;
public double area() { return 3.14 * r * r; }
}
class Square implements Shape {
double side;
public double area() { return side * side; }
}OCP Through Strategy and Plugins
Common OCP-enabling techniques:
- Polymorphism over conditionals.
- The Strategy pattern to inject varying behavior.
- Plugin or registry mechanisms for adding handlers.
All let you extend by adding, not editing.
How SRP and OCP Reinforce Each Other
A class with a single responsibility is much easier to keep closed for modification, because there is only one axis of change.
When you cleanly separate responsibilities, extension points emerge naturally.
Pragmatic Limits
Do not over-apply. Premature abstraction for variation that never comes adds needless complexity.
Apply OCP at the points your domain actually varies; let the rest stay simple until change demands it.
Quick Check
Test your grasp of SRP and OCP.
Recap
You mastered the first two SOLID principles.
- SRP: one reason to change per class.
- OCP: extend by adding, not editing.
- They reinforce each other and guide most refactorings, applied where variation truly exists.
คำถามที่พบบ่อย
บทเรียน “ความเชี่ยวชาญด้านความรับผิดชอบเดียวและการเปิดรับการขยาย” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ความเชี่ยวชาญด้านความรับผิดชอบเดียวและการเปิดรับการขยาย” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clean Architecture & Design Patterns in Practice ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ความเชี่ยวชาญด้านความรับผิดชอบเดียวและการเปิดรับการขยาย”
เพิ่มพูนความเข้าใจในหลักการสองข้อแรกของ SOLID โดยเรียนรู้การระบุขอบเขตความรับผิดชอบและการขยายพฤติกรรมโดยไม่แก้ไขโค้ดที่มีอยู่ คุณปฏิบัติ Clean Architecture & Design Patterns in Practice ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clean Architecture & Design Patterns in Practice หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clean Architecture & Design Patterns in Practice บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “ความเชี่ยวชาญด้านความรับผิดชอบเดียวและการเปิดรับการขยาย” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Clean Architecture & Design Patterns in Practice นี้ได้ไหม
ได้ บทเรียน Clean Architecture & Design Patterns in Practice ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- เจาะลึกการกลับทิศทางการพึ่งพา
- การแยกอินเทอร์เฟซในทางปฏิบัติ
- การปรับโครงสร้างโค้ดด้วยรูปแบบการออกแบบ
- ความเชี่ยวชาญด้านความรับผิดชอบเดียวและการเปิดรับการขยาย