/ / Tổng hợp / Comment (0)

SOLID Principles – Nguyên lý thiết kế trong lập trình hướng đối tượng

Vấn đề của Developers

Làm việc với nhiều function, class hàng trăm, hàng nghìn dòng code.

Việc này bắt nguồn từ cách viết code của các developer và nó kéo theo rất nhiều hệ lụy:

  • Code cực kì khó đọc và khó hiểu
  • Ứng dụng khó maintenance và mở rộng

Và để cải thiện vấn đề này thì SOLID ra đời.

solid principles

solid principles

SOLID Principles là gì

– Chắc hẳn đọc tới bài này thì các bạn đã có kiến thức căn bản về lập trình hướng đối tượng (OOP) rồi, như chúng ta biết thì lập trình hướng đối tượng được chia ra làm 4 tính chất

  • Inheritance (Tính kế thừa)
  • Polymophirsm (Tính đa hình)
  • Abstraction (Tính trừu tượng)
  • Encapsulation (Tính bao đóng)

– Và trong bài viết này mình sẽ đi tìm hiểu về SOLID Principles, đó chính là những nguyên lý thiết kế trong OOP. Nếu bạn đã tìm hiểu về các design pattern thì sẽ thấy chúng đều được xây dựng dựa trên các nguyên tắc này. SOLID được ghép lại từ 5 chữ viết tắt đầu tiên của 5 nguyên tắc sau:

  1. S is single responsibility principle (SRP)
  2. O stands for open closed principle (OCP)
  3. L Liskov substitution principle (LSP)
  4. I interface segregation principle (ISP)
  5. D Dependency injection principle (DIP)

Mục đích của SOLID là giúp developer viết code một cách có hệ thống hơn, qua đó giúp cho ứng dụng dễ dàng maintenance cũng như mở rộng.
– Trong bài này mình sẽ nói sơ qua về các SOLID Principles phía trên.

1. Single responsibility principle

Single responsibility principle

Single responsibility principle


– Đây là nguyên lý đầu tiên tương ứng với chữ S trong SOLID. Nguyên tắc này được lần đầu giới thiệu bởi Robert C. Martin
– Nội dung nguyên lý:

A class should have one, and only one, reason to change.

Có thể tạm hiểu nội dung nguyên lý là:

Một class chỉ có một và chỉ một lý do duy nhất để sửa đổi, hoặc một class chỉ nên giữ 1 trách nhiệm duy nhất

ví dụ:

class AreaCalculator
{
    public function sum()
    {
        // Thực hiện logic tính tổng diện tích các hình
    }
    public function output()
    {
        echo 'Sum: <b>' . $this->sum() . '</b>';
    }
}

– Theo như design hiện tại thì ta thấy class AreaCalculator đang phải xử lý 2 nhiệm vụ:

  • Tính toán tổng diện tích của các hình
  • Xử lý logic render kết quả tính toán

Sau đó thì có thêm yêu cầu là ngoài html thì app phải output được các định dạng khác như json, xml … Chúng ta sẽ làm gì? Update thêm logic vào AreaCalculator? Theo đúng nguyên lý, ta phải tách class này ra làm 2 class riêng. Tuy số lượng class nhiều hơn những việc sửa chữa sẽ đơn giản hơn, class ngắn hơn nên cũng ít bug hơn.
– Để hiểu thêm về nguyên lý này và cách giải quyết ví dụ trên các bạn có thể xem thêm tại đây.

2. Open/closed principle

Open/closed principle

Open/closed principle


– Nguyên lý thứ hai, tương ứng với chữ O trong SOLID
– Nội dung nguyên lý:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Có thể tạm hiểu nội dung nguyên lý là:

Các modules, classes và functions phải được thiết làm sao để đảm bảo khi cần triển khai tính năng mới thì không cần phải chỉnh sửa code cũ mà sẽ viết code mới và code mơi đó sẽ được sử dụng bởi code cũ.

