4 ms·

That was my thought at first as well, but probably for illustrative purposes, it was easier to do if-else statements. The more structure there is, the higher th

by iamwil 16y ago

That was my thought at first as well, but probably for illustrative purposes, it was easier to do if-else statements. The more structure there is, the higher the learning curve. For a presentation, it probably wasn't necessary.

nostrademons 16y ago
In practice, it turns out to be easier to do with if-else statements as well. A factory pattern is useful when you know ahead of time along what dimensions your system will change. You can build an interface with methods for each of those change points, then call out to those methods when appropriate. For each experimental variant, you provide a different implementation and instantiate it based on experiment selection at the factory. Unfortunately, these types of configuration changes, by definition, tend to be experimental. Meaning you have no idea how the app is going to change to accommodate them, you just have an idea that might or might not help users and you want to test that hypothesis as quickly as possible. Rearchitecting your app to build the appropriate factory interfaces takes significantly longer than just throwing in an if, and it's all wasted effort if the experiment comes back with a null result (as many do). If you find yourself making experimental changes to the same areas often, then you might want to look at introducing a Factory. But design patterns in general are something you reach for once the system has matured, not something you do when you're still experimenting and exploring the domain.
- stcredzero 16y ago
  If you read my post carefully, I propose a Factory, then reject it in favor of something simpler. My proposal reduces the refactoring to "this block of code becomes a function call." There's still a piece of conditional logic, for each dimension, but it only gets written once. The application code gets smaller by applying this, except for one startup routine where we set up the thunk. Overall, it's actually less code than sprinkling conditionals everywhere. You could set things up so you change the configuration of all your A/B experiments in a single file. It's not so much a pattern as it is a reorganization of the logic along a straightforward application of DRY. One might still want to stick with the conditionals everywhere if most of the code needs local state. This is probably an indication of a need to refactor, though.

by iamwil 16y ago

nostrademons 16y ago

In practice, it turns out to be easier to do with if-else statements as well. A factory pattern is useful when you know ahead of time along what dimensions your system will change. You can build an interface with methods for each of those change points, then call out to those methods when appropriate. For each experimental variant, you provide a different implementation and instantiate it based on experiment selection at the factory. Unfortunately, these types of configuration changes, by definition, tend to be experimental. Meaning you have no idea how the app is going to change to accommodate them, you just have an idea that might or might not help users and you want to test that hypothesis as quickly as possible. Rearchitecting your app to build the appropriate factory interfaces takes significantly longer than just throwing in an if, and it's all wasted effort if the experiment comes back with a null result (as many do). If you find yourself making experimental changes to the same areas often, then you might want to look at introducing a Factory. But design patterns in general are something you reach for once the system has matured, not something you do when you're still experimenting and exploring the domain.

stcredzero 16y ago
If you read my post carefully, I propose a Factory, then reject it in favor of something simpler. My proposal reduces the refactoring to "this block of code becomes a function call." There's still a piece of conditional logic, for each dimension, but it only gets written once. The application code gets smaller by applying this, except for one startup routine where we set up the thunk. Overall, it's actually less code than sprinkling conditionals everywhere. You could set things up so you change the configuration of all your A/B experiments in a single file. It's not so much a pattern as it is a reorganization of the logic along a straightforward application of DRY. One might still want to stick with the conditionals everywhere if most of the code needs local state. This is probably an indication of a need to refactor, though.