CODEWITHSUNDEEP
javadesign-patternscomposite
Jack welch
Jack welch

Reputation: 1707

composite pattern implementation

I am writing a code that involves composite pattern and would like some clarification. I have Super Manager, a Main Manager and Ordinary Manager and they are in a descending hierarchy with the Super Manager at the top.

I would want the Super Manager to be able to give Main Manager some money and Main Manager to be able to give Ordinary Manager some money. The problem I have is I don't want Main Manager to be able to give Super Manager some money and I don't want to use instanceof to ensure that, since it defeats the purpose of Composite pattern.

My Main Manager and Ordinary Manager extend an abstract class called gradeManagers while my Super Manager has an array list to be able to to add components of type gradeManagers.

Upvotes: 1

Views: 718

Answers (3)

Nilesh
Nilesh

Reputation: 4177

I would extend @Ted Hopp's answer and suggest that instead of depth you could use grade. This might be closer to the domain you are working with. Since you already pointed out that you do have grading managers this may be an elegant solution.

Hope that helps.

Upvotes: 0

kba
kba

Reputation: 19466

As it has already been mentioned by Ted Hopp, this doesn't sound like something where you'd use a Composite Pattern. This just sounds like a case of polymorphism.

Composite Pattern should be used when you want a group of items to be treated as one. Consider a drawing program where you can place shapes on a screen, this could be triangles, squares, etc. Now, consider a functionality where you are able to change the background color of those shapes. If you wanted to change the background color of multiple shapes, you'd want to do something like this

interface Shape {
    public void setBackgroundColor(Color c);
}

And in your actual implementation code:

 for (Shape s : selectedShapes)
     s.setBackgroundColor(c);

Instead of doing this in the code, you could use a composite pattern. This allows your implementation code to be completely oblivious to the fact that the "shape" you want to edit is actually multiple shapes, and allowing your application to treat it as any other shape.

class CompositeShape implements Shape
{
    public void setBackgroundColor(Color c);
    for (Shape s : Shapes)
        s.setBackgroundColor(c);
}

class TriangleShape implements Shape { ... }
class SquareShape implements Shape { ... }

Upvotes: 1

Ted Hopp
Ted Hopp

Reputation: 234795

It doesn't sound like your hierarchy is a great fit for the Composite pattern. The Composite pattern is meant to allow a collection of objects to be treated in the same way as individual objects. (Think of parts being bolted together. Sometimes you want to think of a sub-assembly as a single part that can be bolted together with other parts/sub-assemblies. The sub-assemblies are the composites.) If I understand what you are trying to do, you don't have a collection of Manager objects that you want to treat as another Manager.

Nevertheless, whether or not you use Composite for this, I suggest adding a property (let's call it depth) that increases as you go down the hierarchy. You can then use this to implement your business rule: a Manager can only give money to another Manager of equal or higher depth. This allows you to code in a way that avoids any notion of object class.

Upvotes: 5

Related Questions