Composing Object Princible
Một vấn đề phổ biến trong hệ thống thiết kế hướng đối tượng mà các mẫu thiết kế cố gắng giải quyết là làm thế nào để giảm lượng khớp nối chặt chẽ ? Các nguyên tắc thiết kế được sử dụng bởi tất cả các mẫu thiết kế xác định các cách khác nhau trong đó khớp nỗi có thể được quản lý. Ít kết nối trong hệ thống của bạn có nghĩa là hệ thống của bạn có thể linh hoạt hơn và có khả năng sử lý các thay đổi đối với cơ sở mã hiện có của nó, chẳng hạn như tích hợp tính năng mới.
Các mẫu thiết kế mà chúng ta đã khám phá sử dụng rất nhiều khái quát hóa, trừu tượng hóa và đa hình như là phương tiện của sự gián tiếp. Mặc dù kế thừa là một cách tuyệt vời để đạt được số lượng tái sử dụng mã cao, nhưng nó đi kém với phí kết hợp chặt chẽ giữa siêu lớp và các lớp con của nó. Vì vậy, tại sao có khớp nối ? Hãy suy nghĩ về những gì kế thừa làm trong lâp trình hướng đối tượng ? Khi một lớp con kế thừa từ một superclass, lớp con có được kiến thức và quyền truy cập của chúng những gì không private. Điều này có nghĩa là nếu bạn có nhiều cấp thừa kề, một lớp con dưới cùng của cây thừa kế có khả năng có thể có cách truy cập các thuộc tính và hành vi của tất cả các siêu lớp.
Vậy, chúng ta có thể làm gì để tránh điều này ? Bạn có thể sử dụng Composing Object Princible để đạt được số lượng tái sử dụng mã cao mà không cần sử dụng tính kế thừa. Nguyên tắc này nói rằng các lớp nên đạt được tái sử dụng mã thông qua tổng hơp chứ không phải kế thừa.
Các mẫu thiết kế, chẳng hạn như Composite Pattern hay Decorator Pattern sử dụng nguyên tắc thiết kế này, cả hai mẫu tạo thành các lớp cụ thể để xây dựng các đối tượng phức tạp hơn cùng một lúc. Hành vi tổng thể đến từ tổng hợp của các đối tượng riêng lẻ. Một đối tượng có thể sử dụng lại và tổng hợp một đối tượng khác để ủy thác một số yêu cầu nhất định của nó. Ỷ tưởng là bạn muốn thiết kế hệ thống của mình để các lớp cụ thể có thể ủy thác nhiệm vụ cho các lớp cụ thể khác. Trước tiên, hãy xem xét các lợi thế:
Lợi ích của Composing Object Princible đó là tập hợp và ủy quyền cung cấp ít khớp nối hơn so với kế thừa. Vì các lớp soạn thảo không chia sẻ thuộc tính hoặc triển khai các hành vi, chúng độc lập với nhau hơn.
Trong kế thừa, tất cả các lớp con của một superclass liên kết chặt chẽ với superclass đó. Làm thế nào các lớp của bạn sẽ tự điều chỉnh trong giai đoạn thiết kế phát triển của bạn ?
Trong sơ đồ UML bên trái, các đối tượng có thể được composing đệ quy và thống nhất. Hoặc ở bên phải, một đối tượng bao gồm một đối tưọng khác có kiểu nhất quán.
Composing object cũng cung cấp cho hệ thống của bạn linh hoạt hơn, trong giai đoạn thiết kế, việc tách các lớp trở nên dễ dàng và tự nhiên hơn. Soạn thảo các đối tượng không bắt buộc bạn phải cố gắng và tìm điểm tương đồng giữa hai lớp và ghép chúng lại với nhau như một sự kế thừa. Thay vào đó, bạn có thể thiết kế các lớp có thể làm việc cùng nhau mà không phải chia sẻ bất kỳ điều gì giữa chúng. Tính linh hoạt này cũng sẽ giúp bạn nếu các yêu cầu hệ thống thay đổi.
Nếu bạn sử dụng thừa kế, bạn có thể phải cơ cấu lại toàn bộ cây thừa kế của mình. Cuối cùng, việc composing các đối tượng cho phép bạn, thực tế, thay đổi linh hoat các hành vi của các đối tượng trong thời gian chạy. Bạn có thể xây dựng một tổ hợp hành vi tổng thể, mới bằng cách composing các đối tượng. Với sự kế thừa, bạn không cần cung cấp cho mỗi lớp con thực hiện một hành vi được chia sẻ riêng. Việc thực hiện phổ biến chỉ đơn giản là truy cập trong superclass, cần cung cấp triển khai cho mọi lớp có nghĩa là sẽ mất thời gian và tài nguyên. Một lập trình viên làm việc về việc cung cấp nhiều triển khai cho cùng một hành vi có nghĩa là bạn sẽ có một lập trình viên làm việc ít hơn trên các tính năng khác.
Nguyên tắc Composing Object có nhiều lợi thế so với việc sử dụng tính kế thừa để sủ dụng lại mã và xây dựng các hành vi một cách linh hoạt. Nguyên tắc thiết kế này sẽ giúp bạn giảm việc ghép nối trong hệ thống của bạn bằng cách sử dụng ủy quyền và kết hợp các đối tượng với nhau.
Tóm lại, nguyên tắc này sẽ cung cấp một phương tiện tái sử dụng mã mà không có sự kết hợp chặt chẽ của kế thừa. Cho phép các đối tượng tự động thêm các hành vi trong thời gian chạy và cung cấp cho hệ thống của bạn linh hoạt hơn. Điều này có nghĩa là cần ít thời gian hơn để cập nhật hệ thống, bây giờ, không phải nói rằng không nên sử dụng thừa kế, sáng tác đối tượng trong thừa kế đều có vị trí của chúng, sáng tác sẽ giúp bạn linh hoạt hơn và ít khớp nối hơn trong khi vẫn duy trì khả năng sử dụng lại, nhưng điều đó không có nghĩa là nó phải luôn được sử dụng so với kế thừa.
Bạn phải kiểm tra nhu cầu của bạn để xác định nguyên tắc thiết kế nào là phù hợp
Các mẫu thiết kế mà chúng ta đã khám phá sử dụng rất nhiều khái quát hóa, trừu tượng hóa và đa hình như là phương tiện của sự gián tiếp. Mặc dù kế thừa là một cách tuyệt vời để đạt được số lượng tái sử dụng mã cao, nhưng nó đi kém với phí kết hợp chặt chẽ giữa siêu lớp và các lớp con của nó. Vì vậy, tại sao có khớp nối ? Hãy suy nghĩ về những gì kế thừa làm trong lâp trình hướng đối tượng ? Khi một lớp con kế thừa từ một superclass, lớp con có được kiến thức và quyền truy cập của chúng những gì không private. Điều này có nghĩa là nếu bạn có nhiều cấp thừa kề, một lớp con dưới cùng của cây thừa kế có khả năng có thể có cách truy cập các thuộc tính và hành vi của tất cả các siêu lớp.
Vậy, chúng ta có thể làm gì để tránh điều này ? Bạn có thể sử dụng Composing Object Princible để đạt được số lượng tái sử dụng mã cao mà không cần sử dụng tính kế thừa. Nguyên tắc này nói rằng các lớp nên đạt được tái sử dụng mã thông qua tổng hơp chứ không phải kế thừa.
Các mẫu thiết kế, chẳng hạn như Composite Pattern hay Decorator Pattern sử dụng nguyên tắc thiết kế này, cả hai mẫu tạo thành các lớp cụ thể để xây dựng các đối tượng phức tạp hơn cùng một lúc. Hành vi tổng thể đến từ tổng hợp của các đối tượng riêng lẻ. Một đối tượng có thể sử dụng lại và tổng hợp một đối tượng khác để ủy thác một số yêu cầu nhất định của nó. Ỷ tưởng là bạn muốn thiết kế hệ thống của mình để các lớp cụ thể có thể ủy thác nhiệm vụ cho các lớp cụ thể khác. Trước tiên, hãy xem xét các lợi thế:
Lợi ích của Composing Object Princible đó là tập hợp và ủy quyền cung cấp ít khớp nối hơn so với kế thừa. Vì các lớp soạn thảo không chia sẻ thuộc tính hoặc triển khai các hành vi, chúng độc lập với nhau hơn.
Trong kế thừa, tất cả các lớp con của một superclass liên kết chặt chẽ với superclass đó. Làm thế nào các lớp của bạn sẽ tự điều chỉnh trong giai đoạn thiết kế phát triển của bạn ?
Trong sơ đồ UML bên trái, các đối tượng có thể được composing đệ quy và thống nhất. Hoặc ở bên phải, một đối tượng bao gồm một đối tưọng khác có kiểu nhất quán.
Composing object cũng cung cấp cho hệ thống của bạn linh hoạt hơn, trong giai đoạn thiết kế, việc tách các lớp trở nên dễ dàng và tự nhiên hơn. Soạn thảo các đối tượng không bắt buộc bạn phải cố gắng và tìm điểm tương đồng giữa hai lớp và ghép chúng lại với nhau như một sự kế thừa. Thay vào đó, bạn có thể thiết kế các lớp có thể làm việc cùng nhau mà không phải chia sẻ bất kỳ điều gì giữa chúng. Tính linh hoạt này cũng sẽ giúp bạn nếu các yêu cầu hệ thống thay đổi.
Nếu bạn sử dụng thừa kế, bạn có thể phải cơ cấu lại toàn bộ cây thừa kế của mình. Cuối cùng, việc composing các đối tượng cho phép bạn, thực tế, thay đổi linh hoat các hành vi của các đối tượng trong thời gian chạy. Bạn có thể xây dựng một tổ hợp hành vi tổng thể, mới bằng cách composing các đối tượng. Với sự kế thừa, bạn không cần cung cấp cho mỗi lớp con thực hiện một hành vi được chia sẻ riêng. Việc thực hiện phổ biến chỉ đơn giản là truy cập trong superclass, cần cung cấp triển khai cho mọi lớp có nghĩa là sẽ mất thời gian và tài nguyên. Một lập trình viên làm việc về việc cung cấp nhiều triển khai cho cùng một hành vi có nghĩa là bạn sẽ có một lập trình viên làm việc ít hơn trên các tính năng khác.
Nguyên tắc Composing Object có nhiều lợi thế so với việc sử dụng tính kế thừa để sủ dụng lại mã và xây dựng các hành vi một cách linh hoạt. Nguyên tắc thiết kế này sẽ giúp bạn giảm việc ghép nối trong hệ thống của bạn bằng cách sử dụng ủy quyền và kết hợp các đối tượng với nhau.
Tóm lại, nguyên tắc này sẽ cung cấp một phương tiện tái sử dụng mã mà không có sự kết hợp chặt chẽ của kế thừa. Cho phép các đối tượng tự động thêm các hành vi trong thời gian chạy và cung cấp cho hệ thống của bạn linh hoạt hơn. Điều này có nghĩa là cần ít thời gian hơn để cập nhật hệ thống, bây giờ, không phải nói rằng không nên sử dụng thừa kế, sáng tác đối tượng trong thừa kế đều có vị trí của chúng, sáng tác sẽ giúp bạn linh hoạt hơn và ít khớp nối hơn trong khi vẫn duy trì khả năng sử dụng lại, nhưng điều đó không có nghĩa là nó phải luôn được sử dụng so với kế thừa.
Bạn phải kiểm tra nhu cầu của bạn để xác định nguyên tắc thiết kế nào là phù hợp
Nhận xét
Đăng nhận xét