http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Is the way you've designed RhinoETL an implementation of the command pattern? http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment13http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment13Sun, 23 Dec 2012 07:42:57 GMTHey Ayende, you really should spend some time with F# if you haven't already. With first class functions, it's a much more natural way to represent and encapsulate units of computation, you can even compose/chain them together to build up more complex computations (such as the combinator-based family of parsers). I think you'll really like it! :-)http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment12http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment12Sat, 24 Nov 2012 23:49:06 GMTAnonymous, Lambdas are commands, yes. But in many cases I find it useful to wrap them in a real class, because it make it explicit how / why we capture the parameters for the command to execute.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment11http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment11Wed, 21 Nov 2012 06:22:47 GMTDon't forget the ever popular MacroCommand where you wrap a series of commands into another command that you can then execute / unexecute as a batch... super useful, indeed.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment10http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment10Tue, 20 Nov 2012 17:45:04 GMTI completely agree. I see that very frequently the business object of importance is a process, e.g. NotifyShipping, SaveProfile, etc. And, I like how "object-izing" a process is a straight-forward modeling of what computers do: input, *processing*, output, (storage). I like what Anonymous had to say about using delegates, although I haven't found wrapping up an external dependency in an interface to be as significant an annoyance for me. I played around with constructor-based dependency injection with delegates as declared dependencies, and I liked that a method didn't have to be tied to the delegate definition, unlike a defined interface. I used StructureMap to inject dependencies on delegates, which worked great, but part of me felt like it wasn't cohesive enough. I guess I haven't completely resolved how I feel about it yet or when and when not to do it.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment9http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment9Tue, 20 Nov 2012 15:06:02 GMTDo you consider using lambda functions and delegates as an instance of the Command pattern? If you do, then yes, I also use them heavily. They are particularly interesting because you can achieve the same as implementing a interface but not committing to a particular one at compile time. This is particularly useful when you can not assume a common interface for your objects (such as when they come from a third party library), and implementing several facades would be too much hassle for little benefit. Instead, you can map object methods to delegates on site and have your algorithm control the third-party objects without an explicitly interface definition.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment8http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment8Tue, 20 Nov 2012 14:41:09 GMTI'd say let's not exaggerate. Command is extremely useful when you need to generate commands in one place and run them in another. It's also the only decent way I'm aware of to properly implement unlimited undo. But there are situations in which not using command yields smaller and simpler code, which wouldn't have significant benefits if using command. http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment7http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment7Tue, 20 Nov 2012 14:34:20 GMTAyende - while I do agree with you that the Command pattern is very useful in the various cases you specified, I see it get abused too many times (sometimes really using it as an anti-pattern). For example, I've seen many architects design entire interfaces around the Command pattern (defining a single method which accepts a command derived object), resulting in a very generic definition and implementation - where more specifics would have greatly simplified the code and its maintainability over time.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment6http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment6Tue, 20 Nov 2012 14:19:27 GMTAlso nice for dependency injection.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment5http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment5Tue, 20 Nov 2012 13:28:45 GMTA nice extension of Command is CompoundCommand (or CompositeCommand, or whatever). A single command that contains an ordered list of commands. Iterate through your commands and call Execute(). Iterate backwards and call Undo(). A nice, single object responsible for a large piece of work, but still following the single responsibility principal by delegating actual meaningful work onto more granular commands.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment4http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment4Mon, 19 Nov 2012 20:22:24 GMTOnly when I started looking at how you used this pattern in RacoonBlog did I really get why it was so useful to me as a C# .Net developer. The ability to unit test tasks themselves and then just confirm there existence in other places (MVC Controller) was amazing. Really helped me focus and write meaningful unit tests. Jimmy Bogard at CodeBetter even goes as far as to turn the command pattern into a Query pattern. He encapsulates complex queries into a class that returns a dataset. http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment3http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment3Mon, 19 Nov 2012 13:47:05 GMTAs well as undo\redo support we've had great success combining the command pattern with the visitor pattern. You have a selection of items and a single command which visits each item in the selection performing the action. If each visit pushes its undo state on to a stack up can easily undo the operation again.http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment2http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment2Mon, 19 Nov 2012 12:52:46 GMTAdded to that: you can extend commands to implement undo/redo easily, by adding a state and an 'undo' action next to the actual do action. Shameless plug: I implemented this in Algorithmia (OSS, bsd license), where I added a command implementation, which is able to undo actions by the command, and various data structures which are command aware (and thus undo aware) like graphs and lists: http://algorithmia.codeplex.com http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment1http://ayende.com/159873/design-patterns-in-the-test-of-time-command#comment1Mon, 19 Nov 2012 10:20:19 GMT