Lập trình dựa trên mô hình là gì?

Ai đó có thể giải thích nỗi ám ảnh với các mẫu và chống mẫu trong lập trình? Tôi hỏi bởi vì tôi hoàn toàn không biết ý nghĩa của bất kỳ mô hình nào. Khi đối mặt với một nhiệm vụ lập trình, tôi nghĩ về vấn đề này một chút, viết ra một số cấu trúc dữ liệu mà tôi nghĩ sẽ có liên quan, tạo ra một giải pháp, tách ra một số mô-đun và lặp lại. Không nơi nào trong quá trình tôi nghĩ "Ồ, tôi cần mẫu FunkyLookyTastic ở đây".

Một mô hình là một cách tiếp cận phổ biến để giải quyết một loại vấn đề phổ biến; Không hơn không kém. Bằng cách biết và hiểu họ, bạn có thể sử dụng kinh nghiệm của người khác để hướng dẫn bạn về loại giải pháp đã được chứng minh là hoạt động tốt, tránh những cạm bẫy đã gặp phải trong quá khứ và thảo luận về giải pháp sử dụng thuật ngữ quen thuộc với những người khác biết mô hình đó.

Tất nhiên, bạn có thể đưa ra một giải pháp tốt mà không cần sử dụng một mẫu rõ ràng và cũng đưa ra một giải pháp tồi bằng cách thử áp dụng một mẫu không thực sự phù hợp với vấn đề cụ thể của bạn. Tôi nghĩ rằng "nỗi ám ảnh" mà bạn quan sát thường đến từ những người vừa khám phá ra khái niệm này và nghĩ rằng nó khá mạnh hơn thực tế. Hầu hết mọi người sẽ nhanh chóng nhận ra chúng vì những gì chúng là: một công cụ hữu ích, không phải là một viên đạn ma thuật.

Mặt khác, các mẫu chống là các hành vi thường được quan sát có xu hướng làm giảm chất lượng mã. Một lần nữa, thật hữu ích khi biết và hiểu một số trong số này để bạn có thể tránh hành vi đó và cố gắng sửa nó (với các lý lẽ hợp lý) khi bạn quan sát nó ở người khác. Một số người sẽ mô tả việc lạm dụng các mẫu như là một mẫu chống.

Các mẫu vừa là kiến ​​thức chắt lọc của các lập trình viên trong sách dạy nấu ăn, vừa là cách hữu ích để lập trình viên giao tiếp.

Như các câu trả lời khác cho thấy, các mẫu thực sự là giải pháp phổ biến cho các vấn đề phổ biến. Lợi ích là bạn thường có thể nhận được các giải pháp tốt hơn bằng cách sử dụng một mẫu hiện có hoặc khám phá những cạm bẫy có thể xảy ra trước khi bạn bắt đầu viết mã.

Lợi ích khác là khi bạn nói chuyện với ai đó về mã của bạn. Các mẫu là một loại biệt ngữ khác cô đọng các mô tả dài thành một vài từ. Hãy thử giải thích "sau đó chúng tôi có một người quan sát được thêm bởi nhà máy" mà không đề cập đến các mẫu. Bạn có thể làm điều đó, nhưng phải mất một thời gian dài.

Hầu hết các nhà phát triển sẽ co rúm lại ở bất kỳ mô hình hoặc phương pháp mới nào. Tôi đã làm khi lần đầu tiên tôi nghe về các mẫu thiết kế. Các mẫu thiết kế chỉ là những gì mà tên gợi ý: một thiết kế hoặc mẫu để tạo các lớp và mô hình hóa hành vi và tương tác của chúng theo cách có thể dự đoán được

