Is this composite pattern implementation proper?

Question

Hi

Refer code below which I did for composite pattern demo:
https://www.sololearn.com/compiler-playground/c8i3yyr0wNWx

Feel free to share your views on same. Any improvement advice is most welcome.

Also I have two doubts as below :
1. This design is validating Interface Segregation Principle due to AddReportee() and RemoveReportee(). These two methods are not required for Individuals class , but required for Manager class. If I remove it from Employee Interface, Composite pattern is violated and don't have option to do same thing on leaf and components. If we don't remove, It violates Interface Segregation. How to overcome this issue?

2. Suppose now spHR2 becomes manager for someone. So, How to add reportees to him as It is object of Individuals type.

P.S. : Adding one more point:

3. Is list data member is proper data structure choice for manager class?
https://code.sololearn.com/c8i3yyr0wNWx/?ref=app

Answer 1

Hi Ketan,
I think about Interface Seg Princ in such case you can consider creating a more specific interface for Managers that includes AddReportee, RemoveRepirtee. this way I think you can adhere to the principle without forcing methods that don't make sense for certain classes, something like :
class IManager : public IEmployee {
public:
virtual void AddReportee(shared_ptr<IEmployee> spComp) = 0;
virtual void RemoveReportee(shared_ptr<IEmployee> spComp) = 0;
};
And about spHR2 because it's of type Individuals, so u cannot directly add reportee to it, So I think creating a new Managers object for spHR2 if it becomes a manager
or by allowing an Individuals to be promoted to a Managers type. well, absolutely would require some re-structuring and dynamiq object type change

Answer 2

Thank you so much for your valuable suggestion. :D

I have tried to modify code and it seems now Interface segregation is best compared to earlier code version. Is this correct and same as what you suggested?

https://www.sololearn.com/compiler-playground/c8f77o9V4q0Y

Earlier , below 4 managerial objects were of type

shared_ptr<IEmployee> spCEO = make_shared<Managers>("CEO");
shared_ptr<IEmployee> spITHead = make_shared<Managers>("IT Head");
shared_ptr<IEmployee> spHRHead = make_shared<Managers>("HR Head");
shared_ptr<IEmployee> spAdminHead = make_shared<Managers>("Admin Head");

and now changes their pointer type from IEmployee to IManager as below:

shared_ptr<IManager> spCEO = make_shared<Managers>("CEO");
shared_ptr<IManager> spITHead = make_shared<Managers>("IT Head");
shared_ptr<IManager> spHRHead = make_shared<Managers>("HR Head");
shared_ptr<IManager> spAdminHead = make_shared<Managers>("Admin Head");

In both the versions, actual object is of type Managers, but pointer is now of type IManager instead of IEmployee.

shared_ptr<IManager> spCEO = make_shared<Managers>("CEO");
shared_ptr<IManager> spITHead = make_shared<Managers>("IT Head");
shared_ptr<IManager> spHRHead = make_shared<Managers>("HR Head");
shared_ptr<IManager> spAdminHead = make_shared<Managers>("Admin Head");

Answer 3

oh, Hi Ketan
Well, I just read your code, and I think now is much better and adheres to the ISP. Your code structure is better aligned with the composite pattern as well,, looks more organized. Maybe one more thing about (3. data structure choice) if you anticipate the need for frequent additions and removals of reportees, you might want to consider using a different data structure, such as a 'vector', maybe 'unordered_set', which might (or might not😑) provide better performance for these operations (depends on data size🗂️