8 ms·

Feature flags are usually just a poor-man's way to separate development (changing) and live (stable) code branches. They have explosive complexity (2^n combinat

by spolsky 17y ago

Feature flags are usually just a poor-man's way to separate development (changing) and live (stable) code branches. They have explosive complexity (2^n combinations need to be tested). They require you to contort your code unnaturally to minimize the number of conditionals.

jedbrown 17y ago
Compile-time choices are a terrible code smell. If object creation is sorted out (through dependency injection/service locator/etc), the compile-time choice can usually map to exactly one runtime option and exactly one conditional.
- raganwald 17y ago
  Exactly. You're already creating all your objects with factories, so all you have to do is build a FactoryFactory that builds the right kind of factories and you're good to go... http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joelonsoftware.com/default.asp?joel.3.219431
  - jedbrown 17y ago
    While that's a classic and amusing essay, having client code depend on concrete types instead if interfaces is lame unless you can be confident that they won't change their mind about which one they want to work with. I write mostly C, don't have anything called a factory, and yet every major object has a plugin architecture, many of these have more than a dozen implementations, and client code automatically works with all of them (and any that they or a third-party have written). Say what you will about architecture astronomy, but this is not complex and is far more maintainable and usable than the alternatives.
    - raganwald 17y ago
      I'll take it one further and suggest that the expression concrete type is an oxymoron and that there are many, many ways to decouple code. You've mentioned two orthogonal ways to achieve this goal: Programming to interfaces (most people use this term to mean collections of method signatures) and Plugin Architectures (which sounds a lot like using composition or strategies instead of implementations). But I stand by the tongue-in-cheek suggestion that FactoryFactories are high altitude if not low earth orbit. And obviously, you can use factories and still switch between production and development with a single flag. So please don't interpret my remarks as critical of code I've never actually seen.
      - jedbrown 17y ago
        My use of "concrete types" was merely a proxy for any code upon which client code should not have an explicit dependency. I don't see interfaces and plugins as being orthogonal at all, you can't very well have plugins without interfaces (it wouldn't be much of a plugin if the client depended on the "plugin" itself). Besides, orthogonal vectors don't get you to the same place. ;-) In my opinion, the defining feature of a plugin is that it can be loaded and used with no modification of the code that uses it. On architectures with dynamic loading, this means you can drop a DSO somewhere and use it without code modification or relinking. "Factories", as usually described, would require some modification of the factory to support this new implementation (perhaps just a single line). A "factory" with a runtime-extensible list of implementations that it knows about, is a plugin architecture, but a plugin architecture need not look anything like a factory.
        raganwald 17y ago
        I think that some of our discussion around terms is an artefact of discussing a manifestly typed language like C. But if we handwave and say that "interface" is any dependency with at least one level of indirection and "concrete type" is any dependency with no levels of indirection, I agree that you can't implement plugins without some indirection somewhere. That being said, you clearly can implement indirection without plugins. I think of a plugin architecture as being composition at a coarse level. In the case of a factory with a runtime list of implementations, I think of that as a factory and a plugin architecture, possibly that the plugin architecture is implemented with a factory.
  - jrockway 17y ago
    This is a poor argument (and sadly, I know exactly what you're linking to, without actually clicking it). Factory factories, or dependency injection, is a lot more like Futamura Projections than a factory factory factory factory because you want a hammer. On Futamura Projections: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f... (And that's fu-ta-mu-ra, a Japanese name; not fu-tu-ra-ma, the TV show. I read it wrong the first time, and so did everyone I've admitted that to :)

by spolsky 17y ago

jedbrown 17y ago

Compile-time choices are a terrible code smell. If object creation is sorted out (through dependency injection/service locator/etc), the compile-time choice can usually map to exactly one runtime option and exactly one conditional.

raganwald 17y ago
Exactly. You're already creating all your objects with factories, so all you have to do is build a FactoryFactory that builds the right kind of factories and you're good to go... http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joelonsoftware.com/default.asp?joel.3.219431
- jedbrown 17y ago
  While that's a classic and amusing essay, having client code depend on concrete types instead if interfaces is lame unless you can be confident that they won't change their mind about which one they want to work with. I write mostly C, don't have anything called a factory, and yet every major object has a plugin architecture, many of these have more than a dozen implementations, and client code automatically works with all of them (and any that they or a third-party have written). Say what you will about architecture astronomy, but this is not complex and is far more maintainable and usable than the alternatives.
  - raganwald 17y ago
    I'll take it one further and suggest that the expression concrete type is an oxymoron and that there are many, many ways to decouple code. You've mentioned two orthogonal ways to achieve this goal: Programming to interfaces (most people use this term to mean collections of method signatures) and Plugin Architectures (which sounds a lot like using composition or strategies instead of implementations). But I stand by the tongue-in-cheek suggestion that FactoryFactories are high altitude if not low earth orbit. And obviously, you can use factories and still switch between production and development with a single flag. So please don't interpret my remarks as critical of code I've never actually seen.
    - jedbrown 17y ago
      My use of "concrete types" was merely a proxy for any code upon which client code should not have an explicit dependency. I don't see interfaces and plugins as being orthogonal at all, you can't very well have plugins without interfaces (it wouldn't be much of a plugin if the client depended on the "plugin" itself). Besides, orthogonal vectors don't get you to the same place. ;-) In my opinion, the defining feature of a plugin is that it can be loaded and used with no modification of the code that uses it. On architectures with dynamic loading, this means you can drop a DSO somewhere and use it without code modification or relinking. "Factories", as usually described, would require some modification of the factory to support this new implementation (perhaps just a single line). A "factory" with a runtime-extensible list of implementations that it knows about, is a plugin architecture, but a plugin architecture need not look anything like a factory.
      - raganwald 17y ago
        I think that some of our discussion around terms is an artefact of discussing a manifestly typed language like C. But if we handwave and say that "interface" is any dependency with at least one level of indirection and "concrete type" is any dependency with no levels of indirection, I agree that you can't implement plugins without some indirection somewhere. That being said, you clearly can implement indirection without plugins. I think of a plugin architecture as being composition at a coarse level. In the case of a factory with a runtime list of implementations, I think of that as a factory and a plugin architecture, possibly that the plugin architecture is implemented with a factory.
- jrockway 17y ago
  This is a poor argument (and sadly, I know exactly what you're linking to, without actually clicking it). Factory factories, or dependency injection, is a lot more like Futamura Projections than a factory factory factory factory because you want a hammer. On Futamura Projections: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f... (And that's fu-ta-mu-ra, a Japanese name; not fu-tu-ra-ma, the TV show. I read it wrong the first time, and so did everyone I've admitted that to :)