21–30 of 35 posts
If you are writing software that others will use in a variety of ways, consider following SOLID principles as empathetic programming.
I like to work together with open-minded smart people. Stuff like SOLID only matters if you don't.
Not every team gets to be made of 100% 10x supergenius ninja rock gods. And no one gets to be at their absolute best for every line of code they're ever going to write. Everyone, no matter how gifted, does a better job on average if the boring, obvious thing also tends to be the correct thing. Having some structure makes doing real work with real humans better, not worse.
SOLID isn't an iron law, it's a heuristic. And a damn good one. "Open-minded smart people" can and will find reasons to bend and break the rule sometimes, and the more experienced one becomes the more readily they'll be able to see when the rules doesn't apply. That doesn't mean they're bad rules.
Maybe I'm not open minded or smart enough, but I've seen plenty of codebases that adhered to some set of coherent architectural guidelines and codebases that didn't, and I know which subset I prefer to work on.
I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas. S -> don’t write spagetti code. O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality. L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’…
>Dependency inversion to make things testable Dependency inversion makes things unit testable. >testing is good right? All other things being equal, wouldn't a form of testing that doesn't require rearchitecting your code be better than one that doesn't?
I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas. S -> don’t write spagetti code. O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality. L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’…
Earlier quoted context omitted.
>Dependency inversion to make things testable Dependency inversion makes things unit testable. >testing is good right? All other things being equal, wouldn't a form of testing that doesn't require rearchitecting your code be better than one that doesn't?
Rearchitecting sure, but when designing a code base from scratch, designing for DI is not a bad approach.
I think you have to weigh up the relative merits of having less code vs. having a lower cost of code change. Furthermore, following YAGNI dictates that you shouldn't really do DI until you actually do need it.
I think doing it to facilitate unit testing is a universally bad approach, and a code smell that indicates that what you really wanted was an integration test.
I like to work together with open-minded smart people. Stuff like SOLID only matters if you don't.
Oh, come off it. Not every team gets to be made of 100% 10x supergenius ninja rock gods. And no one gets to be at their absolute best for every line of code they're ever going to write. Everyone, no matter how gifted, does a better job on average if the boring, obvious thing also tends to be the correct thing. Having some structure makes doing real work with real humans better, not worse. SOLID isn't an iron law, it'…
Earlier quoted context omitted.
> Sure, mega-interfaces are bad... I guess... but so are objects with massive sets of methods on them. Why the special focus on interfaces? Its not a special focus; the SRP is a bigger deal and focuses on objects. OTOH, violations of the ISP force violations of the SRP, because an interface with unnecessary methods means that objects which must implement the interface will be forced to have unnecessary methods. Screw…
Concrete example: Many languages's standard libraries have stuck methods for mutation into the base interface for collections of objects. This makes it awkward (at best) to try and use immutable collections. Either you create your own base interface, which makes you incompatible with the rest of the standard library, or you inherit the standard interface and then do something like throw an exception when someone atte…
Earlier quoted context omitted.
Concrete example: Many languages's standard libraries have stuck methods for mutation into the base interface for collections of objects. This makes it awkward (at best) to try and use immutable collections. Either you create your own base interface, which makes you incompatible with the rest of the standard library, or you inherit the standard interface and then do something like throw an exception when someone atte…
Exactly the example I've written in my other comment... I guess many people have been bitten by this!
I feel like it's actually just about the least painful in C#, since pretty much every collection interface derives from IEnumerable. It doesn't define have methods for random access or getting the size of the collection, but it is at least immutable, so you can get away with using it quite a bit, maybe even most of the time.
In Java, on the other hand. . . woof.
I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas. S -> don’t write spagetti code. O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality. L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’…
I don't think the push is for 1 method interfaces. In C#, a good example is that many many APIs use the IList interface to pass lists around. But that interface contains methods like .Add .Remove .RemoveAt .Insert... So while in most cases, you'd be just fine passing a IReadOnlyList , using the IList interface means that as a user of the API, you have to implement these methods which may have no sense for what you're…
Why would the class implement these methods if they aren't even public?
Also, aren't statically typed languages like c# meant to reduce run-time errors by catching them during compilation? Wouldn't throwing exceptions from unimplemented methods from interfaces frequently break this idea?
Earlier quoted context omitted.
I don't think the push is for 1 method interfaces. In C#, a good example is that many many APIs use the IList interface to pass lists around. But that interface contains methods like .Add .Remove .RemoveAt .Insert... So while in most cases, you'd be just fine passing a IReadOnlyList , using the IList interface means that as a user of the API, you have to implement these methods which may have no sense for what you're…
Wow, the ReadOnlyList really does implement all methods of the IList interface. That's just ridiculous, %50 of the methods on the class throw an exception! Why would the class implement these methods if they aren't even public? Also, aren't statically typed languages like c# meant to reduce run-time errors by catching them during compilation? Wouldn't throwing exceptions from unimplemented methods from interfaces fre…
Now if you read carefully you actually do need to jump through some hoops in order to get an exception.
First of all the methods aren't public, you need to explicitly convert the ReadOnlyCollectionto to an IList or ICollection to access them.
Secondly the dependency inversion principle requires that any ReadOnlyCollection is stored as an IReadOnlyList or some other appropriate interface, there should be no way to convert it to an IList accidentally.
And finally the ReadOnlyCollections seems to be designed for the very specific scenario where you can't solve things using interfaces and need to design a class that supports IList, but throws an exception when it is modified. In all other cases you should use something else.