8.1 Sự phân hủy là tất cả
Để rõ ràng, một hình ảnh từ một bài báo hay "Tách rời các hệ thống hướng đối tượng", minh họa những điểm chính sẽ được thảo luận.
Bạn vẫn nghĩ rằng thiết kế một kiến trúc ứng dụng là dễ dàng?
8.2 Giao diện, ẩn triển khai
Các nguyên tắc chính để giảm sự ghép nối của hệ thống là các nguyên tắc của OOP và nguyên tắc Đóng gói + Trừu tượng + Đa hình đằng sau chúng.
Đó là lý do tại sao:
- Các mô-đun phải là "hộp đen" cho nhau (đóng gói) . Điều này có nghĩa là một mô-đun không được “leo” vào một mô-đun khác và không biết gì về cấu trúc bên trong của nó. Các đối tượng trong một hệ thống con không nên truy cập trực tiếp vào các đối tượng trong một hệ thống con khác.
- Các mô-đun/hệ thống con chỉ nên tương tác với nhau thông qua các giao diện (nghĩa là các phần trừu tượng hóa không phụ thuộc vào các chi tiết triển khai). Theo đó, mỗi mô-đun phải có một hoặc nhiều giao diện được xác định rõ ràng để tương tác với các mô-đun khác.
Nguyên lý “hộp đen” (encapsulation) cho phép chúng ta xem xét cấu trúc của mỗi hệ thống con một cách độc lập với các hệ thống con khác. Mô-đun, là một "hộp đen", có thể được thay đổi tương đối tự do. Các vấn đề chỉ có thể phát sinh tại điểm nối của các mô-đun khác nhau (hoặc mô-đun và môi trường).
Và sự tương tác này phải được mô tả ở dạng chung nhất (trừu tượng), tức là ở dạng giao diện. Trong trường hợp này, mã sẽ hoạt động tương tự với bất kỳ triển khai nào tuân theo hợp đồng giao diện. Đó là khả năng làm việc với các triển khai khác nhau (mô-đun hoặc đối tượng) thông qua một giao diện thống nhất được gọi là tính đa hình.
Đó là lý do tại sao Servlet là một giao diện : bộ chứa web không biết gì về servlet, vì đây là một số đối tượng triển khai giao diện Servlet và chỉ có thế. Servlet cũng biết một chút về cấu trúc của container. Giao diện Servlet là hợp đồng đó, tiêu chuẩn đó, tương tác tối thiểu cần thiết để làm cho các ứng dụng web Java chiếm lĩnh thế giới.
Đa hình hoàn toàn không phải là ghi đè các phương thức, như đôi khi người ta lầm tưởng, mà trước hết là khả năng hoán đổi cho nhau của các mô-đun / đối tượng có cùng giao diện hoặc “một giao diện, nhiều triển khai”. Để thực hiện tính đa hình, cơ chế kế thừa hoàn toàn không cần thiết. Điều này rất quan trọng để hiểu vì thừa kế nói chung nên tránh bất cứ khi nào có thể .
Nhờ các giao diện và tính đa hình, chính xác là khả năng sửa đổi và mở rộng mã mà không thay đổi những gì đã được viết (Nguyên tắc đóng mở) đã đạt được.
Miễn là sự tương tác của các mô-đun được mô tả riêng dưới dạng giao diện và không bị ràng buộc với các triển khai cụ thể, bạn có cơ hội hoàn toàn “không đau đớn” để hệ thống thay thế một mô-đun bằng bất kỳ mô-đun nào khác thực hiện cùng một giao diện, cũng như thêm một cái mới và do đó mở rộng chức năng.
Nó giống như trong LEGO constructor - giao diện tiêu chuẩn hóa sự tương tác và phục vụ như một loại trình kết nối trong đó bất kỳ mô-đun nào có trình kết nối phù hợp đều có thể được kết nối.
Tính linh hoạt của nhà thiết kế được đảm bảo bởi thực tế là chúng ta có thể chỉ cần thay thế một mô-đun hoặc bộ phận này bằng một mô-đun hoặc bộ phận khác có cùng đầu nối (có cùng giao diện), cũng như thêm bao nhiêu bộ phận mới tùy thích (đồng thời, hiện có các bộ phận không được thay đổi hoặc thay đổi theo bất kỳ cách nào).
Các giao diện cho phép bạn xây dựng một hệ thống đơn giản hơn, xem xét toàn bộ từng hệ thống con và bỏ qua cấu trúc bên trong của nó. Chúng cho phép các mô-đun tương tác và đồng thời không biết gì về cấu trúc bên trong của nhau, do đó thực hiện đầy đủ nguyên tắc kiến thức tối thiểu, vốn là cơ sở của khớp nối lỏng lẻo.
Các giao diện được xác định càng chung chung/trừu tượng và càng ít hạn chế mà chúng áp đặt đối với tương tác, thì hệ thống càng linh hoạt. Từ đây, một trong những nguyên tắc nữa của SOLID thực sự tuân theo - Nguyên tắc Phân chia Giao diện , phản đối “giao diện dày”.
Anh ấy nói rằng các giao diện lớn, cồng kềnh nên được chia thành các giao diện nhỏ hơn, cụ thể hơn để khách hàng của các giao diện nhỏ (phụ thuộc vào các mô-đun) chỉ biết về các phương thức mà họ cần làm việc.
Nguyên tắc này được xây dựng như sau: “Khách hàng không nên phụ thuộc vào các phương thức (lưu ý các phương thức) mà họ không sử dụng” hoặc “Nhiều giao diện chuyên biệt tốt hơn một giao diện chung”.
Nó chỉ ra rằng kết nối yếu chỉ được cung cấp khi sự tương tác và phụ thuộc của các mô-đun chỉ được mô tả với sự trợ giúp của các giao diện, nghĩa là trừu tượng hóa, mà không sử dụng kiến thức về cấu trúc và cấu trúc bên trong của chúng. Ngoài ra, chúng tôi có khả năng mở rộng / thay đổi hành vi của hệ thống bằng cách thêm và sử dụng các triển khai khác nhau, nghĩa là do tính đa hình. Vâng, chúng ta lại đến với OOP - Đóng gói, Trừu tượng, Đa hình.
8.3 Mặt tiền: giao diện mô-đun
Ở đây, một lập trình viên có kinh nghiệm sẽ hỏi: nếu thiết kế không ở cấp độ các đối tượng tự triển khai các giao diện tương ứng mà ở cấp độ các mô-đun, thì việc triển khai giao diện mô-đun là gì?
Trả lời: nói theo ngôn ngữ của các mẫu thiết kế, thì một đối tượng đặc biệt có thể chịu trách nhiệm triển khai giao diện mô-đun - Mặt tiền . Nếu bạn đang gọi các phương thức trên một đối tượng chứa hậu tố Cổng (ví dụ: MobileApiGateway), thì đó rất có thể là một mặt tiền.
Mặt tiền là một đối tượng giao diện tích lũy một tập hợp các thao tác cấp cao để làm việc với một hệ thống con nhất định, che giấu cấu trúc bên trong và độ phức tạp thực sự đằng sau nó . Cung cấp bảo vệ chống lại những thay đổi trong việc thực hiện hệ thống con. Phục vụ như một điểm vào duy nhất - "bạn đá vào mặt tiền và anh ta biết ai cần phải đá vào hệ thống con này để có được thứ anh ta cần."
Bạn vừa được giới thiệu về một trong những mẫu thiết kế quan trọng nhất cho phép bạn sử dụng khái niệm giao diện khi thiết kế các mô-đun và do đó tách rời chúng - "Mặt tiền".
Ngoài ra, "Mặt tiền" cho phép làm việc với các mô-đun giống như với các đối tượng thông thường và áp dụng tất cả các nguyên tắc và kỹ thuật hữu ích được sử dụng trong thiết kế các lớp khi thiết kế mô-đun.
Lưu ý : Mặc dù hầu hết các lập trình viên đều hiểu tầm quan trọng của giao diện khi thiết kế các lớp (đối tượng), nhưng có vẻ như nhiều người cũng khám phá ra ý tưởng sử dụng giao diện ở cấp độ mô-đun.