Là một sinh viên CNTT, gần đây tôi đã được một trong những giáo viên của chúng tôi cung cấp một số tổng quan về các mẫu thiết kế. Tôi hiểu những gì họ làm, nhưng một số khía cạnh vẫn tiếp tục làm phiền tôi.

Chúng có thực sự được sử dụng bởi đa số các lập trình viên?

Nói về kinh nghiệm, tôi đã gặp một số rắc rối khi lập trình, những điều tôi không thể giải quyết trong một thời gian, nhưng Google và một số giờ nghiên cứu đã giải quyết vấn đề của tôi. Nếu ở đâu đó trên web tôi tìm cách giải quyết vấn đề của mình, đây có phải là mẫu thiết kế không? Tôi đang sử dụng nó?

Và ngoài ra, bạn (lập trình viên) có thấy mình đang tìm kiếm các mẫu (nhân tiện tôi phải tìm ở đâu không?) Khi bạn bắt đầu phát triển? Nếu vậy, đây chắc chắn là một thói quen mà tôi phải bắt đầu nắm lấy.

CẬP NHẬT: Tôi nghĩ khi tôi hỏi liệu các lập trình viên có sử dụng chúng không, tôi hỏi khi bạn gặp vấn đề cần giải quyết, bạn nghĩ "Ồ, tôi nên sử dụng mô hình đó".

Khi tôi là một lập trình viên mới làm quen, tôi yêu thích các mẫu thiết kế. Tôi không chỉ sử dụng các mẫu thiết kế. Tôi gây ra cho họ. Bất cứ nơi nào và bất cứ khi nào tôi có thể. Tôi tàn nhẫn. Aha! Mẫu quan sát! Lấy nó! Sử dụng một người nghe! Ủy quyền! Tóm tắt! Tại sao sử dụng một lớp trừu tượng khi năm sẽ làm gì? Tôi đã nói chuyện với nhiều lập trình viên có kinh nghiệm và thấy rằng mọi người đọc Sách GoF đều trải qua giai đoạn này.

Lập trình viên Novice không sử dụng các mẫu thiết kế. Họ lạm dụng các mẫu thiết kế.

Gần đây, tôi thấy rằng việc giữ các nguyên tắc như Nguyên tắc Trách nhiệm duy nhất trong đầu và viết các bài kiểm tra trước, giúp các mô hình xuất hiện theo cách thực tế hơn. Khi tôi nhận ra các mẫu, tôi có thể tiếp tục phát triển chúng dễ dàng hơn. Tôi nhận ra chúng, nhưng tôi không còn cố ép chúng vào mã. Nếu một mẫu Khách truy cập xuất hiện thì có lẽ là do tôi đã tái cấu trúc sao chép, chứ không phải vì tôi đã nghĩ trước về sự tương đồng của việc kết xuất cây so với việc thêm các giá trị của nó.

Lập trình viên có kinh nghiệm không sử dụng các mẫu thiết kế. Các mẫu thiết kế sử dụng chúng.

Cho dù một người có nhận ra chúng hay không, hầu hết các lập trình viên đều sử dụng các mẫu.

Tuy nhiên, vào ngày làm việc hàng ngày, người ta không bắt đầu lập trình với một mẫu trong tâm trí - người ta nhận ra rằng một mẫu đã xuất hiện trong mã và sau đó đặt tên cho nó.

Một số mẫu phổ biến được tích hợp vào một số ngôn ngữ - ví dụ: mẫu lặp trong tích hợp vào C # với foreachtừ khóa.

Đôi khi bạn đã biết mẫu bạn sẽ sử dụng như một giải pháp phổ biến cho vấn đề hiện tại (giả sử mẫu lưu trữ - bạn đã biết bạn muốn thể hiện dữ liệu của mình dưới dạng bộ sưu tập trong bộ nhớ).

Như ngụ ý của câu trả lời pdr được liên kết: các mẫu thiết kế là tên được đặt cho những thứ mọi người đang làm dù sao , nhằm giúp mọi người dễ dàng thảo luận về những điều đó hơn.

Nói chung, đáng để học hỏi họ khi bắt đầu, bởi vì họ cung cấp cho bạn cái nhìn sâu sắc về các giải pháp mà mọi người đã tìm thấy để làm việc, vì vậy bạn có thể xây dựng dựa trên nhiều năm kinh nghiệm và thử nghiệm & lỗi.

Thảo luận về việc thúc đẩy các vấn đề bao gồm các mẫu có thể giúp bạn hiểu rõ hơn về các cách tốt để tấn công vấn đề của bạn ngay từ đầu, nhưng trừ khi kiến ​​thức về mẫu của bạn cho phép bạn nhận ra có một giải pháp nổi tiếng hiện có, bạn vẫn cần tập trung vào giải quyết Vấn đề đầu tiên.

