Design Patterns - Hiểu đúng và vận dụng đúng

Vì sao Design Patterns khó cho người mới?

Lý do cho cái khó này theo mình là: Các kiến trúc và Design Patterns có tính trừu tượng (abstraction) cao nên khá khó hiểu cho người mới. Sự thiếu hụt các trải nghiệm qua các vấn đề mà kiến trúc và các design patterns tập trung giải quyết nên rất mơ hồ. Trong bài này thì mình chỉ muốn nói về Design Patterns thôi cho đỡ lan man.

Theo quan sát bản thân mình khi các bạn mới tìm hiểu Design Patterns sẽ thường hay xem các tutorial, source code example để cho lẹ. Khổ cái là các ví dụ thường sẽ rất cơ bản, dẫn tới việc hiểu sai rằng chúng đang bị làm quá lên. Tức là thay vì ta code vài dòng là xong, đằng này tạo thêm rất nhiều class và các tầng trừu tượng khác. Suy nghĩ này khiến việc ứng dụng các Design Patterns rất hạn chế.

Hiểu sai về Design Patterns

Mặt khác nhiều bạn đang nghĩ rằng Design Patterns cũng là cái gì đó rất ghê gớm - là kỹ năng thượng thừa của các Seniors nhưng thật ra nó rất bình thường và đơn giản. Vốn dĩ nó đã đơn giản đến mức không thể đơn giản hơn được nữa... nếu nói về mức độ trừu tượng.

Để giải thích cho sự trừu tượng một cách đơn giản, các bạn có thể hình dung một ngôi nhà đầy đủ tiện nghi. Nếu bạn bỏ hết vật dụng đi thì nó vẫn là ngôi nhà, cạo hết vôi tường thì nó vẫn là ngôi nhà, bỏ đi vài cái cửa sổ cũng vậy. NHƯNG nếu bạn tháo cái nóc nhà ra thì nó không thể là ngôi nhà được nữa. Vì nhà là phải có nóc!

Design Patterns là gì?

Suy cho cùng thì các Design Patterns là những giải pháp được thiết kế cho các vấn đề lặp đi lặp lại thường xuyên trong quá trình phát triển ứng dụng (hay phần mềm). Bản thân Design Patterns không thể giải quyết hoàn toàn bài toán bạn đang gặp phải. Tuy nhiên nó là một template rất đáng kham thảo.

Một số ví dụ Design Patterns

Một ví dụ cho Abstract Factory (một pattern rất nổi tiếng), có thể các bạn sẽ coi đi coi lại code demo và vẫn thấy nó cứ "lấn cấn" hay tạo ra nhiều thứ phức tạp quá. Cách tiếp cận này mình gọi là "HOW" (dùng nó như thế nào). Sự thật là chúng ta đôi lần (hoặc rất thường xuyên) đối mặt với vấn đề - lý do mà nó được sinh ra (WHY - WHAT). Chúng ta thử xem một trường hợp sau đây nhé:

Chúng ta đang thiết kế giải pháp cho một hệ thống bao gồm 03 hệ thống nhỏ không thể tách rời khi vận hành. Tức là thiếu 1 trong 3 là không chạy được, sẽ có lỗi. Hệ thống này cần chạy trên các Platform khác nhau hoặc môi trường (environment) khác nhau như Dev, Staging, Production,... Ở mỗi Platform hoặc môi trường cụ thể ta cần thay thế 3 hệ thống con sao cho phù hợp để chạy ổn. Nếu không biết về pattern này, có thể các bạn sẽ giải quyết không hiệu quả và dẫn đến các technical debt hay anti-patterns về sau.

Ở một ví dụ khác, design patterns cũng đóng vai trò như lời giải cho các vấn đề thường gặp ở đời sống như: Ở một nhà hàng có 50 bàn ăn thì liệu chúng ta có cần 50 phục vụ? Đương nhiên là không vì chúng ta chỉ cần ít hơn 50 người và tái sử dụng lại khi họ "rảnh". Và đó chính là pattern "Object Pool" dùng để làm các Worker Pool.

Tương tự với các pattern khác, chúng đều có lý do và mục đích sinh ra (dù nhiều trong số chúng không quá khác biệt và có vẻ bị lặp lại). Biết được cái này (WHY) thì mình tin là các bạn sẽ tiếp thu các Design Patterns tốt hơn và vận dụng chúng hiệu quả hơn.

Lời kết

Lưu ý rằng bản thân Design Patterns cũng có những vấn đề như: nhiều patterns chỉ dùng được cho các OOP Language, tăng thêm các lớp trừu tượng đôi khi dẫn đến những giải pháp rất phức tạp (complex và overskill). Các bạn sẽ cần vận dụng linh hoạt và tinh chỉnh có được giải pháp tốt và phù hợp nhất.

Cá nhân mình vẫn cho là Design Patterns là một chủ đề hay và cần thiết để luyện tập. Nó cũng là nền tảng để hiểu các kiến trúc ứng dụng (dù thực tế các kiến trúc ứng dụng dùng rất ít các design patterns). Đặc biệt nếu bạn đang muốn tiến lên vị trí Software Architect hoặc phát triển các SDK, platform cho doanh nghiệp thì không nên xem thường nó nhé.

Chúc các bạn học Design Patterns thành công và đỡ bị tẩu hoả nhập ma như mình hồi xưa.