3 ms·

In general I think that a lot of these design "principles" are just mislabeled. A better label is generally "rough hewn guideline to use in a first pass at desi

In general I think that a lot of these design "principles" are just mislabeled. A better label is generally "rough hewn guideline to use in a first pass at design". Many of them contradict each other, or even themselves, especially when rotely applied beyond sensibility. Take for instance DRY - if you follow it too far, you end up with InterfaceFactoryFactoryFoo. And of course all those FactoryFactories start to look like violations of DRY anyway. Or the over-application of SRP ends up with 40 classes that are tiny slices of something that could easily be 1 class. Amusingly both are the result of myopic application, going fractal if you will, on the principle, rather than setting a decent "scope" for the application of the ideas. Further as you go through design and implementation, you find places where the design abstractions were wrong, and the "single thing" or "unrepeated task" is violated, in the large (rather than in the tiny) and you have to accept it or do some refactoring. Such is life. None of these things takes away the value of DRY or SOLID or any of the other design principles - it's just that there is a very hard orthogonal problem of "proper scoping" for these principles.

dragonwriter 12y ago
> Take for instance DRY - if you follow it too far, you end up with InterfaceFactoryFactoryFoo. And of course all those FactoryFactories start to look like violations of DRY anyway. Right. DRY runs into limits when you use languages with limited expressiveness -- and, particularly, Java-like class-oriented languages where classes are not, themselves, first-class are problematic here. The problem isn't with the DRY principle, its with a language that doesn't really let you follow it, because certain things cannot be effectively abstracted out into reusable library code and require boilerplate. Most of these things are not problems with, e.g., Lisps.
- TeMPOraL 12y ago
  > Most of these things are not problems with, e.g., Lisps. This is where the Lisp macros start to shine - you can DRY up the code structure itself. The need for that doesn't come that often (I'm personally in the camp of avoiding macros until you're really sure they're the best tool for the job) but when you are really starting to get sick of that repetitiveness that obscure the intention behind your code, macros are really godsend.

dragonwriter 12y ago

> Take for instance DRY - if you follow it too far, you end up with InterfaceFactoryFactoryFoo. And of course all those FactoryFactories start to look like violations of DRY anyway. Right. DRY runs into limits when you use languages with limited expressiveness -- and, particularly, Java-like class-oriented languages where classes are not, themselves, first-class are problematic here. The problem isn't with the DRY principle, its with a language that doesn't really let you follow it, because certain things cannot be effectively abstracted out into reusable library code and require boilerplate. Most of these things are not problems with, e.g., Lisps.

TeMPOraL 12y ago
> Most of these things are not problems with, e.g., Lisps. This is where the Lisp macros start to shine - you can DRY up the code structure itself. The need for that doesn't come that often (I'm personally in the camp of avoiding macros until you're really sure they're the best tool for the job) but when you are really starting to get sick of that repetitiveness that obscure the intention behind your code, macros are really godsend.