Nếu hóa ra là sử dụng một hoặc nhiều mẫu hiện có thì thật tuyệt vời, bạn có các tên được tạo sẵn sẽ giúp người khác dễ hiểu mã của bạn hơn.

Nói chung là không. Có những lúc các mẫu xuất hiện từ mã của tôi, nhưng nói chung, tôi không tìm kiếm chúng và tôi chắc chắn không nói "Ồ, Mẫu cầu sẽ giải quyết vấn đề của tôi!".

Vấn đề là như thế này. Hầu hết các mẫu bị lạm dụng và sử dụng sai mà không bao giờ mọi người xem xét nếu chúng có thiết kế tốt. Các mẫu không phải là nguyên tử. Mã không bao gồm X hoán vị của các mẫu. Chưa kể rằng không phải tất cả các mẫu thực sự là ý tưởng tốt, hoặc một số ngôn ngữ có các giải pháp ở cấp độ ngôn ngữ vượt trội hơn rất nhiều so với một số mẫu.

vâng, hầu hết các lập trình viên mà tôi từng gặp đều sử dụng mô hình phổ biến nhất đó là, Big Ball of Mud . Họ thường bắt đầu với các kiến ​​trúc được thiết kế tốt, nhưng thường kết thúc ở đây, đặc biệt nếu họ bắt đầu nghĩ rằng "chúng ta phải sử dụng các mẫu thiết kế" ở khắp mọi nơi và tái cấu trúc không thương tiếc.

bạn có sử dụng chúng không?

Vâng, lập trình viên giàu kinh nghiệm chắc chắn làm. Bây giờ bạn có thể tránh sử dụng hầu hết các mẫu thiết kế (không bao gồm các công cụ đơn lẻ); nhưng bạn càng lập trình và xây dựng các hệ thống phức tạp hơn, bạn sẽ càng cảm thấy cần phải sử dụng các mẫu thiết kế. Nếu bạn vẫn tránh nó, bạn sẽ bắt đầu cảm thấy đau khi phải mở rộng hệ thống và thay đổi nó theo yêu cầu mới.

Nếu ở đâu đó trên web tôi tìm cách giải quyết vấn đề của mình, đây có phải là mẫu thiết kế không?

Không cần thiết. Một mẫu thiết kế đề cập đến một cách cụ thể để thiết kế các lớp, hành vi và tương tác của chúng để đạt được một mục tiêu cụ thể (hoặc tránh một vấn đề cụ thể). Những gì bạn có thể gặp phải có thể không thực sự là một vấn đề thiết kế mà là một chuỗi các bước cụ thể để lập trình một API nhất định. Ví dụ: có một trình tự nhất định để thiết lập kết nối ổ cắm. Làm điều đó sai và ổ cắm của bạn sẽ không giao tiếp. Chuỗi các bước đó không tạo thành một mô hình.

bạn (lập trình viên) có thấy mình đang tìm kiếm các mẫu không

Đúng. Các mẫu thiết kế thể hiện tiên đề "phòng bệnh hơn chữa bệnh". Nếu bạn có thể phát hiện ra một vấn đề thiết kế cụ thể sắp tới trước đó, bạn có thể ngăn chặn các thiết kế lại lớn để điều chỉnh các thay đổi sau này. Vì vậy, nó trả tiền để biết các mẫu thiết kế trước và tìm kiếm những nơi bạn cần sử dụng chúng khi bạn xây dựng ứng dụng của mình.

Tôi phải tìm btw ở đâu?

Vì bạn là sinh viên nên có lẽ bạn chưa thấy những vấn đề điển hình truyền cảm hứng cho các mẫu thiết kế. Tôi thực sự khuyên bạn nên nhìn vào các mẫu thiết kế đầu tiên . Đầu tiên họ trình bày một vấn đề thiết kế và sau đó cho thấy một mẫu cụ thể có thể giải quyết / tránh nó như thế nào.

Mẫu thiết kế không được dạy khi tôi ở trường. Và, trong phần lớn sự nghiệp lập trình của mình, tôi đã làm việc với mã kế thừa, không hướng đối tượng. Trong những năm gần đây, tôi đã cố gắng học chúng bởi vì chúng nghe có vẻ như là một ý tưởng tốt. Tuy nhiên, tôi phải thú nhận rằng mỗi lần tôi nhặt một cuốn sách hoặc cố gắng đọc một hướng dẫn về chủ đề này, mắt tôi đều trừng trừng và tôi hoàn toàn không học được gì thực tế về chúng.

