system: You are a trustworthy AI assistant. Your task is to answer the question honestly and not fabricate information.

user: Cho tôi thông tin về Dạng thức thiết kế từ wiki nha

assistant:  
Trong kỹ nghệ phần mềm, một dạng thức thiết kế là một giải trình lập lại được cho một dạng vấn đề thường xảy ra trong ngành thiết kế phần mềm. Một dạng thức thiết kế không phải là một thiết kế hoàn tất có thể được chuyển dạng trực tiếp thành mã; nó thực ra là một sự mô tả hay một tiêu bản nhằm chỉ ra cách giải quyết vấn đề mà có thể sử dụng được trong nhiều tình huống khác nhau. Các dạng thức thiết kế hướng đối tượng thường chỉ ra các quan hệ và các mối tương tác giữa các lớp, mà không cần đặc tả rõ các lớp ứng dụng cuối cùng hay các đối tượng có tham gia. Các thuật toán thì không được xem là các dạng thức thiết kế, vì chúng giải quyết các vấn đề tính toán hơn là vấn đề thiết kế.
Lịch sử.
Các dạng thức nguyên thủy như là một nguyên lý thiết kế từ ý kiến của Christopher Alexander. Trong năm 1987, Kent Beck và Ward Cunningham đã bắt đầu thử nghiệm với các ý tưởng về việc ứng dụng các dạng thức vào lập trình và trình bày các kết quả của họ tại hội nghị OOPSLA năm đó. Trong những năm kế tiếp Beck, Cunningham và nhiều người khác đã kế tục công việc này.
Các dạng thức thiết kế trở nên phổ biến trong khoa học máy tính sau khi cuốn "Design Patterns: Elements of Reusable Object-Oriented Software" được phát hành trong năm 1944 (Gamma et al). Cùng năm này, hội nghị Pattern Languages of Programs (tên này có nghĩa là "Các Ngôn ngữ Dạng thức của các Chương trình") đã được tổ chức. Năm sau đó, Portland Pattern Repository (tức là "Trung tâm Dữ liệu Dạng thức Portland") đã được hình thành nhằm hồ sơ hóa các dạng thức thiết kế. Nội hàm của thuật ngữ vẫn còn là một việc bàn cãi cho đến thập niên sau đó.
Phân lớp.
Các dạng thức thiết kế có thể được phân lớp dựa trên nhiều tiêu chỉ, điểm chung nhất của chúng là vấn đề cơ sở bên trong mà chúng giải quyết. Theo tiêu chỉ này, các dạng thức thiết kế có thể được phân thành nhiều lớp, một số trong các lớp đó là:
Hồ sơ.
Hồ sơ cho một dạng thức thiết kế nên chứa đủ thông tin về vấn đề mà dạng thức đó muốn giải quyết, ngữ cảnh mà nó được sử dụng và lời giải đề nghị. Mặc dù vậy, các tác giả sử dụng cách trình bày riêng của họ để viết các dạng thức thiết kế, và các trình bày này thường rập theo những bộ phận trọng yếu. Các tác giả thường bao gồm thêm vào đó các đề mục để cung cấp thêm thông tin, và sắp xếp các bộ phận trọng yếu này vào trong các tiêu chỉ khác nhau, có thể là với các tên khác nhau.
Một định dạng chung được sử dụng bởi "Gang of Four". Nó bao gồm các tiêu chỉ sau:
Phê bình.
Nguyên lý của các dạng thức thiết kế đã bị phê bình bởi một số lãnh vực của khoa học máy tính.
Nhắm tới sai vấn đề.
Điều cần thiết cho các dạng thức kết quả từ việc sử dụng các ngôn ngữ máy tính hay các kĩ thuật thiếu khả năng trườu tượng. Bằng ý tưởng "nhân tử hóa", một nguyên lý không nên được sao chép, mà tốt hơn nên là tham chiếu. Nhưng nếu vật nào đó được tham chiếu thay vì sao chép thì sẽ không có "dạng thức" để đánh nhãn và phân loại. (Paul Graham viết trong bản luận văn "Revenge of the Nerds" (tức là "sự trả thù của những kẻ kỹ tài"):
This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough— often that I'm generating by hand the expansions of some macro that I need to write.
Peter Norvig cho một bàn cãi tương tự cho rằng 16 trong 23 dạng thức trong cuốn "Design Patterns" ("Các Dạng thức Thiết kế") (mà chủ yếu tập trung trong C++) là đơn giản và loại bỏ được (qua việc hỗ trợ ngôn ngữ trực tiếp) trong Lisp hay trong Dylan.
Các bàn cãi xa hơn được tìm thấy trong bài Portland Pattern Repository.
Thiếu các nền tảng chuẩn.
Sự nghiên cứu về các dạng thức thiết kế đã trởo nên quá "đặc ứng" ("ad hoc"), và một số người cho rằng nguyên lý này cần được chuẩn hóa nhiều hơn. Tại OOPSLA 1999, Gang of Four với sự cồng tác đã đồng thanh chống lại màn xử án, trong đó, họ là những người trách nhiệm chính với các tội phạm chống lại khoa học máy tính. Họ đã bị kết án bởi 2/3 của bồi thẩm đoàn. Một số người cảm thấy rằng sự ảnh hưởng từ lý thuyết tương đối có thể giúp họ tốt hơn là xác định, nghiên cứu, hay chuẩn hoá các dạng thức.
Dẫn tới các lời giải không hiệu quả.
Ý tưởng của một dạng thức thiết kế là một nỗ lực để chuẩn hóa cái mà đã được chấp nhận là các thực nghiệm tốt nhất. Trong nguyên tắc, điều này có thể dường như có ích, nhưng trong thực tế, nó thường dẫn tới kết quả trong sự trùng lặp mã một cách không cần thiết. Hầu như luôn luôn là có một lời giải hiệu quả để sử dụng cho sự thiết lập có tính nhân tố tốt đẹp hơn là một dạng thức thiết kế "chỉ vừa đủ tốt".
Nguyên lý cũ và hiển nhiên.
Từ khi bắt đầu, các nguyên lý khoa học máy tính đã được đặt tên (như là truy ngược, "backtrackting", hay là cây AVL) và được hồ sơ hoá. Các dạng thức như là được giới thiệu trong cuốn "Design Patterns" được liên hệ đến các hướng dẫn và các nguyên lý liên hệ . Trong ngành thiết kế cũng đã có các ngành dùng cho tái dụng các cấu trúc thiết kế ( ).