Phần mềm được xem là tốt khi khi nó có kiến trúc tốt. Kiến trúc phần mềm tương tự như móng nhà, móng yếu nhà sẽ không còn vững. Để viết được phần mềm tốt bạn phải học rất nhiều, điều trước nhất bạn phải biết là SOLID.

Bạn Đang Xem: SOLID là gì? Áp dụng SOLID để trở thành lập trình viên giỏi

SOLID ra đời thế nào?

Lập trình hướng đối tượng người dùng (object oriented programming – OOP) là một trong những mô hình lập trình được sử dụng nhiều nhất. Các tính chất đặc biệt quan trọng khiến việc hướng đối tượng người dùng trở thành hiệu quả đó là:

• Tính trừu tượng (abstraction): Tạo ra các lớp trừu tượng mô hình hoá các đối tượng người dùng trong thế giới thực.
• Tính đóng gói (Encapsulation): Các thực thể của lớp trừu tượng có những giá trị tính chất riêng biệt.
• Tính thừa hưởng (Inheritance): Các đối tượng người dùng có thể dễ dàng thừa hưởng và mở rộng lẫn nhau.
• Tính đa hình (Polymorphism): Có thể thực hiện một hành động đơn theo rất nhiều cách thức thức khác nhau tuỳ theo loại đối tượng người dùng cụ thể đang rất được gọi.

Các tính chất đặc biệt quan trọng này của OOP giúp tất cả chúng ta xây dựng được những Khóa học giải quyết và xử lý được nhiều vấn đề cụ thể khác nhau trong thế giới thực. Hồ hết lập trình viên đều đã biết các tính chất này của OOP, nhưng phương pháp để phối hợp các tính chất này với nhau để tăng hiệu quả của ứng dụng thì không phải ai cũng nắm được. Một trong những hướng dẫn để giúp tất cả chúng ta sử dụng được OOP hiệu quả hơn đó là nguyên tắc SOLID.

SOLID là gì?

SOLID là viết tắt của 5 vần âm đầu trong 5 nguyên tắc thiết kế hướng đối tượng người dùng. Hỗ trợ cho lập trình viên viết ra những đoạn code dễ đọc, dễ hiểu, dễ maintain. Nó được đưa ra bởi Robert C. Martin và Michael Feathers. 5 nguyên tắc đó gồm có:

• Single responsibility priciple (SRP)
• Open/Closed principle (OCP)
• Liskov substitution principe (LSP)
• Interface segregation principle (ISP)
• Dependency inversion principle (DIP)

Single responsibility priciple

Nội dung:

Mỗi lớp nên làm chịu trách nhiệm về một nhiệm vụ cụ thể nào này mà thôi.

Nguyên tắc trước nhất ứng với chữ S trong SOLID, có ý tức thị một class nên làm giữ một trách nhiệm duy nhất. Một class có quá nhiều chức năng sẽ trở thành kềnh càng và trở thành khó đọc, khó maintain. Mà khi đối chiếu với ngành IT việc requirement thay đổi, cần thêm sửa chức năng là rất thường nhật, nên việc code trong sáng, dễ đọc dễ hiểu là rất cấp thiết.

Ví dụ: Hình dung rằng viên chức của một đơn vị phần mềm cần phải làm 1 trong 3 việc sau đây: lập trình phần mềm (developer), kiểm tra phần mềm (tester), bán phần mềm (salesman). Mỗi viên chức sẽ sở hữu một chức vụ và dựa vào chức vụ sẽ làm thuê việc tương ứng. Khi đó bạn có nên thiết kế lớp “Employee” với tính chất “position” và 3 phương thức developSoftware(), testSoftware() và saleSoftware() không?

class Employee { string position; function developSoftware(){}; function testSoftware(){}; function saleSoftware(){}; }

Lời đáp là KHÔNG. Thử hình dung nếu có thêm một chức vụ nữa là quản lí nhân sự, ta sẽ phải sửa lại lớp “Employee”, thêm phương thức mới vào sao? Nếu có thêm 10 chức vụ nữa thì sao? Khi đó các đối tượng người dùng được tạo ra sẽ dư thừa rất nhiều phương thức: Developer thì đâu cần dùng hàm testSoftware() và saleSoftware() đúng không nào nào, lỡ may dùng lầm phương thức cũng sẽ gây nên hậu quả khôn lường.

Ứng dụng nguyên tắc Single Responsibility: mỗi lớp 1 trách nhiệm. Ta sẽ tạo 1 lớp trừu tượng là “Employee” có phương thức là working(), từ đây bạn thừa hưởng ra 3 lớp cụ thể là Developer, Tester và Salesman. Ở mỗi lớp này các bạn sẽ implement phương thức working() cụ thể tuy theo nhiệm vụ của từng người. Khi đó tất cả chúng ta sẽ bị tình trạng dùng nhầm phương thức nữa.

Open/Closed principle

Nội dung:

Không được sửa đổi một Class có sẵn, nhưng có thể mở rộng bằng thừa hưởng.