Tôi không thể tin rằng tôi chỉ thừa nhận điều đó ở nơi công cộng. Tôi nghĩ có lẽ tôi đã mất bất kỳ tín dụng đam mê nào mà tôi có thể đã thiết lập trong nhiều năm qua.

Đừng tìm xu hướng

Bất kỳ giải pháp lập trình tiêu chuẩn nào cho một vấn đề nhất định đều có thể được coi là một mẫu thiết kế, không quan trọng mức độ phổ biến của chúng, hoặc nếu các lập trình viên khác sử dụng chúng hay không.

Bạn có thể đã sử dụng một mẫu thiết kế chưa được phát minh / chỉ định.

Đừng thử sử dụng chúng, hãy thử suy nghĩ theo thuật ngữ của họ

Vấn đề với các mẫu thiết kế là đôi khi các lập trình viên muốn điều chỉnh các vấn đề của họ vào chúng khi nó là cách khác.

Hãy nhớ quy ước thiết kế của các mẫu thiết kế có một vấn đề điển hình cần giải quyết, thậm chí bạn có thể kết hợp các mẫu thiết kế để giải quyết các vấn đề lớn hơn khác. Đây là loại điển hình trong Kiến trúc hướng dịch vụ, chỉ cần xem một số mẫu của SOA .

Tìm chúng trong tự nhiên

Có rất nhiều dự án nguồn mở nơi bạn sẽ tìm thấy các mẫu thiết kế được áp dụng. Một ví dụ xuất hiện trong tâm trí là Joomla: bạn sẽ tìm thấy những người độc thân , quan sát viên . Các thư viện GUI sẽ có mẫu trang trí , mẫu lệnh được triển khai và thậm chí có thể có trọng lượng .

Có các mẫu khác như mẫu dữ liệu, ví dụ: Dự án Doctrine đã sử dụng, mẫu bản ghi hoạt động (1.x), mẫu trình quản lý thực thể (2.x), đơn vị công việc , kho lưu trữ , đối tượng truy vấn , ánh xạ siêu dữ liệu , dữ liệu lập bản đồ và các loại tổng quát khác như mẫu chiến lược và mẫu trang trí .

Có rất nhiều giải pháp thú vị để lựa chọn. Xem Mô hình kiến ​​trúc doanh nghiệp của Martin Fowler , cũng có các mẫu mô hình dữ liệu .

Chỉ cần học chúng khi thời gian đến

Tìm hiểu họ, biết họ, ám ảnh họ và khi đến lúc bạn sẽ biết cách giải quyết vấn đề lập trình x, bạn sẽ trở thành một lập trình viên giỏi hơn vào thời điểm đó.

Trở thành một kiến ​​trúc sư

Tôi muốn nói rằng việc có thể suy nghĩ theo thuật ngữ mẫu để giải quyết vấn đề, thực sự biến bạn thành một kiến ​​trúc sư phần mềm . Ngay cả khi bạn không muốn trở thành một kiến ​​trúc sư phần mềm, các giải pháp của bạn sẽ có chất lượng kỹ thuật cao hơn, sạch sẽ hơn và có khả năng mở rộng tốt hơn theo các điều khoản của Thiết kế theo mặc định.

Tôi đã lập trình khoảng 7 năm trong C ++ và học các mẫu khoảng 2 năm trước. Hầu hết các mẫu có thể có một số ứng dụng, nhưng trong cách sử dụng của tôi, một số tốt hơn các ứng dụng khác. Bạn phải nghĩ tại sao bạn đang sử dụng chúng.

Mẫu lặp thực sự đã làm cho mã của tôi trở nên khó hiểu hơn và đã thêm sự phức tạp không cần thiết. Tôi có thể có được khả năng bảo trì tương tự bằng cách sử dụng typedefs cho các loại vectơ STL. Và bất kỳ thay đổi nào tôi thực hiện đối với lớp được lặp đi lặp lại, tôi cũng phải thực hiện với lớp lặp.

Phương pháp nhà máy, tuy nhiên, cực kỳ hữu ích, dựa trên tính đa hình mà nó cung cấp. Tôi quên người đã nói điều đó, nhưng tuyên bố "tái sử dụng có nghĩa là mã cũ có thể sử dụng mã mới", hoàn toàn đúng với mẫu nhà máy.

Tôi đã sử dụng mẫu phương thức mẫu trong nhiều năm mà không hề biết đó là "mẫu thiết kế".

Mẫu Observer đã hữu ích trong một số trường hợp, đôi khi thì không. Đôi khi bạn phải dự đoán độ phức tạp để xác định xem độ phức tạp trên không của mẫu Observer có đáng không. Chúng tôi có một chương trình sử dụng khoảng 10 người đăng ký và có thể có nhiều hơn nữa, vì vậy mẫu người quan sát / người đăng ký rất hữu ích. Một chương trình khác, tuy nhiên, có hai màn hình GUI. Tôi đã triển khai mô hình quan sát viên cho chương trình này và nó hầu như không cần thiết, đơn giản vì nó tăng thêm độ phức tạp và tôi không lường trước việc thêm nhiều màn hình nữa.

Tôi nghĩ rằng những người nói luôn luôn sử dụng các mẫu cho rằng chương trình của bạn sẽ vô cùng phức tạp, nhưng giống như với mọi thứ, có một điểm hòa vốn về độ phức tạp.

Thêm vào Lunivore. Id muốn trích dẫn điều này từ cuốn sách đầu tiên

        ## **Three steps to great software** ##     

• Đảm bảo phần mềm làm những gì khách hàng muốn
• Áp dụng các nguyên tắc hướng đối tượng tốt
• Phấn đấu cho một thiết kế có thể tái sử dụng

Đó là trong giai đoạn thứ ba, sau khi hệ thống của bạn hoạt động theo đúng nghĩa của nó. Tôi đã đến lúc áp dụng các mẫu để làm cho phần mềm của bạn sẵn sàng trong nhiều năm tới.

Chúng có thực sự được sử dụng bởi đa số các lập trình viên?

Tôi đoán là có. Trong ADO.Net có một lớp DataAd CHƯƠNG để đưa ra một ví dụ đơn giản mặc dù tùy thuộc vào khu vực bạn muốn chuyên môn hóa các mẫu có thể khác nhau.

Nói về kinh nghiệm, tôi đã gặp một số rắc rối khi lập trình, những điều tôi không thể giải quyết trong một thời gian, nhưng google và một số giờ nghiên cứu đã giải quyết vấn đề của tôi. Nếu ở đâu đó trên web tôi tìm cách giải quyết vấn đề của mình, đây có phải là mẫu thiết kế không? Tôi đang sử dụng nó?

Không, đó không phải là một mẫu thiết kế theo ý tôi. Một mẫu thiết kế có xu hướng có một số sắp xếp các lớp và phương thức xác định công thức của mẫu.

Tôi muốn nghĩ về những gì bạn đã làm ở đó như là một thực tế phổ biến. Cẩn thận với sao chép và dán mã mặc dù.

Và ngoài ra, bạn (lập trình viên) có thấy mình đang tìm kiếm các mẫu (tôi phải tìm btw ở đâu không?) Khi bạn bắt đầu phát triển? Nếu vậy, đây chắc chắn là một thói quen mà tôi phải bắt đầu nắm lấy.

Thỉnh thoảng khi tôi thấy cùng một mã lặp đi lặp lại, tôi có thể tìm cách tái cấu trúc mã thành một mẫu hoặc nếu tôi nhớ một giải pháp cho một vấn đề tương tự liên quan đến một mẫu tôi sẽ lấy nó ra và sử dụng nó. Các mẫu thiết kế đầu tiên có nhiều hơn một vài mẫu trong khi Tái cấu trúc sẽ là một gợi ý cho các hoạt động mã hóa có thể khiến người ta tìm thấy các mẫu khác nhau. Nếu bạn muốn một điểm khởi đầu khả dĩ khác, hãy xem Mô hình và Thực tiễn của Microsoft .

Học mô hình không chỉ là học một cái gì đó. Bạn học những gì bạn có thể làm với các ngôn ngữ lập trình. Bản thân tôi đã học được rất nhiều về lập trình hướng đối tượng chỉ bằng cách học cách một mẫu hoạt động ( mẫu tổng hợp trong trường hợp này).

Như Oded đã đề cập, hầu hết các lập trình viên đôi khi sử dụng chúng mà không hề nhận ra. Vẻ đẹp của các mẫu là bạn có thể xử lý các vấn đề cụ thể với một mẫu được xác định trước để bạn không phải suy nghĩ nhiều về những thứ kiến ​​trúc.

Bạn sẽ học các mẫu khi bạn bắt đầu làm việc với các dự án hiện có. Có rất nhiều mô hình ngoài kia để bạn học hỏi, và không đáng để dành thời gian để làm chủ tất cả chúng vì nó phụ thuộc vào dự án bạn đang làm. Bất cứ khi nào bạn gặp phải một, hãy tìm hiểu về nó để xem nó được sử dụng như thế nào.