Thứ Bảy, 23 tháng 1, 2021

SERIES SOLID PHẦN 2: Single Responsibility Principle



Nội dung nguyên lý : Một class chỉ giữ một trách nhiệm duy nhất , hay nói cách khác , muốn modify class này thì chỉ có một lý do duy nhất





Vi phạm SRP( Single Responsibility Principle)


Ta có ví dụ điển hình trên, một con dao có quá nhiều chức năng. Khi một phần nào đó trong dao bị hư, ta phải tháo ra toàn bộ chức năng sau đó lấp lại, trong khi đó các con dao khác lại không bị hư hỏng gì => tốn kém, tốn thời gian modify, quản lý thời gian không hiệu quả.


Tại sao nên áp dụng SRP?

  • Đối với các quy trình phần mềm nói chung việc thay đổi requirement là liên tục và rất dynamic , vì vậy việc chỉnh sửa code cũng liên tục.
  • Việc một class quá to sẽ rất khó quản lý , quá cồng kềnh dẫn đến modify rất cực , muốn modify phải đọc lại toàn source?
  • Dễ ảnh hưởng đển các module khác.

Áp dụng Single responsibility principle như thế nào?

Để áp dụng với single responsibility principle cụ thể với con dao phía trên ta chỉ phần tách các con dao chức năng thành các class nhỏ hơn, thế là xong. Khi 1 phần dao nào hư, chỉ cần sữa mỗi con dao đó là được.

KẾT LUẬN

Đây là nguyên lý cơ bản và dễ hiểu nhất mà cũng dễ vi phạm nhất, cho nên nó chỉ ngắn gọn như vậy. Tuy nhiên ở một số dự án cụ thể nào đó thì việc gom nhóm chức năng để chia module là việc rất khó đòi hỏi phải có kinh nghiệm.

Cũng có một số lời phản bác, war với nhau trên nhiều diễn đàn "Tao éo thích Single Responsibility Principle" , bla bla bla nhưng mình thấy tụi này rãnh rỗi chả có gì làm, luận điểm đưa ra thì kém thuyết phục nên khuyên các bạn đừng đọc cho mất công :))


Share:

Thứ Sáu, 22 tháng 1, 2021

SERIES SOLID PHẦN 1: SOLID là gì? 5 nguyên tắc vàng cho dev xịn


Theo sách game programming pattern: một kiến trúc phần mềm tốt là một phần mềm được thiết kế như thể nó đúng hoàn toàn như dự đoán từ đầu đã đề ra, nghĩa là ta sẽ giải quyết mọi task một cách dễ dàng chỉ với một vài function với vị trí đặt function là hoàn hảo, không ảnh hưởng đến các đoạn mã đã viết, không để lại một chút "gợn" nào trên bề mặt yên bình của các dòng mã.

Đễ làm được điều đó dễ dàng, các dev như chúng ta không thể nào bỏ qua được SOLID, những nguyên lý vàng trong việc phát triển và xây dựng phần mềm( tất nhiên phải có sự kết hợp của cả design pattern, nhưng trong phạm vi bài này mình sẽ chỉ nói SOLID)

SOLID RA ĐỜI NHƯ THẾ NÀO?

Lập trình hướng đối tượng là mô hình lập trình cực kì mạnh mẽ và được áp dụng nhiều nhất ngày nay, Các tính chất đặc biệt của nó khiến nó trở nên nổi bật hơn bất kì mô hình lập trình nào khác đó chính là:

  • Encapsulation( Đóng gói )
  • Abstraction( Trừ tượng )
  • Inheritance( Kế thừa )
  • Polymorphism( Đa hình )

Tuy nhiên, không phải lập trình viên nào cũng biết cách kết hợp các tính chất này lại sao cho hiệu quả => Từ đó SOLID bao gồm 5 nguyên lý giúp lập trình viên hiểu được những cách phối hợp các tính chất này lại với nhau để tăng hiệu quả của phần mềm.

SOLID LÀ GÌ?

SOLID là viết tắt của 5 nguyên lý đầu tiên trong Object Oriented Design( OOD ) bao gồm:

( để hiểu chi tiết về các nguyên lý, bấm vào link nhé, mình sẽ chia làm 6 phần trong series này )

TẠI SAO CẦN PHẢI CÓ SOLID


Những nguyên lý này được hình thành để cho phép việc phát triển phần mềm dễ dàng và linh hoạt hơn trong việc maintain và extend khi dự án lớn dần. Ngoài ra, nó còn giúp chúng ta tránh được việc code smells( code như shit ), refactoring code,…


Share: