4 ms·

The most maintainable line of code is the one which you don't write. Remember the cardinal virtues: Laziness Impatience Hubris Back when I was a Java dev, jud

The most maintainable line of code is the one which you don't write. Remember the cardinal virtues: Laziness Impatience Hubris Back when I was a Java dev, judiciously following the SOLID principles was a vital part of keeping code maintainable. They're still as true today as they ever were. * a class should have only a single responsibility * software entities should be open for extension, but closed for modification * objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. * many client-specific interfaces are better than one general-purpose interface. * depend upon abstractions, not concretions.

FreezerburnV 10y ago
Can you expand a little about how each of these parts of SOLID have influenced how you have written code? I feel like I've heard people say conflicting things to some degree on at least some of these (e.g.: single responsibility) and my own experience feels somewhat like following some of them to their natural conclusion can end up with code that is more complex and harder to maintain. Again, for example, the S seems to imply needing a larger number of classes that would have to be searched through to find a specific implementation or bug, and D feels like it would shove the code that actually does something down a layer and be harder to find. That could be my inexperience talking or just not knowing how to employ the ideas properly, though. I guess a decent amount of what I'm feeling comes from my current job, which breaks a decent number of those rules. (S, O, I at least, possibly D but I don't think so) But despite that, code generally seems to be pretty easy to read through, so I'm a bit conflicted.
- AstralStorm 10y ago
  I find SOLID to be less reliable than applying ages old principles of contract-oriented programming. S is matter of taste, you can define it to be "show the whole GUI" or "show a text label in given position". Depending upon abstractions directly is much less reliable than depending upon contract (which is usually not explicit in the abstraction) and preferably also verifying it as both preconditions and postconditions. The other letters are important, though software should be designed for easy modification instead of being closed to it. Otherwise you end up with abstraction forests and deprecated code. Many interfaces is typically a smell, as the developer now has to juggle multiple balls in his head. There is good medium ground out there - making the interface maximize usefulness while not sacrificing too much of Liskov substitution capability is key.

FreezerburnV 10y ago

Can you expand a little about how each of these parts of SOLID have influenced how you have written code? I feel like I've heard people say conflicting things to some degree on at least some of these (e.g.: single responsibility) and my own experience feels somewhat like following some of them to their natural conclusion can end up with code that is more complex and harder to maintain. Again, for example, the S seems to imply needing a larger number of classes that would have to be searched through to find a specific implementation or bug, and D feels like it would shove the code that actually does something down a layer and be harder to find. That could be my inexperience talking or just not knowing how to employ the ideas properly, though. I guess a decent amount of what I'm feeling comes from my current job, which breaks a decent number of those rules. (S, O, I at least, possibly D but I don't think so) But despite that, code generally seems to be pretty easy to read through, so I'm a bit conflicted.

AstralStorm 10y ago
I find SOLID to be less reliable than applying ages old principles of contract-oriented programming. S is matter of taste, you can define it to be "show the whole GUI" or "show a text label in given position". Depending upon abstractions directly is much less reliable than depending upon contract (which is usually not explicit in the abstraction) and preferably also verifying it as both preconditions and postconditions. The other letters are important, though software should be designed for easy modification instead of being closed to it. Otherwise you end up with abstraction forests and deprecated code. Many interfaces is typically a smell, as the developer now has to juggle multiple balls in his head. There is good medium ground out there - making the interface maximize usefulness while not sacrificing too much of Liskov substitution capability is key.