Nguyên tắc thứ hai ứng với chữ O trong SOLID.

Theo nguyên tắc này, mọi khi ta muốn thêm chức năng cho Khóa học, tất cả chúng ta nên viết class mới mở rộng class cũ (bằng phương pháp thừa hưởng hoặc sở hữu class cũ) chứ không nên sửa đổi class cũ. Việc này dẫn đến tình trạng phát sinh nhiều class, nhưng tất cả chúng ta sẽ không cần thiết phải test lại các class cũ nữa, mà chỉ tập trung vào test các class mới, nơi chứa các chức năng mới.

Thông thường việc mở rộng thêm chức năng thì phải viết thêm code, vậy để thiết kế ra một module có thể dễ dàng mở rộng nhưng lại hạn chế sửa đổi code ta cần làm gì. Cách giải quyết và xử lý là tách những phần dễ thay đổi thoát khỏi phần khó thay đổi mà vẫn đảm bảo không tác động ảnh hưởng đến phần sót lại.

Xem Thêm : Hạt kê có tác dụng gì đối với sức khỏe? Cách dùng thế nào?

Ví dụ:

• Đặt vấn đề: Ta cần 1 lớp đảm nhận việc kết nối đến CSDL. Thiết kế ban sơ chỉ có SQL Server và MySQL. Thiết kế ban sơ có dạng như sau:

