Các mẫu thiết kế trong lập trình quan trọng như thế nào?

Tôi là một sinh viên đại học và tôi mới bắt đầu tìm hiểu về các mẫu thiết kế và tôi đang vật lộn để hiểu mục đích của chúng. Tôi đã cố gắng nghiên cứu chúng nhưng tất cả các tài nguyên tôi tìm thấy dường như nói về chúng theo cách hàn lâm, không chuyên nghiệp.

Mục đích của họ là gì và họ có quan trọng để học không?

Các mẫu thiết kế rất tốt để truyền đạt ý định của bạn rất nhanh - mọi người đều biết Nhà máy là gì.

Điều thực sự, thực sự, thực sự tồi tệ phải làm là bắt đầu cố gắng điều chỉnh mã của bạn theo các mẫu hoặc tách riêng các trách nhiệm theo các mẫu hoặc một cái gì đó tương tự. Đó là một điều để nói "Đối tượng này là một Nhà máy" và một điều khác để nói "Đối tượng này chỉ nên là một Nhà máy".

Từ bài viết trên wikipedia về Mẫu thiết kế :

Sự hữu ích của việc nói về các mẫu là có một thuật ngữ chung để thảo luận về các tình huống mà các nhà thiết kế đã thấy nhiều lần.

Trong một thời gian dài chúng tôi đã gặp phải một vấn đề nghiêm trọng trong công nghệ phần mềm: bạn thuê một người mới tham gia vào một dự án và cho dù họ có biết ngôn ngữ lập trình tốt đến đâu, họ cũng phải mất hàng tháng để cập nhật về cách mọi thứ được thực hiện trong bạn dự án trước khi họ có thể có năng suất. Trong kỹ thuật phần cứng, họ đã giải quyết vấn đề này từ rất lâu rồi: họ có một thuật ngữ chung gọi là "sơ đồ nguyên lý". Bạn thuê một kỹ sư phần cứng, cung cấp cho họ sơ đồ của dự án phần cứng của bạn vào buổi sáng, để họ nghiên cứu chúng và đến tối trước khi đến lúc gọi đó là một ngày họ có thể nhặt súng hàn và làm việc hiệu quả. Chúng tôi đã cố gắng đưa ra những cách để trở nên tốt hơn ở đó; tiêu chuẩn hóa các ngôn ngữ lập trình là một cách; thư viện chuẩn (thư viện lớp ngày nay) đã là một cách khác; nhưng một trong những cách quan trọng nhất có lẽ là các mẫu thiết kế. Vì vậy, họ có quan trọng? Bạn đặt cược!

Thực sự có hai lý do khác nhau, đáng kể cho sự tồn tại của các mẫu.

Điều đầu tiên đã được giải thích khá tốt: việc sử dụng các mẫu bôi trơn giao tiếp giữa các nhà phát triển. Nếu cả bạn và tôi đều hiểu rằng khi tôi nói 'Người quan sát' tôi đang nói về một cấu trúc mã rất cụ thể, thì tôi có thể mô tả rất nhanh cách một bit mã sử dụng mẫu đó hoạt động. Thay thế là để mô tả đầy đủ các giải pháp, đó là tốn thời gian và dễ bị lỗi. ("Chà, tôi đã tạo lớp ảo thuần này mô tả và giao diện cho các đối tượng người tiêu dùng, sau đó tôi đã tạo một lớp duy trì một danh sách những người tiêu dùng đang hoạt động, ...")

Lợi ích thứ hai của các mẫu là chúng là các dạng giải pháp sẵn có cho các dạng bài toán phổ biến. Nếu bạn biết các mẫu của mình và, ví dụ, bạn gặp phải một vấn đề trong đó bạn cần tìm một cách tốt để lấy thông tin từ (có thể nhiều) đối tượng sản xuất cho nhiều đối tượng người tiêu dùng, mà không đưa ra sự ghép nối không cần thiết giữa các lớp, bạn sẽ nhận ra "điều này là một công việc cho một Người quan sát! " và bạn sẽ biết ngay cách giải quyết vấn đề của mình.

Những lợi ích này cũng thực sự củng cố lẫn nhau. Chúng cho phép bạn giải quyết nhanh chóng các loại vấn đề phổ biến nhất định và sau đó khi bạn hoàn thành, bạn có thể nhanh chóng truyền đạt cách bạn giải quyết vấn đề.

Tương phản điều này với một thế giới nơi các mẫu "không tồn tại". Bạn gặp phải một trong những loại vấn đề này, thường không phải là vấn đề thiết kế tầm thường và bạn dành một chút thời gian để đưa ra một giải pháp tốt (tình cờ, rất có thể sẽ trông rất giống mẫu phù hợp). Sau đó, đồng nghiệp của bạn đến và muốn biết bạn đã giải quyết nó như thế nào và bạn dành một giờ để thảo luận về cách thức và lý do tại sao.

Tất cả điều này được liên kết với một cảnh báo có vẻ khá rõ ràng: đừng cố ép các vấn đề thành các mô hình không phù hợp. Nếu mô hình không phù hợp với vấn đề, thì giải pháp cuối cùng sẽ bị sai lệch và bạn sẽ mất lợi ích giảm nỗ lực của các mẫu. Ngoài ra, vì công việc của bạn sẽ không còn phù hợp với sự hiểu biết của đồng nghiệp về ý nghĩa của mẫu, bạn sẽ mất chi phí lợi ích giao tiếp. Trên thực tế, bạn có thể sẽ tăng chi phí liên lạc vượt quá chi phí phi mẫu, bởi vì việc sử dụng sai mẫu sẽ khiến đồng nghiệp của bạn hiểu sai về giải pháp, tệ hơn là không hiểu gì cả.

Các mẫu là về việc tái sử dụng các ý tưởng và khái niệm và về việc thiết lập một nền tảng chung / nhất quán để giao tiếp.

Tất cả chúng ta đều đồng ý (!) Rằng trong lý thuyết tái sử dụng mã là một điều tốt - nhưng hóa ra nó khó hơn chúng ta muốn làm một cách thực tế (trong một số khía cạnh, điều này đang thay đổi, nhưng nó sẽ luôn là một thách thức ). Nhưng trong thực tế, rất nhiều thứ chúng ta muốn sử dụng lại là một cách làm, để sử dụng một loại khuôn mẫu để xây dựng giải pháp cho một vấn đề cụ thể - đó là các Mẫu. Vì vậy, bạn đi đến một trường hợp mà bạn nói rằng một cách tiếp cận tốt để giải quyết vấn đề X là sử dụng Mẫu Y và chúng tôi biết rằng các yếu tố của mẫu Y là a, b và c và chúng tôi đi. Bởi vì các mô hình được hiểu rộng rãi, bạn không cần phải giải thích sâu sắc, đó là lợi ích truyền thông.

Điều thú vị về các mẫu là các ngôn ngữ và khung đang phát triển để cung cấp hỗ trợ tốt hơn cho các mẫu phổ biến với hiệu ứng mạng mà chúng ta ngày càng sử dụng mã tốt hơn (nhiều viên gạch lego tốt hơn!) Bởi vì cách chúng ta xây dựng các ứng dụng (bằng cách triển khai các mẫu ) tạo điều kiện tái sử dụng.

Các mẫu thiết kế chỉ là những viên gạch được biết đến mà bất kỳ giải pháp phần mềm nào cũng được xây dựng dựa trên. Chúng rất quan trọng vì những lý do sau:

1. Họ là bất khả tri ngôn ngữ. Khi bạn biết mẫu thiết kế nào phù hợp với vấn đề / kiến ​​trúc / tác vụ nhất định, bạn có thể triển khai nó trong bất kỳ ngôn ngữ đa mô hình nào - hãy là C #, Java hoặc Python - trong hầu hết các trường hợp đều giống nhau, bạn chỉ cần có để thích ứng cú pháp. Điều này có nghĩa là bạn có thể chuyển trải nghiệm của mình từ lập trình bằng một ngôn ngữ sang các ngôn ngữ khác miễn là bạn ở trong cùng một miền vấn đề (và thậm chí có thể trên các miền).

