Dạo bài

Xin chào các bạn, là mình đây, một anh chàng IT thích chia sẻ kiến thức đến mọi người

Với mình, việc chia sẻ kiến thức vừa giúp được các bạn đọc khám phá được kiến thức mới, vừa giúp bản thân có thể ôn lại kiến thức cũng như nhận ra những kiến thức sai mà mình nghĩ rằng trước giờ mình đã nắm rõ nó. Các bài viết của mình được viết dựa trên quá trình mình học hỏi, đi làm và đúc kết được sau những năm tháng

Kiến thức là bao la, không thể nào học hết được mà chỉ có thể tích lũy hằng ngày để lượng kiến thức được vung đầy. Vậy hôm nay chúng ta cùng nhau tích lũy thêm lượng kiến thức mới gì đây nhỉ? Đó chính là Design Pattern

Mình cá là ở đây có nhiều bạn biết rất nhiều pattern, ngay cả mình cũng biết cả chục pattern. Biết là vậy nhưng bạn đã áp dụng được bao nhiêu mẫu vào dự án của bạn???

Anh Leader mình từng nói: "Nhiều ông biết lắm Design Pattern mà hỏi tới thì toàn trả lời suông chứ chưa áp dụng bao giờ", đúng là vậy các bạn à, biết là một chuyện, áp dụng chưa là một chuyện khác và áp dụng có đúng cách không là một chuyện khác khác nữa

Sau đây là cái nhìn khái quát về Design Pattern. Chúng ta trả lời theo 3W: What - When - Why

Design Pattern

What - Design Pattern là gì?

Design là Thiết kế, Pattern là Mẫu, dịch ra nghĩa là Mẫu thiết kế. Nghe lạ thật, mình có phải Designer hay kiến trúc sư đâu mà thiết kế gì đây nhỉ? Lúc đi học cũng chưa từng nghe đến, thầy cô cũng không dạy mình cái này, đã thế lúc đi phỏng vấn nhà tuyển dụng nào cũng thích hỏi đến nó

Hmm, vậy nó là gì mà các nhà lập trình viên chúng ta ai ai cũng cần nắm vững (nghe có vẻ dữ dằn, phóng đại vậy chứ là nó quan trọng thiệt đó các bạn)

Design Pattern là những giải pháp chung đã được tối ưu hóa để áp dụng vào phát triển phần mềm, những giải pháp này là tinh hoa của các kỹ sư phần mềm dày dặn kinh nghiệm đút kết được. Ngắn gọn là vậy nhưng có tới 2 ý mà chúng ta cần bận tâm, đầu tiên là đã được tối ưu - các giải pháp này đã được thử nghiệm và kiểm chứng, bạn chỉ việc là lựa chọn giải pháp phù hợp và áp dụng vào hệ thống, điều thứ 2 đó là nó được đúc kết từ những người có kinh nghiệm - cái này quan trọng, giống như đi làm mà được mấy ông senior chỉ có mấy cái tip trick hay ho vậy đó

When - Khi nào sử dụng nó?

Khi bạn thấy dự án của mình gặp phải những vấn đề mà hầu như những dự án khác đã gặp phải

Khi dự án bắt đầu lớn dần và trở nên phức tạp

Khi bạn muốn dự án của bạn quy tắc hơn, chuẩn mực hơn

Why - Tại sao nên và không nên sử dụng nó?

Why - Tại sao nên sử dụng nó?

Kinh nghiệm từ những người đi trước: Design Pattern là kết quả của sự tích lũy kinh nghiệm từ các kỹ sư phần mềm gạo cội. Sử dụng Design Pattern giúp mình tiếp cận kiến thức và kinh nghiệm từ những người đi trước, tránh được các lỗi phổ biến và áp dụng những phương pháp đã được kiểm chứng

Tiếng nói chung: Design Pattern cung cấp một ngôn ngữ chung để thảo luận về các vấn đề. Nó giúp các nhà phát triển có thể giao tiếp với nhau một cách hiệu quả hơn, chia sẻ kiến thức và ý tưởng, và hiểu rõ hơn về thiết kế của hệ thống

Tính linh hoạt, mở rộng và tái sử dụng cao: Cho phép bạn dễ dàng thay đổi, mở rộng và sử dụng lại mã nguồn mà không ảnh hưởng đến các phần khác trong hệ thống

Khả năng kiểm thử: Bạn có thể dễ dàng kiểm thử từng chức năng/module một mà không ảnh hưởng đến các phần khác trong hệ thống

Why - Tại sao không nên sử dụng nó?

Design Pattern áp dụng vào hệ thống lớn thì giúp giảm độ phức tạp xuống, nhưng nếu áp dụng vào hệ thống nhỏ thì lại tăng độ phức tạp lên bởi vì:

Phức tạp hóa không cần thiết: Sử dụng Design Pattern có thể làm tăng độ phức tạp của mã nguồn mà không có lợi ích rõ ràng. Design Pattern đòi hỏi bạn phải áp dụng các quy tắc và cấu trúc phức tạp, và điều này có thể làm cho mã nguồn trở nên khó hiểu và bảo trì

Tăng thời gian và tốn nhiều công sức: Sử dụng Design Pattern đòi hỏi thời gian và công sức để áp dụng và triển khai chúng. Thời gian và tài nguyên cho các dự án đều có giới hạn, và việc áp dụng Design Pattern có thể làm tăng thời gian phát triển và ảnh hưởng đến dự án

