Why does the language change when demonstating what "modern" solid is. Changing the language also changes a bunch of properties independant of what they are trying to show solid is, unless they are saying you need to use javascript to do modern solid.
Sorry if this was unclear - the article was mainly trying to show that the basic ideas behind SOLID could be used in other, non-OO languages. The original SOLID still works just fine and hasn't changed much in Java, from what I can tell.
The way before and after hooks are applied seems pretty terrible. Imagine doing this everywhere. It's also not a pattern I've ever seen in any FP codebase.
If you need to do something before or after you could just, you know, do it from the callers side. Or wrap the original thing in a new thing which does this. If the only way of composing things is by passing increasingly elaborate callbacks around (have fun with error handling, return early, and so on, from these functions) then I think you really missed a good abstraction level in your code.
Lastly, dependency inversion is actually a pretty big topic in FP languages, especially since they often experiment with effect systems. It's a shame that this paragraph read so anemic.
Honestly this article is exactly the kind of shallow content I've come to expect from this blog.
I'm definitely not an expert in FP! The hook method is one I've seen used here and there, but higher-order functions is definitely more common. In retrospect I should have put more emphasis on that.
Can you point to some good articles on dependency inversion in FP?
Hexagonal architecture helps much more than SOLID helps.
Applying hexagonal results in SOLID code with much less burden. Why?
Because SOLID is all about the S and the S is much easier to grasp in hexagonal then it is in theory.
Moreover how can one achieve the S but not the OLID? How can one achoive the O without the LID? It probably takes a lot of effort but they are all very imterconnected.
6 comments
[ 2.7 ms ] story [ 27.2 ms ] threadCan I do "modern" solid in Java or C# ?
If you need to do something before or after you could just, you know, do it from the callers side. Or wrap the original thing in a new thing which does this. If the only way of composing things is by passing increasingly elaborate callbacks around (have fun with error handling, return early, and so on, from these functions) then I think you really missed a good abstraction level in your code.
Lastly, dependency inversion is actually a pretty big topic in FP languages, especially since they often experiment with effect systems. It's a shame that this paragraph read so anemic.
Honestly this article is exactly the kind of shallow content I've come to expect from this blog.
Can you point to some good articles on dependency inversion in FP?