4 ms·

I use this pattern a lot (and I often find myself wishing I used it more). Another way to think about this is "noun-ification" (aka the Command pattern) - inste

I use this pattern a lot (and I often find myself wishing I used it more). Another way to think about this is "noun-ification" (aka the Command pattern) - instead of invoking a function directly, capture all of its arguments, serialize them to some "store", then provide the ability to rehydrate them and actually run it.

caseyohara 2y ago
Interesting you used the term hydrate because I only hear that used when talking about front-end web development (specifically Next and React) and it's a relatively new term. The "Hydration (web development)" Wikipedia article was only created in December 2020. https://en.wikipedia.org/wiki/Hydration_(web_development) https://en.wikipedia.org/wiki/Hydration_(web_development) I feel like serialize/deserialize or marshal/demarshal are more common in broader computer science contexts.
- stevesimmons 2y ago
  "Hydrate" is much older than 2020. Here's a StackOverflow reference from 2011 [1], for instance. I first heard it used around that time, for loading objects from databases (in a banking context). [1] https://stackoverflow.com/a/4929478 https://stackoverflow.com/a/4929478
munificent 2y ago
I came here to say basically the same thing. To me, this reads like an example of the Command pattern, which is one of my favorite, most-used patterns. The idea of taking some chunk of imperative behavior and reifying it into an object that can perform that behavior is very powerful: * It allows you to attach other metadata to the object so that code can ask questions about it: "Do you perform IO?" "Can you be reverted?" It lets surrounding code introspect over operations in useful ways. * It allows you to separate the code that creates the command from the code that performs it (what this blog post is about). This can nicely decouple "strategy"-type code from "execution harness" type code. Both of those are often fairly complex in their own right, so a pattern that lets you build a nice abstraction layer between them can be very helpful. * It allows the command object to support multiple related operations. The most common example, which I deeply love, is implementing undo. A Command object for some UI operation can also support a separate method to undo the same operation. Your undo stack is then just a list of these Command objects.

caseyohara 2y ago

Interesting you used the term hydrate because I only hear that used when talking about front-end web development (specifically Next and React) and it's a relatively new term. The "Hydration (web development)" Wikipedia article was only created in December 2020. https://en.wikipedia.org/wiki/Hydration_(web_development) https://en.wikipedia.org/wiki/Hydration_(web_development) I feel like serialize/deserialize or marshal/demarshal are more common in broader computer science contexts.

stevesimmons 2y ago
"Hydrate" is much older than 2020. Here's a StackOverflow reference from 2011 [1], for instance. I first heard it used around that time, for loading objects from databases (in a banking context). [1] https://stackoverflow.com/a/4929478 https://stackoverflow.com/a/4929478

munificent 2y ago

I came here to say basically the same thing. To me, this reads like an example of the Command pattern, which is one of my favorite, most-used patterns. The idea of taking some chunk of imperative behavior and reifying it into an object that can perform that behavior is very powerful: * It allows you to attach other metadata to the object so that code can ask questions about it: "Do you perform IO?" "Can you be reverted?" It lets surrounding code introspect over operations in useful ways. * It allows you to separate the code that creates the command from the code that performs it (what this blog post is about). This can nicely decouple "strategy"-type code from "execution harness" type code. Both of those are often fairly complex in their own right, so a pattern that lets you build a nice abstraction layer between them can be very helpful. * It allows the command object to support multiple related operations. The most common example, which I deeply love, is implementing undo. A Command object for some UI operation can also support a separate method to undo the same operation. Your undo stack is then just a list of these Command objects.