mẫu thiết kế

1.1 Giới thiệu về mẫu

Như đã đề cập trước đó, một lập trình viên bắt đầu làm việc trên một chương trình bằng cách thiết kế mô hình của nó: biên soạn một danh sách các thực thể mà chương trình sẽ hoạt động. Và càng nhiều thực thể trong chương trình, chương trình càng phức tạp.

Do đó, để giảm độ phức tạp của chương trình, họ cố gắng chuẩn hóa các tương tác của các đối tượng. Và đây là lúc các mẫu thiết kế hay design pattern giúp ích rất nhiều cho lập trình viên . Từ mẫu thiết kế tiếng Anh .

Quan trọng! Trong tiếng Nga, từ thiết kế thường có nghĩa là thiết kế đồ họa, trong tiếng Anh thì không phải như vậy. Từ thiết kế trong tiếng Anh gần nghĩa với từ “thiết kế” và/hoặc “thiết bị”. Ví dụ, thiết kế của một động cơ không phải là hình thức bên ngoài mà là cấu trúc bên trong của nó.

Do đó, một mẫu thiết kế chính xác là một mẫu/mẫu thiết kế. Tôi khuyên bạn nên ngừng sử dụng từ thiết kế theo nghĩa “xuất hiện” hoàn toàn. Bạn là Kỹ sư phần mềm tương lai và đối với bạn, thiết kế chính xác là thiết kế.

Vậy mẫu thiết kế này là gì? Trước hết, một mẫu thiết kế là một giải pháp tiêu chuẩn cho một vấn đề tiêu chuẩn . Một giải pháp tốt, hiệu quả và đã được thử nghiệm theo thời gian.

Giả sử bạn được yêu cầu thiết kế một chiếc xe đạp, bạn có thể chế tạo nó hai bánh, ba hoặc thậm chí là năm bánh. Nhân tiện, vào buổi bình minh của thiết kế, nó đã như vậy. Nhưng cách tiếp cận được thử nghiệm theo thời gian là hai bánh. Nhưng cách tiếp cận rõ ràng hiện tại đã trải qua đau đớn và sai lầm:

Thông thường, một mẫu không phải là một giải pháp hoàn chỉnh có thể được chuyển đổi trực tiếp thành mã, nó chỉ là một ví dụ về một giải pháp tốt cho một vấn đề có thể được sử dụng trong các tình huống khác nhau.

Các mẫu hướng đối tượng hiển thị các mối quan hệ và tương tác giữa các lớp hoặc đối tượng mà không chỉ định lớp cuối cùng hoặc đối tượng ứng dụng nào sẽ được sử dụng.

1.2 Lịch sử của các mẫu thiết kế

Quay trở lại những năm 70, các lập trình viên phải đối mặt với nhu cầu phát triển các chương trình lớn phải được thực hiện bởi toàn bộ nhóm phát triển. Nhiều phương pháp tổ chức công việc đã được thử, nhưng ngành xây dựng ảnh hưởng nhiều nhất đến sự phát triển.

Để tổ chức công việc của một nhóm lớn người, các phương pháp và cách tiếp cận từ ngành xây dựng đã được sử dụng. Nhân tiện, chính từ đó, các thuật ngữ như lắp ráp (xây dựng), Nhà phát triển phần mềm (xây dựng) và khái niệm kiến ​​​​trúc đã đi vào lập trình.

Và như bạn có thể đoán ra, ý tưởng mẫu thiết kế cũng được lấy từ ngành xây dựng. Khái niệm về các mẫu được mô tả lần đầu tiên bởi Christopher Alexander trong Ngôn ngữ mẫu. Các thành phố. Xây dựng. Sự thi công". Trong cuốn sách này, một ngôn ngữ đặc biệt, các mẫu, đã được sử dụng để mô tả các quá trình thiết kế thành phố.

Các mô hình trong xây dựng mô tả các quyết định điển hình đã được thử nghiệm qua thời gian: cửa sổ nên cao bao nhiêu, nên có bao nhiêu tầng trong tòa nhà, nên phân bổ bao nhiêu diện tích trong tiểu khu cho cây cối và thảm cỏ.

Do đó, không có gì ngạc nhiên khi vào năm 1994, cuốn sách “Kỹ thuật thiết kế hướng đối tượng. Design Patterns”, bao gồm 23 mẫu giải quyết các vấn đề khác nhau của thiết kế hướng đối tượng.

Cuốn sách được viết bởi 4 tác giả: Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides. Tên sách dài quá không ai nhớ nổi. Do đó, chẳng mấy chốc mọi người bắt đầu gọi nó là “cuốn sách của nhóm bốn người”, tức là “cuốn sách của nhóm bốn người” , và sau đó là “cuốn sách của GoF”.

Và kể từ đó, các mẫu thiết kế khác đã được phát hiện. Cách tiếp cận “mẫu” đã trở nên phổ biến trong tất cả các lĩnh vực lập trình, vì vậy bây giờ bạn có thể tìm thấy tất cả các loại mẫu bên ngoài thiết kế đối tượng.

Quan trọng! Các mẫu không phải là một số giải pháp siêu nguyên bản, mà ngược lại, các giải pháp điển hình thường gặp cho cùng một vấn đề. Giải pháp đã được chứng minh tốt.

1.3 Danh sách các mẫu

