Clean Architecture & Design Patterns in Practice · บทเรียน

ภาพรวมหลักการ SOLID

ทำความรู้จักเบื้องต้นกับหลักการ SOLID ทั้งห้า ได้แก่ ความรับผิดชอบเดียว เปิด/ปิด การทดแทนของ Liskov การแยกอินเทอร์เฟซ และการกลับทิศทางการพึ่งพา

ภาพรวมหลักการ SOLID เป็นบทเรียน Clean Architecture & Design Patterns in Practice ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clean Architecture & Design Patterns in Practice และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

What are SOLID Principles?

The SOLID principles are five design guidelines for software that’s easy to maintain, understand, and extend. Think of them as a path to cleaner code.

Why SOLID Matters

Applying SOLID gives you code that’s easier to understand, simpler to test, more flexible to change, and friendlier to teamwork. It’s the bedrock of good OO design.

S: Single Responsibility Principle (SRP)

The Single Responsibility Principle: a class should have one reason to change. Don’t mix calculating data and saving it — split those concerns apart.

SRP in Action: Simple Report

This SimpleReport obeys SRP: its only job is generating report content. Printing and saving are someone else’s responsibility.

public class SimpleReport {
  private String content;

  public SimpleReport(String content) {
    this.content = content;
  }

  // This class's single responsibility is to generate/represent the report content
  public String generateReportContent() {
    return "Report: " + content;
  }

  public static void main(String[] args) {
    SimpleReport report = new SimpleReport("Sales Data for Q1");
    System.out.println(report.generateReportContent());
  }
}

O: Open/Closed Principle (OCP)

The Open/Closed Principle: software should be open for extension but closed for modification. Add new behavior without editing working code.

OCP in Action: Flexible Greeters

Here a new greeter type slots in without touching the Greeter interface or existing classes — extending behavior, not modifying it. That’s OCP.

interface Greeter {
  String greet();
}

class EnglishGreeter implements Greeter {
  @Override
  public String greet() {
    return "Hello!";
  }
}

class SpanishGreeter implements Greeter {
  @Override
  public String greet() {
    return "¡Hola!";
  }
}

public class OCPDemo {
  public static void main(String[] args) {
    Greeter english = new EnglishGreeter();
    Greeter spanish = new SpanishGreeter();
    System.out.println(english.greet());
    System.out.println(spanish.greet());
  }
}

L: Liskov Substitution Principle (LSP)

The Liskov Substitution Principle: a subclass must be usable anywhere its parent is expected, without breaking the program. Subtypes honor the contract.

LSP in Action: Shapes

Any function taking a Shape handles both Rectangle and Circle correctly — they honor the contract. That’s LSP at work.

interface Shape {
  double getArea();
}

class Rectangle implements Shape {
  private double width; 
  private double height;

  public Rectangle(double width, double height) {
    this.width = width;
    this.height = height;
  }

  @Override
  public double getArea() {
    return width * height;
  }
}

class Circle implements Shape {
  private double radius;

  public Circle(double radius) {
    this.radius = radius;
  }

  @Override
  public double getArea() {
    return Math.PI * radius * radius;
  }
}

public class LSPDemo {
  public static void printArea(Shape shape) {
    System.out.println("Area: " + shape.getArea());
  }

  public static void main(String[] args) {
    Shape myRectangle = new Rectangle(5, 4);
    Shape myCircle = new Circle(3);

    printArea(myRectangle);
    printArea(myCircle);
  }
}

I: Interface Segregation Principle (ISP)

The Interface Segregation Principle: don’t force clients to depend on methods they don’t use. Prefer many small, focused interfaces over one fat one.

D: Dependency Inversion Principle (DIP)

The Dependency Inversion Principle: high-level and low-level modules should both depend on abstractions, not concrete details. That’s how you get loose coupling.

Check Your Understanding

Which of the following statements correctly describe the benefits of applying SOLID principles?

Recap: The Power of SOLID

You’ve met all five SOLID principles — single responsibility, open/closed, Liskov, interface segregation, dependency inversion — the toolkit for adaptable software.

คำถามที่พบบ่อย

บทเรียน “ภาพรวมหลักการ SOLID” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “ภาพรวมหลักการ SOLID” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clean Architecture & Design Patterns in Practice ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “ภาพรวมหลักการ SOLID”

ทำความรู้จักเบื้องต้นกับหลักการ SOLID ทั้งห้า ได้แก่ ความรับผิดชอบเดียว เปิด/ปิด การทดแทนของ Liskov การแยกอินเทอร์เฟซ และการกลับทิศทางการพึ่งพา คุณปฏิบัติ Clean Architecture & Design Patterns in Practice ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clean Architecture & Design Patterns in Practice หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clean Architecture & Design Patterns in Practice บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “ภาพรวมหลักการ SOLID” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Clean Architecture & Design Patterns in Practice นี้ได้ไหม

ได้ บทเรียน Clean Architecture & Design Patterns in Practice ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

บทนำสู่โค้ดสะอาด
ภาพรวมหลักการ SOLID
คุณค่าของการออกแบบที่ดี
ความเป็นเอกภาพ การเชื่อมโยง และการแยกความรับผิดชอบ

← กลับไปที่ Clean Architecture & Design Patterns in Practice