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 followinga. 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 userDisadvantage -1. Although frontpanel doesn't have number key pressed functionality. I will be adding the dummy method for frontpanel also.
Is factory pattern a right pattern for the situation described here?
java;design patterns;c++