Delegating whole class bad practice?

Question

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) { dim.setDimension(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:

appState.dim.setDimension(...) //or appState->dim.setDimension(...)

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

Thanks in advance.

@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
– a a, Commented Jan 22, 2022 at 9:24
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(...). — Filip Milovanović
– Filip Milovanović, Commented Jan 23, 2022 at 2:33

Christophe · Accepted Answer · 2022-01-22 14:37:41Z

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).

Stack Exchange Network

Delegating whole class bad practice?

1 Answer 1

Hot Network Questions

Delegating whole class bad practice?

1 Answer 1

Related

Hot Network Questions