Tìm kiếm bài viết

Tản mạn công nghệ: Design pattern

09.11.2020

0/5 (0 Reviews)

Trong công nghệ phần mềm, một mẫu thiết kế (tiếng Anh: design pattern) là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm.

    Design pattern

    Theo các trang nước ngoài và wiki thì người ta ghi thế này:

    Trong công nghệ phần mềm, một mẫu thiết kế (tiếng Anh: design pattern) là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm. Một mẫu thiết kế không phải là một thiết kế hoàn thiện để mà có thể được chuyển đổi trực tiếp thành mã; nó chỉ là một mô tả hay là sườn (template) mô tả cách giải quyết một vấn đề mà có thể được dùng trong nhiều tình huống khác nhau. Các mẫu thiết kế hướng đối tượng thường cho thấy mối quan hệ và sự tương tác giữa các lớp hay các đối tượng, mà không cần chỉ rõ các lớp hay đối tượng của từng ứng dụng cụ thể. Các giải thuật không được xem là các mẫu thiết kế, vì chúng giải quyết các vấn đề về tính toán hơn là các vấn đề về thiết kế.

     

    Dùng Design pattern có lợi ích gì

    Trong quá trình làm dự án, có 1 điều chắc chắn luôn xảy ra, đó là sự thay đổi về yêu cầu từ khách hàng. Lúc này đương nhiên dự án của chúng ta sẽ phình to hơn về mọi mặt, thêm chức năng, thêm component, thêm ti tỉ thứ nhưng vẫn phải đảm bảo về mặt performance. ==> Và đây là lúc, Design pattern tỏa sáng , nó cung cấp cho ta những giải pháp đã được tối ưu hóa, đã được kiểm chứng để giải quyết các vấn đề trong software engineering. Nó đóng góp vai trò như 1 kim chỉ nam cho bạn, các giải pháp luôn ở dạng tổng quát, giúp tăng tốc độ phát triển phần mềm bằng cách đưa ra các mô hình test, mô hình phát triển đã qua kiểm nghiệm.

    Hơn nữa, dùng lại các design pattern đã được các đồng đạo khác công nhận, cũng giúp ta tránh được các vấn đề tiềm ẩn có thể gây ra những lỗi lớn, dễ dàng nâng cấp, bảo trì về sau.

    Giúp cho các lập trình viên có thể hiểu code của người khác 1 cách nhanh chóng, vì người ta có thể biết bạn đang áp dụng theo cách nào khi đọc code. Mọi thành viên trong team có thể dễ dàng trao đổi với nhau để cùng xây dựng dự án mà không mất quá nhiều thời gian.

     

    Để học Design pattern, bạn cần ...

    • Vì Design Pattern sử dụng nền tảng của lập trình hướng đối tượng nên nó sẽ áp dụng 4 đặc tính của OOP: Kế Thừa , Đa Hình, Trừu Tượng, Bao Đóng. => Bạn phải nắm kỹ 4 khái niệm đó không chỉ về lý thuyết

    • Hiểu và áp dụng các khái niệm đặc biệt là về abstract class,interface và static vì nó rất cần thiết.

    • Tư duy hoàn toàn theo OOP, loại bỏ tư duy theo lối cấu trúc.

     

    Phân loại

    Về công pháp thì design pattern sẽ được chia ra làm 3 loại lớn, bao gồm:

    Creational Pattern ( loại khởi tạo): loại này sẽ giúp bạn trong việc khởi tạo đối tượng, gồm 9 mẫu design là:

    • Abstract Factory.

    • Builder.

    • Factory Method.

    • Multiton.

    • Pool.

    • Prototype.

    • Simple Factory.

    • Singleton.

    • Static Factory.

    Structural (loại cấu trúc): Loại này sẽ giúp chúng ta thiết lập, định nghĩa quan hệ giữa các đối tượng, gồm 11 mẫu design là:

    • Adapter/ Wrapper.

    • Bridge.

    • Composite.

    • Data Mapper.

    • Decorator.

    • Dependency Injection.

    • Facade.

    • Fluent Interface.

    • Flyweight.

    • Registry.

    • Proxy.

    Behavioral patterns (loại ứng xử): loại này sẽ tập trung thực hiện các hành vi của đối tượng, Gồm 12 mẫu design là:

    • Chain Of Responsibilities.

    • Command.

    • Iterator.

    • Mediator.

    • Memento.

    • Null Object.

    • Observer.

    • Specification.

    • State.

    • Strategy.

    • Template Method.

    • Visitor.

     

    Khi nào nên dùng Design pattern

    • Khi bạn muốn giảm được thời gian và công sức suy nghĩ ra các cách giải quyết cho những vấn đề đã có lời giải => xài design pattern.

    • Khi bạn muốn chương trình chạy uyển chuyển hơn, dễ dàng quản lý tiến trình hoạt động, dễ nâng cấp bảo trì khi dự án phình to => xài design pattern

    • Tuy nhiên, vì design pattern là 1 giải pháp chung nên nó khá là trừu tượng và khó nhằn => không dễ gì mà áp dụng vào 1 dự án đã có sẵn mà bạn không nắm rõ hoặc code và dự án khá phức tạp và nhiều.

     

    CÓ THỂ BẠN QUAN TÂM

    Bài Viết Cùng Chuyên Mục

    XEM THÊM
    thumbnail

    Kubernetes bài 6 - Vận hành k8s Day-Two Operations và Quản trị bằng GitOps

    22.05.2026

    Khi cụm Kubernetes của bạn đã được bảo mật cấu hình, tối ưu tài nguyên và thiết lập tự phục hồi, câu hỏi đặt ra là làm sao để duy trì sự ổn định đó trong nhiều năm tiếp theo mà không bị phụ thuộc

    thumbnail

    Kubernetes bài 5 - bảo mật Cloud Native và chuẩn DevSecOps cho K8s

    22.05.2026

    Việc siết chặt an ninh (Hardening) không phải là cấu hình một vài thông số rồi bỏ đó, mà là một tư duy phòng thủ chiều sâu.

    thumbnail

    Kubernetes bài 4 - Tối ưu Resource Auto-Healing và Scale Zero-Downtime

    22.05.2026

    Bài viết này sẽ đi sâu vào các cơ chế ở tầng Kernel giúp hệ thống tự phục hồi, chống lại các đợt tấn công cạn kiệt tài nguyên và cập nhật phiên bản mới mà người dùng không hề hay biết.

    thumbnail

    Kubernetes bài 3 - Bảo mật cấu hình k8s và config Security trên Production

    22.05.2026

    Kubernetes giải quyết bài toán này bằng hai đối tượng chuyên biệt nhưng nếu không hiểu rõ bản chất bảo mật ở tầng dưới, bạn đang tự tay dâng toàn bộ chìa khóa hệ thống cho hacker.

    thumbnail

    Kubernetes bài 2 - Mạng lưới k8s và luồng Traffic ở Packet Level

    22.05.2026

    Pod không chỉ là một container: Rất nhiều người nhầm lẫn Pod 1-1 với Container. Thực chất, Pod là đơn vị triển khai nhỏ nhất, có thể chứa một hoặc nhiều container

    Mục lục bài viết