Các nguyên tắc, định luật cần nắm khi lập trình



  • Lời mở đầu:

    Thomas Paine- một triết gia người Anh từng nói:
    "An army of principles can penetrate where an army of soldiers cannot" (Đội quân nguyên tắc có thể xuyên thủng cả những nơi mà đội quân con người không thể ).

    Từ đó ta có thể thấy được lợi ích, sức mạnh mà những nguyên tắc mang lại là to lớn như thế nào.

    Và trong trong bài viết này, mình xin đưa ra một số nguyên tắc để cung cấp "sức mạnh" cho các bạn trên con đường lập trình.

    Một số nguyên tắc phổ biến

    Nguyên tắc KISS (không phải hôn hít gì đâu ^^):

    KISS = Keep It Simple Stupid

    KISS có nhiều biến thể khác nhau như "Keep It Short and Simple", "Keep It Simple and Straightforward" and "Keep It Small and Simple".

    Tựu chung lại, hàm ý của nó vẫn hướng về một sự đơn giản và rõ ràng trong mọi vấn đề, sự đơn giản là mục đích trọng tâm trong thiết kế, còn những cái phức tạp không cần thiết thì nên tránh.

    Và trong lập trình, hãy làm cho mọi thứ (mã lệnh của bạn) trở nên đơn giản và dễ nhìn hơn. Hãy chia nhỏ vấn đề ra những bài toán nhỏ đơn giản hơn, viết mã để xử lý nó, biến nó thành các lớp và các hàm riêng biệt, đừng để một lớp hay một phương thức có hàng trăm dòng lệnh, hãy để nó trở về con số chục thôi. Đừng viết những lớp hay phương thức theo kiểu spaghetti hay all-in-one (tất cả trong một) như dao thụy sĩ, hãy để mọi thứ thật đơn giản để bạn luôn có thể hiểu được, và kết hợp chúng với nhau để giải quyết được các bài toán lớn.

    Nguyên tắc YAGNI:

    YAGNI = You Aren’t Gonna Need It
    YAGNI là nguyên tắc nằm trong quy trình lập trình cực hạn-Extreme Programming (XP) “Chưa phải lúc cần thiết thì chưa được phép làm”.

    Nếu bạn muốn code thêm những tính năng không cần thiết ở thời điểm hiện tại nhưng bạn nghĩ nó sẽ hữu dụng trong tương lai, hãy cứ bình tĩnh và xem lại những công việc đang chờ bạn giải quyết ngay. Bạn không thể lãng phí thời gian của mình để code những tính năng mà bạn sẽ phải sửa nó hay thay đổi nó bởi vì nó không phù hợp với nhu cầu của khách hàng, hay trong trường hợp xấu nhất là nó sẽ không được sử dụng đến.

    Hiểu đơn giản thì bạn cứ tập trung vào những thứ bạn chắc chắn cần ở thời điểm hiện tại, đừng có "đứng núi này trông núi nọ".

    Nguyên tắc DRY:

    DRY = Don’t Repeat Yourself

    Nguyên tắc này chỉ ra rằng nếu chúng ta đang muốn viết nhiều đoạn code giống nhau ở nhiều chỗ khác nhau, thay vì copy và paste đoạn code đó, chúng ta hãy đưa đoạn code đó vào một phương thức riêng sau đó gọi phương thức này từ những chỗ chúng ta cần gọi.

    Nghe quen quen đúng không, tính kế thừa trong lập trình hướng đối tượng (Object oriented programming- OOP) cũng tuân theo nguyên tắc này. Quá đơn giản phải không?

    Nguyên tắc SOLID:

    1. Single responsibility principle (SRP)

    Được hiểu là một class chỉ chịu một trách nhiệm duy nhất (mỗi một thay đổi trong tài liệu mô tả sẽ chỉ ảnh hưởng tới một class cụ thể )

    Tức là một class chỉ nên thực hiện công việc/thao tác cụ thể. Để nếu xảy ra lỗi/muốn thay đổi thao tác đó thì ta chỉ cần sửa đổi duy nhất một class thôi.

    Nguyên tắc này có thể khiến cho số lượng class nhiều lên nhưng chắc chắn sẽ dễ dàng hơn trong việc quản lý, sửa chữa và mở rộng.

    2. Open/closed principle (OCP)

    Được hiểu là: Có thể thoải mái mở rộng 1 class, nhưng không được sửa đổi bên trong class đó.

    Theo nguyên lý này, mỗi khi ta muốn thêm chức năng,.. cho chương trình, chúng ta nên viết class mới mở rộng class cũ ( bằng cách kế thừa hoặc sở hữu class cũ) chứ không nên sửa đổi trực tiếp class cũ.

    3. Liskov substitution principle (LSP)

    Được hiểu là: Trong một chương trình, các object của class con có thể thay thế class cha mà không làm thay đổi tính đúng đắn của chương trình

    Đọc không thì khá là khó hiểu, cho nên mình sẽ lấy một ví dụ cho các bạn.

    "Hãy tưởng tượng bạn có 1 class cha tên Vịt. Các class VịtBầu, VịtXiêm có thể kế thừa class này, chương trình chạy bình thường. Tuy nhiên nếu ta viết class VịtChạyPin, cần pin mới chạy được. Khi class này kế thừa class Vịt, vì không có pin không chạy được, sẽ gây lỗi. Đó là 1 trường hợp vi phạm nguyên lý này."

    4. Interface segregation principle (ISP)

    Được hiểu là 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ể.

    Nguyên lý này khá dễ hiểu. Hãy tưởng tượng chúng ta có 1 interface lớn, khoảng 100 methods. Việc implements sẽ khá cực khổ, ngoài ra còn có 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.

    5. Dependency inversion principle (DIP)

    Nội dung gồm 2 phần:

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

    Có vẻ hơi hại não nhỉ, mình sẽ lấy ví dụ thực tế.

    "Chúng ta đều biết 2 loại đèn: đèn tròn và đèn huỳnh quang. Chúng cùng có đuôi tròn, do đó ta có thể thay thế đèn tròn bằng đèn huỳnh quanh cho nhau 1 cách dễ dàng.

    Ở đây, interface chính là đuôi tròn, implementation là bóng đèn tròn và bóng đèn huỳnh quang. Ta có thể swap dễ dàng giữa 2 loại bóng vì ổ điện chỉ quan tâm tới interface (đuôi tròn), không quan tâm tới implementation."

    Có ví dụ thực tế thì dễ hiểu hơn rồi đúng không?

    Kết:

    Trên đây là một số nguyên tắc cơ bản khi lập trình (mà mình đọc và hiểu được) mình muốn chia sẻ với các bạn. Nó đã có ích với mình và mong rằng cũng có thể hỗ trợ cho các bạn phần nào.

    Tham khảo:

    https://viblo.asia/p/nhung-nguyen-tac-nhung-dinh-luat-cua-lap-trinh-ma-chung-ta-nen-co-san-trong-dau-wpVYRP2kG4ng

    https://trello.com/c/nVYxJS6h/68-nguyên-lý-kiss-trong-lập-trình

    https://toidicodedao.com/2015/03/24/solid-la-gi-ap-dung-cac-nguyen-ly-solid-de-tro-thanh-lap-trinh-vien-code-cung/
    Nguồn: Viblo


Hãy đăng nhập để trả lời
 

Có vẻ như bạn đã mất kết nối tới LaptrinhX, vui lòng đợi một lúc để chúng tôi thử kết nối lại.