2. Mặc dù thực tế là các mẫu thiết kế có ràng buộc với mô hình lập trình , có nghĩa là các mẫu thiết kế cho lập trình hướng đối tượng (những mẫu nổi tiếng nhất, còn được gọi là mẫu "Gang of Four" ). Các mẫu cho phép bạn hiểu mô hình nào là tốt nhất và giúp bạn vượt ra ngoài cú pháp.Ví dụ, tôi đã thấy rất nhiều triển khai trong C # và Java, nơi mọi người chỉ lập trình theo cách họ đã làm trong Basic hoặc Fortran - họ có một tâm trí bắt buộc hoàn hảo để giải quyết vấn đề và họ sử dụng OOP chỉ để đưa ra giải pháp này - không cần kế thừa , không đa hình, tất cả các phương thức đều công khai, vv Các mẫu thiết kế giúp bạn nhìn phía sau các khái niệm này và xem cách chúng hoạt động trong cuộc sống thực. Áp dụng tương tự cho mẫu thiết kế trong các mô hình khác, như lập trình chức năng.

3. Các mẫu nói chung là một cách tiện dụng để thể hiện ý tưởng và đến với Khoa học máy tính từ kiến ​​trúc. Khi bạn hiểu ý tưởng đằng sau một "mẫu" nhất định, bạn có thể dễ dàng nhận ra mẫu này trong một số vấn đề khác và giải quyết nó bằng mẫu này (có thể sửa đổi một chút để giải quyết vấn đề của bạn tốt hơn). Có rất nhiều mẫu khác nhau: trong Tích hợp phần mềm doanh nghiệp , trong Kiểm tra mã nguồn, v.v. Chỉ cần tìm các mẫu trong sách cho Khoa học máy tính.

4. Ngoài việc có được các thực tiễn tốt bằng cách học các mẫu, bạn có thể dễ dàng học cách tránh các lỗi ngớ ngẩn trong mã của mình bằng cách nghiên cứu các mẫu chống . Có rất nhiều cuốn sách đề cập đến những sai lầm phổ biến trong các lĩnh vực khác nhau dưới hình thức chống mẫu rất thú vị và mang tính giáo dục đồng thời. Nhân tiện, tôi thích tên của những mẫu chống này!

Bạn có thể nghĩ về một mô hình như một cách đã được chứng minh để giải quyết vấn đề mà bạn và các nhà phát triển khác hiểu. Ví dụ, vấn đề là tạo một danh sách dữ liệu được sắp xếp, sau đó bạn có thể chọn sử dụng danh sách được liên kết hoặc đưa dữ liệu vào một vectơ và sắp xếp. Bạn có thể hiểu cả hai tùy chọn này bởi vì bạn có thể đã biết mẫu danh sách được liên kết hoặc mẫu vectơ tải và sắp xếp. Bạn có thể biết những ưu và nhược điểm của từng loại và không cần phải xem việc triển khai để hiểu những gì đang diễn ra.

Tôi nghĩ bạn là người khởi đầu cho lập trình, tôi không khuyên bạn nên học mẫu thiết kế sớm. Học và hiểu mẫu thiết kế cần dựa trên kinh nghiệm phát triển phần mềm. Bạn nên thực hành nhiều hơn để viết mã và tìm ra kiểu mã nào là xấu và sau đó tìm hiểu mẫu thiết kế để cải thiện thiết kế.

Sự hữu ích của một mẫu thiết kế phụ thuộc vào ngôn ngữ bạn chọn. Ngôn ngữ càng mạnh mẽ bạn chọn càng ít bạn sẽ cần phải hiểu và thực hiện các thiết kế patters. Một mẫu thiết kế có thể là một dấu hiệu cho thấy ngôn ngữ của bạn hút thiếu một tính năng built-in.

Joe Gregorio đã có một cuộc nói chuyện tuyệt vời về việc thiếu các mẫu thiết kế trong Python

Các mẫu thiết kế là giải pháp cho các vấn đề thường gặp trong phát triển phần mềm. Luôn có nhiều hơn một giải pháp cho một số vấn đề và các mẫu thiết kế giúp bạn quyết định giải pháp nào là tốt nhất bằng cách cung cấp cho bạn một bộ giải pháp tốt cho những vấn đề phổ biến này.