class ConnectionManager { public function doConnection(Object $connection) { if($connection instanceof SqlServer) { //connect with SqlServer } elseif($connection instanceof MySql) { //connect with MySql } } }

Sau đó yêu cầu đưa ra phải kết nối thêm đến Oracle và một vài hệ CSDL khác. Để thêm chức năng ta phải thêm vào code những khối esleif khác, việc này làm code kềnh càng và khó quản lý hơn.

• Giải pháp:
  • Ứng dụng Abstract thiết kế lại các lớp SqlServer, MySql, Oracle…
  • Các lớp này đều phải có chung nhiệm vụ tạo kết nối đến csdl tương ứng có thể gọi chung là Connection.
  • Phương pháp kết nối đến csdl thay đổi tùy thuộc vào từng loại kết nối nhưng có thể gọi chung là doConect.
  • Vậy ta có lớp cơ sở Connection có phương thức doConnect, các lớp cụ thể là SqlServer, MySql, Oracle… thừa hưởng từ Connection và overwrite lại phương thức doConnect phù phù hợp với lớp đó.

Thiết kế sau thời điểm làm lại sở hữu dạng như sau:

abstract class Connection() { public abstract function doConnect(); } class SqlServer extends Connection { public function doConnect() { //connect with SqlServer } } class MySql extends Connection { public function doConnect() { //connect with MySql } } class ConnectionManager { public function doConnection(Connection $connection) { //something //…………….. //connection $connection->doConnect(); } }

Với thiết kế này khi cần kết nối đến 1 loại csdl mới chỉ có thêm một lớp mới thừa hưởng Connection mà không cần sửa đổi code của lớp ConnectionManager, điều này thỏa mãn 2 ĐK của nguyên tắc OCP.

Liskov substitution principle

Nội dung:

Các đối tượng người dùng (instance) kiểu class con có thể thay thế các đối tượng người dùng kiểu class cha mà không khiến ra lỗi.

Nguyên tắc thứ 3, ứng với chữ L trong SOLID.

Quay trở lại ví dụ lớp Emloyee trong phần 1, ta giả sử có đơn vị sẽ điểm danh vào mỗi buổi sáng, và chỉ có những viên chức thuộc biên chế chính thức mới được phép điểm danh. Ta bổ sung phương thức checkAttendance() vào lớp Employee.

Hình dung có một trường hợp sau: đơn vị thuê một viên chức lao công để làm vệ sinh văn phòng, mặc dù là một người thao tác làm việc cho đơn vị nhưng do không được cấp số ID nên không được xem là một viên chức thường nhật, mà chỉ là một viên chức thời vụ, do này sẽ không được điểm danh.

Nguyên tắc này nói rằng: Nếu tất cả chúng ta tạo ra một lớp CleanerStaff thừa hưởng từ lớp Employee, và implement hàm working() cho lớp này, thì mọi thứ đều ổn, tuy nhiên lớp mới này cũng lại sở hữu hàm checkAttendance() để điểm danh, mà như vậy là sai quy định dẫn đến Khóa học bị lỗi. Như vậy, thiết kế lớp CleanerStaff thừa hưởng từ lớp Employee là không được phép.

Có nhiều phương pháp để giải quyết và xử lý tình huống này ví dụ như tách hàm checkAttendance() ra một interface riêng và chỉ cho những lớp Developer, Tester và Salesman implements interface này.

Interface segregation principle

Nội dung:

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 tiêu cụ thể.

Nguyên tắc này rất dễ hiểu. Hãy tưởng tượng tất cả chúng ta có một interface lớn, khoảng tầm 100 methods. Việc implements sẽ rất vất vả vì các class impliment interface này sẽ nên cần phải phải thực thi toàn bộ các method của interface. Ngoài ra còn tồn tại thể dư thừa vì 1 class không cần dùng hết 100 method. Khi tách interface ra thành nhiều interface nhỏ, gồm các method liên quan tới nhau, việc implement và quản lý sẽ dễ hơn.

Ví dụ:

Xem Thêm : Love Spell là gì? Bùa yêu Love spell có hiệu quả hay bị quật không?

Tất cả chúng ta có một interface Animal như sau:

interface Animal { void eat(); void run(); void fly(); }

Tất cả chúng ta có 2 class Dog và Snake implement interface Animal. Nhưng thật vô lý, Dog thì làm thế nào có thể fly(), cũng như Snake không thể nào run() được? Thay vào đó, tất cả chúng ta nên tách thành 3 interface như vậy này:

interface Animal { void eat(); } interface RunnableAnimal extends Animal { void run(); } interface FlyableAnimal extends Animal { void fly(); }

Dependency inversion principle

Nội dung:

1.Các module cấp cao không nên phụ thuộc vào các modules thấp cấp. Cả hai nên phụ thuộc vào abstraction. 2.Interface (abstraction) không nên phụ thuộc vào cụ thể, mà trái lại (Các class giao tiếp với nhau thông qua interface (abstraction), không phải thông qua implementation.)

Có thể hiểu nguyên lí này như sau: những thành phần trong một Khóa học nên làm phụ thuộc vào những cái trừu tượng (abstraction). 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 mang tính cụ thể mà nên trái lại.

Những cái trừu tượng (abstraction) là những cái ít thay đổi và biến động, nó tập hợp những đặc tính chung nhất của những cái cụ thể. Những cái cụ thể dù khác nhau thế nào đi nữa đều tuân theo những quy tắc chung mà cái trừu tượng đã định ra. Việc phụ thuộc vào cái trừu tượng sẽ giúp Khóa học linh động và thích ứng tốt với những sự thay đổi diễn ra liên tục.

Xem Thêm : Hạt kê có tác dụng gì đối với sức khỏe? Cách dùng thế nào?

Ví dụ:

Lấy ví dụ về ổ cứng của máy tính, chúng ta cũng có thể dùng loại ổ cứng thể rắn SSD đời mới để chạy cho nhanh, tuy nhiên cũng sẽ có thể dùng ổ đĩa quay HDD thông thường. Nhà sinh sản Mainboard không thể nào biết các bạn sẽ dùng ổ SSD hay loại HDD đĩa quay thông thường. Tuy nhiên họ sẽ luôn đảm nói rằng chúng ta cũng có thể dùng bất kì thứ gì bạn muốn, miễn sao ổ đĩa cứng đó phải có chuẩn giao tiếp SATA để sở hữu thể gắn được vào bo mạch chủ. Ở đây chuẩn giao tiếp SATA đó chính là interface, còn SSD hay HDD đĩa quay là implementation cụ thể.

Trong những khi lập trình cũng vậy, khi ứng dụng nguyên tắc này, ở những lớp trừu tượng cấp cao, ta thường sử dụng interface nhiều hơn thay vì một kiểu thừa hưởng cụ thể. Ví dụ, để kết nối tới Database, ta thường thiết kế lớp trừu tượng DataAccess có những phương thức phương thức chung như save(), get(), … Sau đó tùy vào việc sử dụng loại DBMS nào (vd: MySql, MongoDB, …) mà ta thừa hưởng và implement những phương thức này. Tính chất đa hình của OOP được vận dụng rất nhiều trong nguyên tắc này.

Tổng kết

SOLID là 5 nguyên tắc cơ bản trong việc thiết kế phần mềm. Nó giúp tất cả chúng ta tổ chức sắp xếp các function, method, class một cách xác thực hơn. Làm thế nào để kết nối các thành phần, module với nhau.

Rõ ràng, dễ hiểu

Teamwork là điều không thể tránh trong lập trình. Ứng dụng SOLID vào công việc các bạn sẽ tạo ra các hàm tốt, dễ hiểu hơn. Hỗ trợ cho bạn và đồng nghiệp đọc hiểu code của nhau tốt hơn.

Dễ thay đổi

SOLID giúp tạo ra các module, class rõ ràng, mạch lạc, mang tính độc lập cao. Do vậy khi có sự yêu cầu thay đổi, mở rộng từ khách hàng, ta cũng không tốn quá nhiều sức lực để thực hiện việc thay đổi.

Tái sử dụng

SOLID khiến các lập trình viên suy nghĩ nhiều hơn về phong thái viết phần mềm, do vậy code viết ra sẽ mạch lạc, dễ hiểu, dễ sử dụng.

Nguồn tham khảo:

• Những dòng code vui
• Kipalog

Tham khảo thêm các vị trí tuyển dụng lập trình it lương chất lượng cao tại Topdev