Hãy nhìn vào những ngôi nhà. Họ có một số điểm tương đồng. Mỗi nhà đều có một phòng khách, nhà bếp, phòng ngủ, phòng tắm, nhà vệ sinh tối thiểu. Không ai sẽ xây dựng một ngôi nhà mà không có phòng tắm, phải không? Căn hộ có một mô hình khác với nhà gỗ. Lâu đài có một mô hình khác nhau hoàn toàn. Quần áo cũng có hoa văn. Cả áo khoác và áo sơ mi chính thức đều có thiết kế cơ bản giống nhau, nhưng chúng có những hành vi khác nhau: bạn sẽ không mặc áo khoác cao bồi cho một cuộc phỏng vấn. Các lớp tương tự và hành động của chúng có thể được nhóm theo hành vi và thiết kế của chúng. Nhìn vào các yếu tố phổ biến trong hành vi của họ cung cấp cho bạn các mẫu thiết kế cho các lớp.

Các mẫu thiết kế theo cách hiểu của tôi chỉ quan trọng nếu khả năng sử dụng lại và mở rộng là mối quan tâm chính. Nếu bạn tạo các ứng dụng nhỏ (dưới 10 lớp), bạn có thể không cần đến chúng. Nhưng các dự án lớn, đặc biệt là những dự án có đội ngũ lớn làm việc với chúng và có chu kỳ bảo trì dài và tính năng bổ sung, chắc chắn sẽ cần các mẫu. Nó thậm chí không phải là một lựa chọn trong các dự án lớn.

Hãy xem một số hướng dẫn trực tuyến về các mẫu. Wikipedia có một bộ bài viết hay. Trang web này cũng tốt: http://sourcemaking.com/ . Nếu bạn là một lập trình viên có kinh nghiệm, bạn sẽ thấy rằng bạn đã bắt gặp một vài mẫu, thậm chí có thể tự thực hiện một cái gì đó tương tự mà không biết nó bằng một tên cụ thể.

Đừng bỏ qua chúng hoàn toàn! Bạn có thể thấy chúng hữu ích trong tương lai nếu không phải bây giờ. Chìa khóa để tiếp cận các Mẫu thiết kế với một suy nghĩ cởi mở là hỏi: "Điều gì sẽ xảy ra nếu tôi không sử dụng các mẫu thiết kế?" Các mô hình không có nghĩa là "phương pháp chữa trị" (mặc dù bạn có thể sử dụng chúng như một phương pháp chữa trị cho một vấn đề); thay vào đó, họ là hiện thân của "phòng bệnh hơn chữa bệnh".

Tất cả đều giống nhau, tôi sẽ thận trọng trước một nỗi ám ảnh với việc triển khai các mẫu ở bất cứ đâu và bất cứ khi nào bạn thấy một cái cớ nhỏ để sử dụng nó. Tôi đã phải đối mặt với vấn đề này trong một dự án mà kiến ​​trúc sư đã bị thuyết phục rằng nếu không có DP thì dự án sẽ là một thảm họa hoàn toàn. Chúng tôi đã có một cuộc họp nhóm nơi các kỹ sư chuyển qua thiết kế và chỉ ra rằng nhiều mẫu mà anh ấy đề xuất sẽ không có tác dụng gì ngoài việc hiển thị "wow nhìn vào các mẫu đẹp". Phải mất rất nhiều thuyết phục và một số thương lượng để giảm số lượng các địa điểm mà các mẫu được sử dụng đến một cơ sở chỉ cần.

Những người trả lời đúng về mặt "lập trình dựa trên mẫu" như thường nghĩ. Tôi có một định nghĩa hơi khác mà tôi thấy phù hợp hơn với những gì tôi đang làm và tôi có xu hướng sử dụng "lập trình dựa trên mẫu" để mô tả một cách tiếp cận plugin hơn là cách tiếp cận lập kế hoạch.

Vì tôi lập trình các plugin jQuery, một plugin đám mây CMS và các plugin thương mại điện tử, "lập trình dựa trên mẫu" theo quan điểm đó có nghĩa là xem xét công nghệ cốt lõi và các trường hợp sử dụng tồn tại và đạt được các liên quan thống kê nhất. Các plugin đặc biệt phải rất dựa trên mô hình để chúng phù hợp với bối cảnh lập trình.

Tuy nhiên, tốt nhất là áp dụng một mẫu SAU KHI bạn thấy các trường hợp sử dụng hợp lệ trên nhiều dự án để nó có giá trị thống kê để sử dụng lại.