Suppose I have the following struct:

struct Dimension
    void setDimension(Vector2i dim);
    Vector2i getDimension() const;
    bool canShowInformation();

And this struct uses the Dimension struct:

struct ApplicationState
    Dimension dim;
    State currentState;

    //Delegate everything to Dimension struct.
    void setDimension(Vector2i dim)
    Vector2i getDimension() const
        return dim.getDimension();
    bool canShowInformation()
        return canShowInformation();

Is it bad to wrap almost all methods of Dimension struct in the ApplicationState struct? I do this so that I won't have long method calls like this:


Is there a design principle or pattern which solves this problem?

Thanks in advance.

  • 2
    If you're delegating everything, why not just inherit? Jan 22, 2022 at 9:17
  • @PhilipKendall ApplicationState will have other functionality not related to the dimension, like stuff related to the currentState and StateChanges. So it won't just be a special case of Dimension. If for example ÀpplicationState will have 10 methods at the end and only three of them are delegations to Dimension should I inherit from ````Dimension```?
    – a a
    Jan 22, 2022 at 9:24
  • "so that I want have long method" do you mean won't?
    – Ewan
    Jan 22, 2022 at 9:48
  • 1
    long method names are considered a good thing(tm)
    – Ewan
    Jan 22, 2022 at 9:48
  • 2
    In addition to what Christophe said below, if AppState is a thing that conceptually has a dimension instance as its part, then doing this wrapping for ease of use (at the cost of more dificult maintenance) kind of undoes what you've accomplished by defining the Dimension struct in the first place. You've created a separate struct that represents the "dimension" concept in a higher level way - and now you're polluting your AppState class with details that are the responsibility of Dimension. You can always create a local ref/ptr to 'appState.dim', & then just do dim.setDimension(...). Jan 23, 2022 at 2:33

1 Answer 1


It depends on your design intention:

  • If ApplicationState and Dimension address different concerns and may evolve due to different reasons, then it is fine.

  • Likewise, if ApplicationState is just there for using a Dimension with another interface/protocol, then it is an adapter and is also fine.

  • If ApplicationState is nothing else than a specialized Dimension, then this might be overkill.

To make up your design decision, you should also be aware that lots of appState.dim.dimOperation() creates a de facto coupling that works well in practice but makes the code difficult to maintain (see also principle of least knowledge).

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.