Các thành phần:
Component (Customer):
Mô hình hóa một sự trừu tƣợng chính nhất định bởi xác định giao diện của nó.
Xác định các giao thức cho việc thêm, loại bỏ, thử nghiệm và truy vấn các đối tƣợng vai trò.
ComponentCore (CustomerCore):
Thực thi giao diện Component bao gồm các phƣơng thức để quản lý các vai trò.
Tạo ra thực thể ConcreteRole.
Quản lý các đối tƣợng vai trò của nó.
ComponentRole (CustomerRole):
Mô hình và thực thi một sự mở rộng xác định ngữ cảnh của giao diện Component.
Có thể đƣợc khởi tạo với một tham số ComponentCore Các đối tƣợng lõi và vai trò cộng tác với nhau:
ComponentRole chuyển tiếp các yêu cầu tới đối tƣợng ComponentCore của nó.
ComponentCore khởi tạo và quản lý các ConcreteRole.
Một client tƣơng tác với các đối tƣợng lõi và vai trò theo cách:
Một client có thể gửi tới các đối tƣợng lõi các vai trò. Để thực hiện điều đó nó định rõ các vai trò mong muốn với các đối tƣợng xác định.
Mỗi khi client muốn làm việc trên một đối tƣợng lõi theo một cách xác định vai trò, nó yêu cầu đối tƣợng lõi cho vai trò này. Nếu đối tƣợng lõi hiện tại đang đóng vai trò đƣợc yêu cầu, nó đƣợc trả về cho client.
Nếu các đối tƣợng lõi không đóng vai trò đƣợc yêu cầu, một lỗi đƣợc đƣa ra. Một đối tƣợng lõi không bao giờ tạo ra các đối tƣợng vai trò thuộc sở hữu của nó.
Sự trừu tƣợng chính có thể đƣợc xác định một cách xúc tích. Giao diện Component tập trung vào các cƣ xử và trạng thái thiết yếu của sự trừu tƣợng chính đƣợc mô hình và không bị phồng lên bởi các vai trò xác định ngữ cảnh
Các vai trò có thể đƣợc phát triển một cách dễ dàng và độc lập với những vai trò khác. Việc mở rộng giao diện Component là có thể thực hiện một cách dễ dàng bởi vì không phải thay đổi lớp ComponentCore. Một lớp ConcreteRole cho phép bạn thêm vào các vai trò mới và các thực thi vai trò trong khi vẫn tự bảo vệ sự trừu tƣợng chính. Các đối tƣợng vai trò có thể đƣợc thêm và loại bỏ một cách động. Một đối tƣợng vai trò có thể đƣợc thêm và loại bỏ tại lúc thực thi bởi việc gắn kết và phân tách nó từ đối tƣợng lõi. Do đó chỉ các đối tƣợng cần thiết trong tình huống đƣa ra là thực sự đƣợc tạo ra.
Các ứng dụng tốt hơn là nên phân tách. Bởi việc chia tách tƣờng minh giao diện Component khỏi các vai trò của nó, sự gắn kết của các ứng dụng dựa trên sự mở rộng vai trò khác nhau đƣợc hạn chế. Một ứng dụng (Client A) sử dụng giao diện Component và một số lớp ConcreteRole xác định ngữ cảnh không cần biết lớp ConcreteRole đƣợc sử dụng trong các ứng dụng khác (Client B).
Việc thực thi mẫu Role Object phải chú trọng tới 2 yếu tố then chốt: việc mở rộng một cách trong suốt các sự trừu tƣợng chính với các vai trò và việc quản lý động các vai trò này. Đối với việc mở rộng một cách trong suốt, chúng ta sử dụng mẫu Decorator. Với việc tạo và quản lý các vai trò, chúng ta áp dụng mẫu Product Trader.
Do đó mẫu Role Object kết hợp 2 mẫu nổi tiếng theo cách thêm vào các ngữ nghĩa mới.
Cung cấp sự thích ứng giao diện: bởi vì chúng ta muốn các đối tƣợng vai trò đƣợc sử dụng một cách trong suốt ở những nơi mà đối tƣợng lõi có thể đƣợc sử dụng, chúng phải hỗ trợ một giao diện thông dụng. Chú ý rằng từ một điểm mô hình của tầm nhìn, một lớp role đƣợc xem nhƣ là một sự đặc biệt hóa của đối tƣợng core của nó, chẳng hạn một Investor là một Customer. Mẫu Decorator cho chúng ta biết làm thế nào để thực hiện điều này. Trƣớc tiên, chúng ta đƣa ra một giao diện thông dụng cho tất cả các đối tƣợng mà có các vai trò đƣợc thêm vào chúng một cách động. Giao diện này đƣợc cung cấp bởi lớp Component trong sơ đồ cấu trúc và tƣơng ứng với lớp Component trong mẫu Decorator. Với tất cả các vai trò xác định ngữ cảnh mà có thể mở rộng các chức năng của Component, chúng ta đƣa ra lớp cha trừu tƣợng ComponentRole mà tƣơng ứng với lớp Decorator. ComponentRole thực thi giao diện của Component bởi chuyển tiếp việc gọi các thao tác của đối tƣợng lõi. Do đó, các vai trò bao bọc lõi một cách trong suốt. Các lớp ConcreteRole phải thừa kế từ ComponentRole. Chúng tƣơng ứng với lớp ConcreteDecorator trong mẫu Decorator.
Ẩn quá trình tạo đối tƣợng vai trò. Các bản thể role đƣợc sử dụng để trang trí một đối tƣợng lõi tại lúc thực thi. Một vấn đề chính là làm thế nào một bản thể ConcreteRole thực sự đƣợc tạo ra và đƣợc gắn kết vào đối tƣợng lõi. Chú ý rằng các ConcreteRole không đƣợc tạo ra bởi các client. Đúng hơn là quá trình tạo vai trò sẽ đƣợc khởi tạo bởi ComponentCore, do đó tránh đƣợc là các đối tƣợng vai trò có thể tồn tại tự nó ( độc lập với một đối tƣợng lõi). Điều này cũng ngăn cản các client biết làm thế nào để tạo ra các đối tƣợng vai trò.
Việc tách các lớp vai trò với lõi: việc tạo ra và quản lý các vai trò nên đƣợc thực hiện theo kiểu cách giống loài. Hay nói cách khác nó trở lên khó khăn nếu không thể không mở rộng một ComponentCore với các vai trò mới và không đoán trƣớc mà không thay đổi sự thực thi của nó. Do đó, cả hai quá trình tạo và quản lý phải là sự độc lập của các lớp vai trò cụ thể. Mã ComponentCore phải không tham chiếu tĩnh tới chúng.
Việc quản lý các đối tƣợng role: để cho một đối tƣợng core quản lý các vai trò của nó, giao diện Component khai báo một giao thức quản lý role mà bao gồm các thao tác thêm, loại bỏ, thử nghiệm và truy vấn các đối tƣợng role. Để hỗ trợ giao thức quản lý vai trò, đối tƣợng core duy trì một từ điển ánh xạ các sự xác định vai trò với các bản thể vai trò cụ thể. Mỗi khi một đối tƣợng vai trò đƣợc gắn kết vào đối tƣợng
Duy trì trạng thái đối tƣợng role và core nhất quán: các thay đổi đối với đối tƣợng lõi hay đối với các đối tƣợng vai trò có thể yêu cầu cập nhật tới các đối tƣợng vai trò khác. Chẳng hạn, xem xét sự thay đổi tên của một Person mà cũng là Borrower. Mỗi khi Person nhận một tên mới, một cờ phải đƣợc đƣa ra trong vai trò Borrower để chỉ ra rằng Borrower đã có sự thay đổi tên.
Duy trì định danh khái niệm. Mẫu Role Object cho phép chúng ta quản lý đối tƣợng lõi và các vai trò của nó nhƣ là một đối tƣợng khái niệm đơn với trạng thái đƣợc tích hợp. Do đó client có thể nhận biết đƣợc hai đối tƣợng kỹ thuật phân biệt thực sự là phần của cùng một đối tƣợng logic, đó là nếu chúng giống nhau về khái niệm. Các đối tƣợng vai trò khác nhau chia sẻ một định danh đối tƣợng khái niệm đơn mỗi khi chúng có cùng lõi.
Duy trì các ràng buộc trong số các vai trò. Giữa các vai trò, bản thân chúng, có thể có một số ràng buộc. Một trƣờng hợp phổ biến là một vai trò B yêu cầu một vai trò A đã đƣợc đóng vai bởi đối tƣợng. Chẳng hạn, nếu Customer và Borrower là các vai trò của Person, thế thì sự tồn tại của một đối tƣợng vai trò Customer là một tiền điều kiện cho phép một Person đóng vai trò Borrower. Chúng là các ràng buộc cấp vai trò. Khả năng của một đối tƣợng đóng vai trò B xác định bị hạn chế trong trƣờng hợp mà đối tƣợng đó đã đóng vai trò A. Không với vai trò A, vai trò B không đƣợc phép đóng vai.
Duy trì các ràng buộc trong số các vai trò bởi áp dụng đệ quy mẫu Role Object. Nhiều trƣờng hợp vấn đề của các ràng buộc mức vai trò có thể đƣợc giải quyết bởi áp dụng mẫu Role Object một cách đệ quy. Nếu một vai trò A là một tiền điều kiện cho một số các vai trò B, C, D… thì vai trò A có thể đƣợc hiểu nhƣ là một sự trừu tƣợng chính cho các vai trò đó. Borrower và Investor có thể đƣợc xem nhƣ là các vai trò của Customer, và Customer và Guarantor có thể đƣợc xem nhƣ là các vai trò của Person. Bởi vì là một Guarantor không yêu cầu là một Customer, nó không cần thiết đƣợc mô hình nhƣ là một vai trò của Customer. Hình sau biểu diễn áp dụng đệ quy của mẫu Role Object.