3 ms·

also, a mention of GoF Command pattern further convinces me that all design patterns are just workaround to shortcomings of mainstream languages of the time and

also, a mention of GoF Command pattern further convinces me that all design patterns are just workaround to shortcomings of mainstream languages of the time and are simply unnecessary in proper FP languages or at least languages with higher order functions and other functional features. cargo culting design patterns into languages that don't need them is ironic.

TheOtherHobbes 7y ago
Design patterns often seem to rearrange complexity instead of removing it. If you split everything up into nice manageable <40 LOC chunks, you now have tens or hundreds of nice manageable <40 LOC chunks to document, use, and remember - probably spread across a similarly large number of files. It looks neater while you're writing it, but it's debatable if it's any easier to understand if you're trying to debug it. Especially if you're coming in cold, and there's an unnecessarily high level of abstraction, added for the sake of following the patterns. See also: https://ieeexplore.ieee.org/document/4493325 https://ieeexplore.ieee.org/document/4493325 Realistically, the benefits don't seem to be empirically proven - certainly not with any persuasively high level of independent replication.
- andyg_blog 7y ago
  One reason to break up a function is deep logic nesting. If you consider the Code Coverage metric a valid metric, then it says we'd need 2^N independent tests to validate each possible branch of logic in a function. Breaking that nesting can reduce the number of required tests by an order of magnitude. At that point we may need an integration test to validate that we can transition from one to the other neatly, but this grows linearly instead of exponentially. Deep nesting often comes with very long functions.
  - Sean1708 7y ago
    How do objects removing branching from an algorithm? It may not be there as an if-statement, but (unless I'm missing something) you'll still conceptually have a branch.
    - andyg_blog 7y ago
      It's not objects necessarily; they're simply a way to group a set of related functions. It's functions. Separate functions can be separately unit tested. Then you can write an integration test that uses each of those functions. The testing obligations can be overall much smaller as a result.

TheOtherHobbes 7y ago

Design patterns often seem to rearrange complexity instead of removing it. If you split everything up into nice manageable <40 LOC chunks, you now have tens or hundreds of nice manageable <40 LOC chunks to document, use, and remember - probably spread across a similarly large number of files. It looks neater while you're writing it, but it's debatable if it's any easier to understand if you're trying to debug it. Especially if you're coming in cold, and there's an unnecessarily high level of abstraction, added for the sake of following the patterns. See also: https://ieeexplore.ieee.org/document/4493325 https://ieeexplore.ieee.org/document/4493325 Realistically, the benefits don't seem to be empirically proven - certainly not with any persuasively high level of independent replication.

andyg_blog 7y ago
One reason to break up a function is deep logic nesting. If you consider the Code Coverage metric a valid metric, then it says we'd need 2^N independent tests to validate each possible branch of logic in a function. Breaking that nesting can reduce the number of required tests by an order of magnitude. At that point we may need an integration test to validate that we can transition from one to the other neatly, but this grows linearly instead of exponentially. Deep nesting often comes with very long functions.
- Sean1708 7y ago
  How do objects removing branching from an algorithm? It may not be there as an if-statement, but (unless I'm missing something) you'll still conceptually have a branch.
  - andyg_blog 7y ago
    It's not objects necessarily; they're simply a way to group a set of related functions. It's functions. Separate functions can be separately unit tested. Then you can write an integration test that uses each of those functions. The testing obligations can be overall much smaller as a result.