Hello to all, Does any design patterns that replace the switch case approach ? I looking for any techniques that replace switch case or if statement because i develop a menu options and there are a lot of option which display to user. Thanks. [Edited by - Peter_APIIT on June 27, 2009 3:47:22 AM]

Monads and hashtables of objects/functions from the top of my head

Quote:Original post by Hodgman
polymorphism

QFT

">Google tech talks - Clean code talks

[Edited by - dmail on June 27, 2009 6:27:52 AM]

Perhaps mapping member function to array of function then based on the choice and called the appropriate function.

That's what polymorphism does under the hood, basically.

To be more explicit...

A Menu is a collection of Menu Items.

The Menu has a Menu View.

Each Menu Item has meta-information:
What category it belongs to. Is it a sub-menu? An action? Both?

Sub-menus can be asked to produce a menu. There may be multiple 'styles' of sub-menu, or not.

Actions can be asked to run.

In addition, Menu Items have display information. Do they have a string-based name? An icon?

Your menu view is fed a Menu. It then displays a view of that Menu, asking each item enough information to display it. Maybe it displays menu items that have sub menus with a little |> next to them -- whatever, and actions with some other indication, and items that are 'both' as a combo-box with an execute button. When you pick a sub menu, maybe it does a stack-based view, or maybe it does a flyout-based view -- whatever.

Heck, maybe the menu view is a text interface, or a drop-down from a menu bar, or a right-click list, or a modal dialog.

The menu doesn't care. The view deals with that problem.

All of this doesn't matter to the menu. The menu is a collection of menu items.

Pattern used: Model/View (Model = menu, View = menu view). Maybe implement the rendering of the Model/View with the Visitor pattern, or maybe not.

The menu is populated through one of many ways. Maybe you have a registry of menu items. Which you then feed an array of the uids to the menu generator. Or maybe your menus are actually flyweights of the uids themselves, and the menu object is built by grabbing configuration data from the menu registry.

Much of the above is data-driven design. Instead of having code that describes the layout of your menus, you have data that your menu engine uses to determine the layout of your menus.

Depending on the scale of your project, much of the above will be serious overkill.

Actually i just talking about console menu option with 1 to 5 option for user.

The polymorphism has a type to determine which function but my situation is there are only 1 type at a time.

Please advice.

Write your menu to contain an arbitrary number of options.

The view of the menu (the one that says "pick one of the following: 1: foo, 2: bar, ...") gets the user input.

It then determines which menu to use (possibly using a std::vector<> look-up), and depending on the data in that menu item, does something.

Maybe it calls a function in the menu item that determines what happens. Maybe it displays a sub-menu based off data in that menu item.

This is classic model/view stuff, with maybe a dash of flyweight.

Another consideration is that you might not want your menu to be 'stack based'.

Ie, if a menu item says "run X", it doesn't run it in the current context, but rather has it set up the running of X to happen. If you have a stack of menus, store the explicitly instead of implicitly in the execution stack, so you can manipulate it.

By this point I'm probably beyond what you need for your particular project.

Quote:Original post by Peter_APIIT
Actually i just talking about console menu option with 1 to 5 option for user.

The polymorphism has a type to determine which function but my situation is there are only 1 type at a time.

class Menu {  virtual void handle() = 0;};class MenuA : Menu {  virtual void handle() {    printMenu();    int option = getInput();    switch (option) {      case 0 : doA(); break;      case 1 : doB(); break;      case 2 : {        anotherMenu->handle();        break;      }      default:        print("Invalid selection");    }  }};

No, really, it is just as simple as that.

Quote:i develop a menu options and there are a lot of option which display to user.

5 is not a lot.

The only time you do not want a switch statement is when options change during run-time. But that complicates many other things as well.