Có sự khác biệt nào về mặt triển khai hay không như cách thiết kế bố cục có thể khác với ủy quyền. Ví dụ, mã bên dưới dường như đang thực hiện ủy quyền vì người dùng không thể truy cập đối tượng đã soạn (ví dụ "a") mà không sử dụng b. Do đó, người dùng sẽ cần phải gọi các giao diện của lớp b và sau đó "lớp b" gọi các giao diện thích hợp của "lớp a" làm cho nó ủy nhiệm. Điều này có nghĩa không ?Thành phần so với đoàn đại biểu
Class A {
friend class B;
private:
A(){}; //dont want user to instantiate this class object since it wont sense without any context. Just like a room with no house.
void PrintStructure(){};
};
Class B{
public:
void PrintStructure(){a.PrintStructure();} //delegate
private:
A a; //composition
};
Nếu thành phần ngụ ý rằng trẻ không thể tồn tại mà không có bối cảnh của phụ huynh thì người dùng có nên không bao giờ được phép tạo đối tượng của lớp được tạo không? Ví dụ: ví dụ tinh tế của tôi sẽ là lớp A {friend Class B; riêng tư: A() {}; void PrintStructure() {}; }; Lớp B {public: void PrintStructure() {a.PrintStructure();} // ủy nhiệm riêng: A a; //thành phần }; Bây giờ lớp B có lớp A. Một người dùng chỉ phải sử dụng các giao diện lớp B để thay đổi hành vi của lớp A và lớp B nên ủy nhiệm các nhiệm vụ đó cho các hàm hạng A. Thiết kế này có tốt không? –
@Frank: Các lớp bạn bè là một cách để thực hiện loại mối quan hệ này. Mặc dù họ không ủng hộ tôi. Một giải pháp thanh lịch hơn là có hàm khởi tạo cho Room để yêu cầu một cá thể của House, sau đó trở thành "parent" của nó. – cletus
Bạn sẽ viết mã như thế nào trong ví dụ của tôi? Hơn nữa, tôi không muốn người dùng có thể khởi tạo đối tượng A vì sẽ không có ý nghĩa khi thực hiện bất kỳ thao tác nào trên A mà không có ngữ cảnh B. –