Kiến thức nâng cao: Sử dụng Design Pattern có thể làm cho mã nguồn trở nên phức tạp hơn đối với những lập trình viên mới tham gia dự án, một số Design Pattern đòi hỏi kiến thức và kinh nghiệm chuyên sâu để hiểu và triển khai. Nếu các bạn không quen với Design Pattern hoặc không có đủ kinh nghiệm, việc hiểu và bảo trì mã nguồn trở nên khó khăn hơn rất nhiều

🗯️ Hy vọng 3W trên đã đủ trả lời cho câu hỏi Tại sao các nhà tuyển dụng thích phỏng vấn Design Pattern?

Một số pattern phổ biến

Sau đây mình sẽ giới thiệu một số design pattern phổ biến, mình đưa ra usecase nên áp dụng pattern thay vì giải thích khái niệm nó là gì. Các bài viết sau mình sẽ đi vào cụ thể từng pattern

Singleton Pattern

• Hệ thống của bạn bao gồm các class như sau: Config, Main, Auth và Database. Config class có nhiệm vụ lấy các biến môi trường như PORT, JWT_SECRET, DB_USERNAME, DB_PASSWORD. Ở Main class bạn cần khởi tạo Config class để lấy PORT, Auth bạn cần khởi tạo Config class để lấy JWT_SECRET và Database thì khởi tạo Config để lấy DB_USERNAME, DB_PASSWORD. Sương sương là có tới 3 lần khởi tạo Config class, chưa kể trong một hệ thống có rất nhiều class khác cần Config class để lấy các biến môi trường
• N lần khởi tạo Config class là N lần phải xử lý logic để lấy các biến môi trường, ảnh hưởng lớn tới hiệu năng của hệ thống. Lúc này là lúc chúng ta nên áp dụng Singleton Pattern, pattern sẽ giúp Config class chỉ khởi tạo một lần duy nhất, và các class khác khi cần các biến môi trường thì không phải khởi tạo Config class lần nào nữa mà vẫn lấy được giá trị từ lần khởi tạo đầu tiên

Factory Pattern

• Bạn có 3 class Logger là GoogleLogger, TelegramLogger, LocalLogger. Bạn sử dụng 3 class này ở khắp nơi trong hệ thống của bạn, một ngày đẹp trời bạn cần update lại class GoogleLogger, thế là bạn phải đi tìm những chỗ sử dụng class này. Lúc này hệ thống chúng ta còn nhỏ nên chưa thành vấn đề, nhưng khi một hệ thống lớn dần thì nó trở nên rối mù, dễ dẫn tới sửa chỗ này nhưng quên chỉnh chỗ kia. Vì vậy, đã tới lúc nên dùng Factory Pattern, nhiệm vụ của bạn là tạo một lớp LoggerFactory để người dùng tương tác với lớp này, các class như GoogleLogger, TelegramLogger, LocalLogger được khởi tạo và quản lý bởi LoggerFactory

Decorator Pattern

• Hệ thống của bạn có một chức năng là login, thông thường chúng ta sẽ check xem username, password có empty không, có dài quá hay ngắn quá không? bạn sẽ check ở đâu? ngay trong hàm login? Okey, vẫn được thôi. Design Pattern như mình đã nói ở trên, nên áp dụng ở những dự án lớn, nếu dự án lớn thì sẽ có rất nhiều hàm cần check input có empty không, vì thế mình sẽ áp dụng Decorator Pattern để tạo ra một hàm checkEmptyInput riêng. Khi muốn check input có empty không của một hàm bất kỳ, mình sẽ bọc hàm checkEmptyInput ở ngoài các hàm đó, sau này muốn chỉnh sửa liên quan đến trường hợp empty thì chỉ cần sửa hàm checkEmptyInput thay vì sửa từng hàm kia

Strategy Pattern

Một vài chức năng sử dụng strategy pattern như:

• Login bằng google, github hoặc facebook - mỗi ứng dụng/nền tảng là một strategy
• Lưu trữ data ở local disk, google drive hoặc dropbox - mỗi storage là một strategy
• Gửi order qua các provider - mỗi provider là một strategy

Có nhiều bạn sẽ nghĩ rằng là mình mới biết design pattern mà sao có cảm giác như mình có code theo các usecase ở trên rồi phải. Đúng là vậy, một số ngôn ngữ, framework hay thư viện họ cũng dựa vào design pattern để xây dựng nên, chẳng hạn như Javascript thì có sử dụng module pattern (chia mã nguồn vào từng file khác nhau rồi import/export) hay là C# sử dụng Decorator pattern (mấy dấu @ đó các bạn), Hook pattern trong ReactJS (useState, useEffect)

Kết bài

Trong lĩnh vực Công nghệ thông tin, chúng ta luôn đối mặt với những vấn đề phổ biến. Thay vì phải dành kha khá nhiều thời gian và công sức để tự mình giải quyết, chúng ta nên học hỏi và sử dụng những nền tảng đã có để phát triển những giải pháp tốt hơn

Hành trình khám phá Design Pattern chỉ mới bắt đầu, phần giới thiệu này chủ yếu là lý thuyết suông, áp dụng vào dự án như thế nào mới là vấn đề. Nào cùng mình đến với những phần sau để xem mình áp dụng nó vào dự án thực tế như thế nào nhé. Cảm ơn các bạn đã đọc