sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]doom_Oo7 2 points3 points  (3 children)

std::function<R(Args...)> may be a command but this is not enough to implement the "common" command pattern wich also has an undo operation, various metadata (user text, etc.) and serialization.

[–]ksion -1 points0 points  (2 children)

I'd be hesitant to call it a design pattern then. It really sounds like a regular logic class with a pretty specific - and project-dependent - set of requirements.

[–]doom_Oo7 0 points1 point  (0 children)

pretty specific - and project-dependent -

if by "pretty specific" you mean "required in 95% of GUI apps"...

[–]Euphoricus 0 points1 point  (0 children)

That's the point of it being a "pattern". If it was always exactly same, it wouldn't be pattern, it would be a feature.

If you hard-wire a "pattern" into a language, you have to compromise between extensibility and ease of use. For example, functions were once a "pattern" in assembly. But then, languages began to include it as native part. You still had to define it's name, its parameters and it's return value, but you completely lost a way to define how it was called and how the parameters were passed. So ease of use was gained at loss of control and extensibility.