5 ms·

Does it? The class-based solution looks very convenient to me for large projects. Let's say I am new to the project and I don't know what commands exist. I just

Does it? The class-based solution looks very convenient to me for large projects. Let's say I am new to the project and I don't know what commands exist. I just ask the IDE to show me all sub classes of the command super class. That sounds much better than searching the functions implementing the different operations everywhere in the source code. Not everything that is easier to write is easier to read two years later (even if it has much less lines).

TeMPOraL 8y ago
Unless there's some magic involved (like pulling code from strings at runtime, via reflection), you'll have a place in which all those functions show up together. A central table, a switch statement in a factory method, or something. You'll have it in either the class-based or function-based implementation.
- tralarpa 8y ago
  > you'll have a place in which all those functions show up I don't see why. For example, imagine a graphical editor. GUI events will trigger some actions and those actions will trigger some commands being execute (and placed in an undo buffer etc.). I don't see where that central place should be and why you would need it at all. And now imagine a large project with different ways to execute commands ("execute", "executeWithUndo", "executeInTransaction",...), people composing new commands from existing ones, etc. Soon grep becomes your best friend. Or just press Ctrl-H or whatever in your favorite Java IDE to see the class hierarchy.
  - TeMPOraL 8y ago
    > and why you would need it at all. Because in the functional model, you're not abusing the filesystem or inheritance hierarchy to do your bookkeeping. Also, I said functions, not necessarily anonymous ones. There are ways to solve this use case. You can stash your actions as named public static functions in a "Commands" class. Or you can create one dummy class with @Functional on its only method, that essentially forwards the call. So in your UI handlers, you do button.setOnAction(new Command(someFunctionSomewhere));, instead of having a separate class for every possible action. You can now find all actions by looking up calls to Command c-tor(s), and you can build subtypes of Command as you need some special functionality. Note that this way, you don't commit yourself early to a huge type hierarchy. In my experience, even in large projects, Command objects tend to sit in the filesystem, wasting space and people's time. But if you're absolutely sure you'll need this pattern, then go ahead and use it. It just shouldn't be the default, go-to way of solving this problem.

TeMPOraL 8y ago

Unless there's some magic involved (like pulling code from strings at runtime, via reflection), you'll have a place in which all those functions show up together. A central table, a switch statement in a factory method, or something. You'll have it in either the class-based or function-based implementation.

tralarpa 8y ago
> you'll have a place in which all those functions show up I don't see why. For example, imagine a graphical editor. GUI events will trigger some actions and those actions will trigger some commands being execute (and placed in an undo buffer etc.). I don't see where that central place should be and why you would need it at all. And now imagine a large project with different ways to execute commands ("execute", "executeWithUndo", "executeInTransaction",...), people composing new commands from existing ones, etc. Soon grep becomes your best friend. Or just press Ctrl-H or whatever in your favorite Java IDE to see the class hierarchy.
- TeMPOraL 8y ago
  > and why you would need it at all. Because in the functional model, you're not abusing the filesystem or inheritance hierarchy to do your bookkeeping. Also, I said functions, not necessarily anonymous ones. There are ways to solve this use case. You can stash your actions as named public static functions in a "Commands" class. Or you can create one dummy class with @Functional on its only method, that essentially forwards the call. So in your UI handlers, you do button.setOnAction(new Command(someFunctionSomewhere));, instead of having a separate class for every possible action. You can now find all actions by looking up calls to Command c-tor(s), and you can build subtypes of Command as you need some special functionality. Note that this way, you don't commit yourself early to a huge type hierarchy. In my experience, even in large projects, Command objects tend to sit in the filesystem, wasting space and people's time. But if you're absolutely sure you'll need this pattern, then go ahead and use it. It just shouldn't be the default, go-to way of solving this problem.