Nhiều lập trình viên đã không học được một mẫu nào trong suốt cuộc đời của họ, tuy nhiên, điều đó không ngăn cản họ sử dụng chúng. Như chúng tôi đã nói trước đây, các mẫu là giải pháp tốt đã được thử nghiệm theo thời gian và nếu lập trình viên không phải là kẻ ngốc, thì với kinh nghiệm, chính anh ta sẽ tìm ra các giải pháp như vậy.

Nhưng tại sao, trải qua hàng chục thử nghiệm và sai lầm, đi đến giải pháp tối ưu khi có những người đã đi trên con đường này và đã viết những cuốn sách với tinh hoa của kinh nghiệm và trí tuệ cuộc sống của họ?

Bạn có thể đóng đinh bằng cờ lê, nhưng tại sao? Bạn thậm chí có thể sử dụng máy khoan nếu bạn cố gắng hết sức. Nhưng việc sở hữu nhạc cụ một cách có ý thức chính xác là điều phân biệt một người chuyên nghiệp với một người nghiệp dư. Và người chuyên nghiệp biết rằng tính năng chính của mũi khoan hoàn toàn không nằm ở chỗ này. Vì vậy, tại sao bạn cần biết các mẫu?

• Các giải pháp đã được chứng minh. Bạn dành ít thời gian hơn khi sử dụng các giải pháp có sẵn thay vì phát minh lại bánh xe. Một số quyết định bạn có thể tự nghĩ ra, nhưng nhiều quyết định có thể là một khám phá cho bạn.
• Tiêu chuẩn hóa mã. Bạn ít tính toán sai hơn khi thiết kế, sử dụng các giải pháp thống nhất điển hình, vì tất cả các vấn đề tiềm ẩn trong đó đã được tìm ra từ lâu.
• Từ điển lập trình chung. Bạn nói tên của mẫu thay vì dành một giờ để giải thích cho các lập trình viên khác về thiết kế tuyệt vời mà bạn đã nghĩ ra và những lớp nào cần thiết cho việc này.

Các mẫu là gì?

Các mẫu khác nhau về mức độ phức tạp, chi tiết và phạm vi bao phủ của hệ thống được thiết kế. Vẽ một sự tương tự với việc xây dựng, bạn có thể tăng độ an toàn của giao lộ bằng cách đặt đèn giao thông hoặc bạn có thể thay thế giao lộ bằng một giao lộ toàn bộ ô tô có đường chui.

Các mẫu đơn giản và cấp thấp nhất là thành ngữ. Chúng không phổ biến, vì chúng chỉ được áp dụng trong khuôn khổ của một ngôn ngữ lập trình.

Linh hoạt nhất là các mẫu kiến ​​trúc có thể được thực hiện bằng hầu hết mọi ngôn ngữ. Chúng cần thiết để thiết kế toàn bộ chương trình chứ không phải các yếu tố riêng lẻ của nó.

Nhưng điều chính là các mẫu khác nhau về mục đích. Các mẫu mà chúng ta sẽ làm quen có thể được chia thành ba nhóm chính:

• Các mẫu tạo đảm nhiệm việc tạo các đối tượng một cách linh hoạt mà không đưa các phụ thuộc không cần thiết vào chương trình.
• Các mẫu cấu trúc chỉ ra những cách khác nhau để xây dựng mối quan hệ giữa các đối tượng.
• Các mẫu hành vi đảm nhận việc giao tiếp hiệu quả giữa các đối tượng.

1.4 Giới thiệu về UML

Hãy bắt đầu bằng cách xem xét 23 mẫu giống nhau đã được mô tả trong cuốn sách Gang of Four. Cả bản thân các mẫu và tên của chúng đều là những thứ quen thuộc ngay cả đối với một lập trình viên mới làm quen. Tôi sẽ giới thiệu bạn với họ, nhưng tôi thực sự khuyên bạn nên đọc cuốn sách về các mẫu đó.

Các mẫu thiết kế không bị ràng buộc với một ngôn ngữ lập trình cụ thể, vì vậy UML thường được sử dụng để mô tả chúng. Nó đã rất phổ biến cách đây 20 năm, nhưng thậm chí bây giờ đôi khi nó vẫn được sử dụng. Và nhân tiện, mô tả các mẫu chỉ là nơi sử dụng UML là tiêu chuẩn.

Với UML, bạn có thể mô tả mối quan hệ giữa các thực thể khác nhau. Trong trường hợp của chúng tôi, đây là các đối tượng và lớp.

Quan hệ giữa các lớp được mô tả bằng bốn loại mũi tên:

Trên thực tế, mọi thứ ở đây rất đơn giản. Mũi tên cuối cùng thực sự có nghĩa là một lớp được kế thừa từ một lớp khác. Và mũi tên thứ nhất và thứ hai là một đối tượng lưu trữ một liên kết đến đối tượng thứ hai. Và đó là tất cả.

Nếu viên kim cương liên kết có màu đen, thì liên kết đó yếu: các vật thể có thể tồn tại mà không có nhau. Nếu viên kim cương có màu trắng, thì các đối tượng có liên quan chặt chẽ với nhau, chẳng hạn như một lớp HttpRequestvà lớp con của nó HttpRequest.Builder.

1.5 Danh sách các mẫu

Các loại hoa văn sẽ được biểu thị bằng màu sắc và chữ cái khác nhau:

b- hành vi (hành vi);

C- tạo (sáng tạo);

S- cấu trúc (cấu trúc).

Và cuối cùng là danh sách 23 mẫu thiết kế: