4 ms·
If you've got some great conceptual framework for thinking about code quality that doesn't include coupling and cohesion or some equivalent ideas, please, share
by aaronbwebber 10y ago
If you've got some great conceptual framework for thinking about code quality that doesn't include coupling and cohesion or some equivalent ideas, please, share it with us all. I'm not holding my breath thought. The reason we keep talking about coupling and cohesion is that these are useful concepts that can be fairly directly applied to most day-to-day software design problems.
This was a nice, fairly short post about how to apply some generally accepted principles of good software design in a specific language. It's a worthwhile read for anyone relatively new to Go programming.
- akkartik 10y agoI do, but I don't want to shamelessly plug here. My point was not that these ideas are bad. My point was that they are incomplete, and pointing at them as reasons why a new language is so great is absurd -- when in fact Java supports them just as well. I think Go is great, but I think it's great because it gets a large number of details slightly more right than the languages of the previous decade. And it will make its mistakes that languages of the next decade will learn from. SOLID is just the bare minimum ante here. Bragging about SOLID is like bragging that your language supports all kinds of data structures.
- papaf 10y agoI am not against thinking in terms of coupling and cohesion but I found the following different and interesting ways to think about separating software: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries http://shaffner.us/cs/papers/tarpit.pdf http://shaffner.us/cs/papers/tarpit.pdf The common theme in both these viewpoints is that the biggest enemy is state, and who is responsible for it, rather than just responsibility on its own.