– Theo nguyên lý này thì khi chúng ta muốn mở rộng chức năng cho một class thì nên tạo ra 1 class mới kế thừa từ class cũ và phát triển tính năng mới trên đó, không nên sửa đổi trực tiếp vào class cũ.
– Ví dụ: Chiếc máy tính của chúng ta khi muốn tăng dung lượng lưu trữ ta có thể lắp thêm ổ cứng, hoặc USB. Hoặc muốn hiển thị tốt hơn ta có thể lắp thêm card màn hình…tất cả đều không phải sửa chữa gì trong máy tính của chúng ta cả mà chỉ cần lắp thêm các phụ kiện khác vào là có thể đáp ứng được.
– Để hiểu thêm về nguyên lý này và cách giải quyết qua ví dụ các bạn có thể xem thêm tại đây.

3. Liskov Substitution Principle

Liskov Substitution Principle

Liskov Substitution Principle


– Nguyên lý thứ ba, tương ứng với chữ L trong SOLID
– Nội dung nguyên lý:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Có thể tạm hiểu nội dung nguyên lý là:

Mọi class con sẽ không bao giờ được phép phá vỡ chức năng của class cha. Hay nói cách khác thì mọi class con có thể thay thế class cha mà không là thay đổi hành vi của hệ thống.

– Khái niệm có vẻ khá khó hiểu, các bạn có thể nhìn vào bức ảnh mình họa trên sẽ thấy bản thân con vịt nó có khả năng bơi và vận động, nhưng con vịt đồ chơi thì cần có pin mới có thể chạy được, sẽ gây lỗi. Đó là 1 trường hợp vi phạm nguyên lý này.
– Để hiểu thêm về nguyên lý này và cách giải quyết ví dụ trên các bạn có thể xem thêm tại đây.

4. Interface Segregation Principle

 Interface Segregation Principle

Interface Segregation Principle


– Nguyên lý thứ tư, tương ứng với chữ I trong SOLID
– Nội dung nguyên lý:

A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

Có thể tạm hiểu nội dung nguyên lý là:

Một class không nên buộc phải implement một interface mà nó không sử dụng hoặc là 1 class không nên buộc phải phụ thuộc vào những method mà nó không dùng.

– Thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ, với nhiều mục đích cụ thể. Trong thực tế có nhiều interface xây dựng khá nhiều methods, như vậy tất cả những class nào mà implement nó sẽ phải viết lại hết những methods đó, có thể có những methods mà nó không dùng tới. Chính vì vậy ta nên phân chia ra thành nhiều interface với các methods liên quan tới nhau như vậy việc implement và quản lý sẽ dễ hơn.
– Để hiểu thêm về nguyên lý này và cách giải quyết ví dụ trên các bạn có thể xem thêm tại đây.

5. Dependency inversion principle

Dependency inversion principle

Dependency inversion principle


– Nguyên lý cuối cùng, tương ứng với chữ D trong SOLID
– Nội dung nguyên lý:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.

Có thể tạm hiểu nội dung nguyên lý là:

A. Class cấp cao sẽ không phụ thuộc trực tiếp vào Class cấp thấp mà sẽ phụ thuộc vào abstractions (interface) và abstractions (interface) đó sẽ được implement bởi Class cấp thấp.
B. Class mang tính trừu tượng sẽ không phụ thuộc và class cụ thể. Class cụ thể sẽ phụ thuộc vào abstractions (interface)

– Đây là một nguyên lý khá quan trọng và được sử dụng rất nhiều, một trong các Design Pattern triển khai theo nguyên lý này mà mình có đề cập là Repository Design Pattern

Bài viết được tham khảo:

The SOLID Principles, Explained with Motivational Posters



04/09/2017
Written by nobitacnt

Trong bài viết không tránh khỏi những câu từ chưa chính xác,mong nhận được sự góp ý để website hoàn thiện hơn.Nếu thấy bài viết có ích với bạn hãy like và share để ủng hộ nhé :D.

Bài viết chùng chuyên mục

Gửi bình luận

Giới thiệu

Mình tạo ra blog này với mong muốn chia sẻ và học hỏi kinh nghiệm trong quá trình thiết kế website. Website đang trong quá trình phát triển chân thành cảm ơn mọi sự góp ý của các bạn để làm cho website ngày càng hoàn thiên.

DMCA.com Protection Status
Theo dõi qua Email

Tổng hợp các bài viết về

Hoc php - CodeIgniter Framework - Laravel Framework - PHP va MYSQL