Giới thiệu ngắn gọn về Design Patterns trong phát triển Web

2237

Lời giới thiệu

Đây là bài viết về các Design Pattern dựa trên những gì tôi đã học được chủ yếu từ Gang of Four. Song song đó, tôi sẽ cố gắng tập trung vào full stack web với các ví dụ cực kỳ thiết thực. Hầu hết trong số đó sẽ là về JavaScript hoặc Python, vì các ngôn ngữ khác đã có nhiều tài liệu về chủ đề này.

Design Pattern là gì?

Giống như mọi người trong số các bạn tin rằng mình là người nấu ăn giỏi nhất trên thế giới nhờ vào sự đặc biệt, độc nhất vô nhị của mình, tất cả chúng ta đều có thể đồng ý rằng có một cuốn sách công thức tốt có thể biến hầu hết mọi người thành đầu bếp giỏi.

Lý do là khá đơn giản: tất cả những công thức nấu ăn đã được tạo ra bởi một người – sau khi đã trải qua rất nhiều sai lầm trên đường đi và đưa ra các sửa đổi thiết thực. Sử dụng những kiến ​​thức này sẽ giúp bạn tránh được nhiều cạm bẫy thường gặp và những quyết định sai lầm. Điều này cực kỳ hữu ích trong những trường hợp mà tưởng chừng như vô hại.

Đồng thời công thức nấu ăn có thể được sử dụng như một khuôn mẫu để dựa trên chứ không phải là một bộ quy tắc phải tuân theo một cách thô kệch.

Tương tự trong phát triển phần mềm cũng hoạt động theo cùng một cách. Điểm khác biệt chính là các dự án phát triển phần mềm thường kéo dài hơn cũng như kết quả của nó sẽ khá là ảnh hưởng đến bạn và cả những người xung quanh.

Nói cách khác, Design Pattern có thể xem như là một điểm khởi đầu tốt để giải quyết các vấn đề thường gặp.

Điểm bất cập của nó

Design pattern thật sự rất hữu ích nhưng nó cũng thay thế cả quá trình ra quyết định của bạn.

Đây là lập luận phổ biến nhất được đưa ra để chống lại việc sử dụng phương pháp tiếp cận bằng design pattern trong phát triển phần mềm: các giải pháp được cung cấp từ chúng có xu hướng không được hiệu quả vì nó có thể chỉ dành cho các vấn đề rất cụ thể.

Với tôi đây là một điểm yếu mà bạn phải luôn luôn cải thiện hoặc ít nhất là thích nghi với một trong những giải pháp cho nhu cầu của mình. Các Design Pattern đã vượt qua thử thách của thời gian sẽ cung cấp cho bạn lợi thế của việc biết trước hầu hết các điểm yếu của nó, vì vậy bạn sẽ có một sự hiểu biết tốt hơn về cách giải quyết các vấn đề có thể sảy ra.

Một lập luận phổ biến khác chống lại design pattern là việc một số kiểu (hay còn gọi là Gang of Four) đã trở nên một chút “lỗi thời” so với những gì chúng ta có ngày nay.

Vâng, tôi không thể không đồng ý với điều này, nhưng “Kiến thức là sức mạnh” và tôi thà có một công cụ tôi không sử dụng hơn là thiếu một công cụ mình cần.

Điều này, tuy nhiên, dẫn đến những lời chỉ trích khác mà tôi muốn nói tới ở đây. Một trong những rủi ro của design pattern là bạn có thể sẽ sử dụng chúng ngay cả trong các tình huống không cần đến.

Tôi đoán đây là một vấn đề khá phổ biến với bất kỳ thứ gì được số đông sử dụng. Thật không may, kinh nghiệm vẫn sẽ là cách tốt nhất để giúp bạn vượt qua trường hợp này.

Phân loại các design pattern

ngày nay, chúng ta vẫn phân loại các design pattern thành 3 nhóm sau:

Creational Patterns

  • Abstract Factory
  • Builder
  • Factory
  • Prototype
  • Singleton

Structural Patterns

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

Behavioral Patterns

  • Chain of responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template method
  • Visitor

Đây là một bài giới thiệu chung ngắn gọn và hy vọng không nhàm chán về các design pattern. Trong các bài viết tiếp theo tôi sẽ đi sâu vào những ví dụ thực tế và ít phức tạp hơn.

Techtalk via Dev.to

CHIA SẺ