Solid là gì và nên áp dụng nguyên lý solid ra sao để có thể trở thành một người lập trình viên giỏi có lẽ là thắc mắc của nhiều người. Hãy cùng tìm hiểu cụ thể về phần mềm này nhé!

Solid là gì và ra đời như thế nào?

Lập trình đối tượng hay còn có tên gọi tiếng anh đó là Object Oriented Programming – OOP chính là một trong những mô hình lập trình ngày nay được sử dụng nhiều nhất. Phần mềm này được sử dụng rộng rãi nhờ vào những đặc tính như tính trừu tượng, tính đa hình, tình kế thừa và tính đóng gói.

Sự hình thành và phát triển của solid
Sự hình thành và phát triển của solid

Các tính chất đặc biệt này đã giúp cho rất nhiều coder xây dựng dễ dàng hơn những chương trình và giải quyết được nhiều vấn đề cụ thể khác nhau ở trong thế giới thực. Hầu hết các coder đã quen thuộc với các tính năng OOP này, nhưng việc kết hợp các tính năng này để tăng hiệu suất ứng dụng vẫn chưa được hiểu rõ.

Solid chính là được viết tắt từ 5 chữ cái đầu tiên ở trong bộ 5 nguyên tắc được thiết kế ra với mục đích giúp cho các coder đọc được dễ hiểu hơn, dễ nắm bắt được những ý chính hơn. Những nguyên tắc này đã được đưa ra bởi Michael Feathers và Robert C.Martin bao gồm: 

  • Single Responsibility Principle (SRP)
  • Open/Closed Principle (OCP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle (DIP)

Bộ 5 nguyên tắc của solid là gì?

Bên trên chúng ta đã hiểu sơ qua solid là gì và tiếp theo đây hãy cùng chúng tôi tìm hiểu chi tiết về 5 nguyên tắc của phần mềm này.

Nguyên tắc 1: Single Responsibility Principle (SRP)

Nguyên tắc 1: Single responsibility principle (SRP)
Nguyên tắc 1: Single responsibility principle (SRP)

Nguyên tắc đầu tiên trong bộ 5 nguyên tắc đó là chữ cái S với ý nghĩa là một class với trách nhiệm duy nhất, nếu như một class có quá nhiều chắc năng thì nó sẽ trở nên khó hiểu, cồng kềnh và cũng khiến cho các lập trình viên khó có thể duy trì hết toàn bộ.

Nhất là trong ngành IT thì việc yêu cầu thay đổi cũng như thêm bớt những chức năng để thuận tiện hơn là điều rất bình thường. Vì có lý do đó mà việc một người lập trình có thể code trong sáng dễ đọc cũng như dễ hiểu là một điều rất cần thiết.

Nguyên tắc class ngoài việc đánh dấu những giao dịch đã được thực hiện thì nó còn làm nhiệm vụ tính hoa hồng cho mỗi giao dịch. Bên cạnh đó sau này cũng sẽ có thêm một số chức năng ví dụ như gửi thông báo, hoặc là gửi mail nội dung cụ thể liên quan đến hoa hồng cho mỗi cá nhân có liên quan đến.

Để mọi người có thể dễ hình dung hơn, lấy một ví dụ hình dung rằng một người nhân viên của công ty công nghệ cần phải làm 1 trong 3 công việc: kiểm tra phần mềm, lập trình phần mềm và bán phần mềm. Với mỗi một người nhân viên sẽ có những chức vụ cũng như số tiền lương tương ứng và khi đó thì bạn sẽ có nên thiết kế “ Employee “ cùng với thuộc tính “position” không? Vầ câu trả lời hoàn toàn là Không.

Áp dụng theo nguyên tắc 1 thì mỗi một lớp class sẽ cần phải tạo ra một lớp trừu tượng là “Employee” có được phương thức là working () từ đó bạn sẽ kế thừa ra 3 lớp cụ thể như đã nói ở bên trên và sẽ tùy thuộc vào nhiệm vụ của mỗi người.

Nguyên tắc 2: Open/Closed Principle (OCP)

Nguyên tắc thứ hai trong bộ 5 nguyên tắc đó là chữ cái O có ý nghĩa chính là không được sửa đổi một class có sẵn tuy nhiên có thể mở rộng bằng việc kế thừa. Điều này giúp chúng ta có thể tạo ra nhiều class mà hoàn toàn không cần test lại các class cũ, chỉ tập trung test các class mới cùng các tính năng mới. 

Thông thường muốn mở rộng chức năng thì phải viết thêm code để thiết kế module và có thể dễ dàng mở rộng, hạn chế thay đổi code cần thiết. Giải pháp là tách các bộ phận dễ thay thế khỏi các bộ phận khó thay thế, đảm bảo rằng những bộ phận khác không bị ảnh hưởng.

Ví dụ như có một vấn đề đó là cần một lớp đảm nhận cho việc kết nối CSDL tuy nhiên thiết kế ban đầu chỉ có SQL, MySQL cùng với Server. Sau đó đặt ra yêu cầu cần phải được kết nối thêm đến Oracle cùng với một vài hệ CSDL khác. Với thiết kế như này nếu như muốn kết nối đến 1 loại CSDL mới thì chỉ cần thêm một lớp thừa kế Connection mà không cần phải sửa đổi code.

Nguyên tắc 3: Liskov Substitution Principle (LSP)

Nguyên tắc 3: Liskov Substitution Principle (LSP)
Nguyên tắc 3: Liskov Substitution Principle (LSP)

Nguyên tắc thứ ba trong bộ 5 nguyên tắc đó là chữ cái L có ý nghĩa chính là các đối tượng kiểu class con hoàn toàn có thể thay đổi những đối tượng class cha mà không gây ra lỗi gì.

Cùng quay trở lại với ví dụ Employee ở nguyên tắc số 1, chúng ta giả sử rằng sẽ có công ty điểm danh vào mỗi buổi sáng và cũng chỉ có những nhân viên thuộc vào hàng nhân viên biên chế chính thức điểm danh thì ta sẽ cần bổ sung phương thức checkAttendance() vào lớp Employee.

Nếu ta hình dung có một công ty thuê một người nhân viên lao công để có thể làm vệ sinh văn phòng tuy nhiên người nhân viên này sẽ không được coi là một người nhân viên chính do không được phép cấp ID mà chỉ là một người nhân viên thời vụ chính vì vậy mà sẽ không được điểm danh.

Từ đó chúng ta có thể hiểu rằng quy tắc này tạo ra một lớp CleanerStaff được kế thừa từ Employee và Implement với hàm working thì mọi thứ đều ổn. Tuy nhiên là lớp mới này lại có hàm checkAttendance() dùng để điểm danh mà như thế sẽ là sai quy định chính vì vậy mà lớp thiết kế CleanStaff kế thừa từ Employee là không hợp lý.

Nguyên tắc 4: Interface Segregation Principle (ISP)

Nguyên tắc này rất dễ hiểu. Hãy tưởng tượng rằng chúng ta hiện đang có được một giao diện của người dùng lớn cùng với khoảng 100 phương thức. Bên cạnh đó việc dư thừa cũng rất dễ dàng bị xáy ra vì lý do không cần sử dụng tất cả 100 phương thức. Chia giao diện người dùng thành nhiều giao diện nhỏ với các phương thức liên quan giúp việc triển khai và quản lý dễ dàng hơn.

Nếu như có 2 class đó là Dog cùng với Snake Implement Interface Animal tuy nhiên thật vô lý khi Dog có thể fly() cũng như Snake không có khả năng run() và thay vào đó thì những người lập trình viên nên tách thành 3 Interface.

Nguyên tắc 5: Dependency Inversion Principle (DIP)

Nguyên tắc cuối cùng với ý nghĩa:

  • Các module cấp cao thì không nên phụ thuộc vào những nhóm modules cấp thấp, và hơn hết cả 2 nên phụ thuộc vào abstraction.
  • Abstraction thì không nên phụ thuộc vào những chi tiết mà nên ngược lại.

Nguyên tắc này hoàn toàn có thể được hiểu như sau: các thành phần của chương trình chỉ nên có sự phụ thuộc vào sự trừu tượng hóa. Bên cạnh đó những thành phần trừu tượng không nên phụ thuộc vào các thành phần cụ thể, mà ngược lại. 

Các phần trừu tượng ít thay đổi và đa dạng, tập hợp các đặc tính chung nhất. Những sự vật cụ thể, dù khác nhau đến đâu, đều tuân theo những quy luật chung của cái trừu tượng. Tính trừu tượng phụ thuộc giúp chương trình linh hoạt và thích nghi tốt với sự thay đổi liên tục.

Trên đây chính là toàn bộ những thông tin về Solid cũng như bộ 5 nguyên tắc solid mà các lập trình viên cần nắm rõ để trở thành một người lập trình viên xuất sắc. Hy vọng thông qua bài viết các bạn tự trả lời được cho mình câu hỏi solid là gì. Hãy theo dõi thường xuyên để cập nhật nhiều thông tin về IT hơn nhé.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

0981578920
icons8-exercise-96