Is factory pattern a right pattern when we want to consolidate the related objects?

Problem - In the Set-top box, I have a user-io, basically the interface to control the settop box - The user-io can be rcu i.e. remote control, front panel - the buttons on the Set-top box, and the rear-rcu - this is used for testing the bunch of settop boxes.

Solution - A factory object that checks whether the user-io type is rcu or front-panel. This factory object will create the required product. The factory object has a dependency on the abstract user-io. This user-io will force to have the concrete class the following methods - Channel up, Channel down, Volume up, Volume down, Power Up/down and the number key ( which may not be in the front-panel). Thus front panel will not do anything on the method number key pressed.

The factory object will create the concrete class ( rcu or fp) and will store in the user-io type pointer.

The main class, will create a factory object, that can be singleton, and will have the related objects with it.

Can I say that the advantage here what I will gain is the following a. The related classes are consolidated/organized together. b. When I want to access the rcu or fp. I see them as only user-io, which is true by concept. c. The FP will have the led or flash light functionality.So, while creating the fp, I need to create LED object also. A FP dependency on the LED,which I can hide from the user

Disadvantage - 1. Although frontpanel doesn't have number key pressed functionality. I will be adding the dummy method for frontpanel also.

  • 4
    Your problem description is incomplete. You only describe a situation, not a goal. Nov 11, 2014 at 14:07
  • 1
    Why are you assuming that RCU and front panel cannot exist at the same time?
    – Euphoric
    Nov 11, 2014 at 15:20
  • Is this situation right for the factory design pattern? Nov 12, 2014 at 5:48
  • The RCU and FP can exist simultaneously. I never denied it. Nov 12, 2014 at 5:48

2 Answers 2


The Final products which you want to create are

1) Remote control Unit

2) Front Panel

3) Buttons on Setup box

So, I think the situation is not highly dynamic. (May be in future you may have to add one more type of new device.)

so, with Factory Method / Abstract factory we end up with parallel creator class hierarchy. This approach of creating objects would unnecessarily add too many creator classes.

so, a little variation on factory method is "Static Factory method" which will make sure it creates required class object(s ) based on the need.

And as mentioned above, you may just need one "Virtual-Base" which defines General operations and the default behaviour. Derived class will override what is needed for it.


You could use a factory, but you said that the factory would have "a dependency on the abstracted user-io", which would already be instantiated.

The factory should be the means by which the abstracted user-io is created in the first place. If that is already created then you've already passed the point where the factory would be useful.

Something will happen that will determine which user-io should be used. This could be a UX event, input value, or a difference in IR signal, whatever. That should be what the factory has a dependency on, if a factory is indeed necessary.

Technically you only need an abstract class or interface, where the FP implementation does not support everything. Alternatively the common interface could only include the common functionality of the two implementations.

Ultimately only you have enough info for which to decide how to implement the solution, we can only help provide understanding about where certain tools and patterns can be beneficial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.