Is factory pattern a right pattern for the situation described here?

Question

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.

Answer 1

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.

Answer 2

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.