How to design specialised UI for subclasses

Question

5.00/5 (2 votes)

See more:

I am writing a C++ application where i have an object model and a UI (as most applications do). For the model, i have a main object and a number of specialised subclasses. The UI has context menus and property dialogs that i want to be specific to each object type. The main object has a number of actions that are available in the menu, but the subclasses need to add menu items (actions). And similarly for the property dialog - it needs to display data specific to each subclass.

My question is what is a good way to design this?

I can put all the menu creation code in each class, so that the specialised classes override the function to give their own menus. Like this (pseudo-code):

class MainObject {
    virtual MenuList getMenus() {
        return Menu("do something"),
               Menu("do something else"),
               Menu("do a third thing"),
    }
};

class SpecialObjectA : public MainObject {
    virtual MenuList getMenus() {
        return MainObject::getMenus() + Menu("special menu A");
    }
};

class SpecialObjectB : public MainObject {
    virtual MenuList getMenus() {
        return MainObject::getMenus() + Menu("special menu B");
    }
};

But that seems like the model classes are doing too much. They shouldn't be responsible for creating and managing UI objects.

So maybe i could create a separate object hierarchy for creating the menus. Each class would be responsible for creating the menu for it's respective model object. Something like this:

class MainMenuController {
    MainObject* theObject;
    virtual MenuList getMenus() {
        return Menu("do something"),
               Menu("do something else"),
               Menu("do a third thing"),
    }
};

class SpecialMenuControllerA : public MainMenuController {
    SpecialObjectA* theObject;
    virtual MenuList getMenus() {
        return MainObject::getMenus() + Menu("special menu A");
    }
};

class SpecialMenuControllerB : public MainMenuController {
    SpecialObjectB* theObject;
    virtual MenuList getMenus() {
        return MainObject::getMenus() + Menu("special menu B");
    }
};


class MainObject {
    virtual MenuList getMenus() {
        return new MainMenuController()->getMenus();
    }
};

class SpecialObjectA : public MainObject {
    virtual MenuList getMenus() {
        return new SpecialMenuControllerA()->getMenus();
    }
};

class SpecialObjectB : public MainObject {
    virtual MenuList getMenus() {
        return new SpecialMenuControllerB()->getMenus();
    }
};

But then i'm not sure where the logic for performing each menu action should go. Since each action operates on the model object, those MenuController classes above would need to know what object the action is for.

I am using Qt, so i could use their powerful signals and slots mechanism to do this, but i'm not quite sure how.
Does anyone have an idea of what Object Oriented design patterns to use here? I can provide more detail if my problem is unclear.

thanks

Posted 10-Jan-11 11:16am

XTAL256

Add a Solution

Comments

Sergey Alexandrovich Kryukov 10-Jan-11 19:23pm

You're posing very interesting problems (my vote of 5), which need some thinking...

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2011-01-10T15:44:00

This is a topic of prolonged discussion. Basically, you started to think in right direction, but still far away from well balanced approach.

First, let me offer some criticism. You first goal should be isolation of UI from "business logics". You first options is worse, because all mixed together. You formulation of the problem itself actually misses important point: you describe menu items, which are by far less important than menu actions.

First thing to do: you need to introduce a notion of action which is abstracted from the UI controls use to invoke an action. The action be invoked from any UI element you may decide.

Your second approach looks a bit better, but it will not reach your goals. 1) still you're thinking about menu items only; this is inadequate level of abstraction; and related: 2) why UI object are aware of logical objects, not the other way around? Right, the menu items (or whatever triggers the actions) act on the logical object, so the UI class holds a reference to it. But as the state of you logical object changes, the set of valid operations changes. What triggers that change? You may need to equip some "properties" describing logical objects with side effect to trgger UI representation of the object, and -- importantly -- the states of the controls user to trigger action should be invalidated. In terms of you menu items, some of the items should be enabled/disables, others probably renamed, hidden, etc. Don't forget, at the same time the logical object should be agnostic to UI controls and perhaps actions. Also, is your application multi-threading? it makes a big difference.

This way, we're running into some self-referencing deadlock in the design, from the other hand, it should bring the idea of having some intermediate agent sitting between the UI and you logical objects, some "middleman".

Working people devised different schema used to tackle such problems. You can learn them by getting familiar with some design patterns.

Here are the patterns you probably need to understand:

Model-View-Controller (MVC)

Model View ViewModel (MVVM)

Model-View-Presenter

First two are considered as architectural patterns, the last one as a design pattern, derivative from MVC, where the role of "middleman" is performed by Application Controller.

The choice of best-fitting pattern for you projects really depends on the scale of the project, its goals and other detail. It really takes experience and critical thinking.