Mẫu thiết kế là công cụ. Giống như các công cụ, có hai cách để sử dụng chúng: cách chính xác và cách không chính xác. Ví dụ, nếu tôi đưa cho bạn một cái tuốc nơ vít và một cái đinh, và yêu cầu bạn nối hai miếng gỗ lại với nhau, bạn nên yêu cầu tôi lấy một cái búa. Búa được sử dụng cho đinh, trong khi tua vít được sử dụng cho ốc vít.
Quá thường xuyên, một mẫu thiết kế được quảng cáo là One True Way, thường chỉ đúng khi có vấn đề cụ thể phát sinh. Các nhà phát triển cơ sở thường giống như trẻ em khi họ tìm thấy thứ gì đó mới để chơi cùng; họ muốn áp dụng mô hình thiết kế đó cho mọi thứ . Và không có gì sai với nó, miễn là cuối cùng họ biết rằng Mẫu A áp dụng cho Vấn đề B và Mẫu C áp dụng cho Vấn đề D. Giống như bạn không sử dụng tuốc nơ vít để lái đinh, bạn không sử dụng cụ thể mô hình chỉ vì nó tồn tại; bạn sử dụng mô hình vì đó là công cụ tốt nhất (được biết đến) cho công việc.
Mặt trái của các mẫu là chống mẫu. Những thứ đã được chứng minh hết lần này đến lần khác là xấu, thường là về thời gian thực hiện hoặc bộ nhớ. Tuy nhiên, cả mẫu và mẫu chống đều không tốt cho nhà phát triển mà không hiểu tại sao chúng tồn tại. Các nhà phát triển muốn nghĩ rằng những gì họ đang làm là mới và sáng tạo, nhưng hầu hết thời gian, họ không làm. Nó có thể đã được nghĩ đến trước đây. Những người trước họ đã tạo ra các mô hình vì kinh nghiệm.
Tất nhiên, các nhà phát triển cơ sở thường dường như nghĩ ra những cách mới để làm những việc cũ, và đôi khi những cách đó tốt hơn. Tuy nhiên, quá thường xuyên, nó trở thành một trường hợp của hiệu ứng Dunning-Kruger; nhà phát triển biết chỉ đủ để tạo ra một chương trình chức năng, nhưng không hiểu giới hạn của chính họ. Cách duy nhất để vượt qua điều này dường như là thông qua kinh nghiệm, cả tích cực và tiêu cực. Họ bỏ qua các mẫu vì họ tin rằng mình vượt trội, nhưng không biết rằng, trên thực tế, 10.000 nhà phát triển đã sử dụng một thiết kế cụ thể và sau đó loại bỏ nó vì nó thực sự xấu.
Agile ủng hộ "hoàn thành công việc một cách nhanh chóng" liên quan đến việc điều chỉnh nhanh chóng để phát triển nhu cầu của khách hàng. Nó không ủng hộ các mẫu thiết kế cũng không coi thường chúng. Nếu một mẫu là phương pháp nhanh nhất, đáng tin cậy nhất, thì nhà phát triển nên sử dụng nó. Nếu một mẫu cụ thể sẽ tốn nhiều thời gian hơn chỉ đơn giản là "hoàn thành nó", sử dụng một thứ không phải là mẫu có thể sẽ ổn (tất nhiên, giả sử, hiệu suất đó không bị suy giảm nghiêm trọng, v.v.). Nếu không tìm thấy mô hình đã biết nào, thiết kế riêng của họ được ưu tiên hơn là nói với khách hàng "không." Khách hàng, đặc biệt là khách hàng trả tiền, thường đúng.
Bất cứ ai tuyên bố rằng các mẫu là The Way, hoặc tuyên bố rằng các mẫu đó là The Bane Of Existence, đều sai. Các mẫu là các công cụ, có nghĩa là được áp dụng cho các tình huống cụ thể và có mức độ thành công khác nhau dựa trên hoàn cảnh. Đây là một Sự thật, một điều không phụ thuộc vào việc bạn có chọn MVC hay không, nếu bạn sử dụng Đối tượng truyền dữ liệu hay không, v.v. Điều quan trọng là triển khai mã trong khung thời gian ngắn hợp lý, hoạt động tốt cho người dùng, và là hợp lý không có lỗi logic.
Thông thường , các mẫu sẽ cho phép một hình thức thiết kế mạch lạc và sẽ hoạt động tốt hơn là bỏ qua tất cả các mẫu có lợi cho việc viết 100% ý tưởng ban đầu, nhưng bạn không thể tránh tất cả các mẫu. Ví dụ: nếu y = x + 5, bạn có thực sự sẽ viết y = x + (5 * 3 + 15/3) / 4, chỉ để tránh mô hình viết x + 5? Số bạn không. Bạn sẽ viết y = x + 5 và chuyển sang vấn đề tiếp theo.
Mọi người sử dụng các mẫu mỗi ngày, và điều đó không sao . Điều quan trọng nhất là có mã có chức năng logic, hiếm khi gặp sự cố và thân thiện với người dùng. Không có gì khác quan trọng hơn thế.