3 ms·
Pretty good takes here in the comments (shout out to references to "pit of success") There are two things worth mentioning, though. 1) the best pragmatic prog
by wrsh07 6y ago
Pretty good takes here in the comments (shout out to references to "pit of success")
There are two things worth mentioning, though.
1) the best pragmatic programming recommendation is "semantic compression" by Muratori [1]. Incidentally, I find it to be an effective "takedown" of the sort of dogmatic oop that anyone criticizing oop is criticizing
2) Muratori might disagree with this, but for me the whole point of a new class (type) is new invariants [2]. If you need a new invariant, you make a new type. Sticking to this principle has helped me keep classes small and focused without really thinking about other things like "single responsibility". There are a few exceptions (eg you might need a new type to work with a particularly clunky API, like some Map Reduce ones), but it's really that simple.
As a bit of an aside, the worst code I have written hasn't been purely OO nor purely functional. It's been when I've mistakenly tried to add new ideas to existing code that break the paradigm.
[1] https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015
[2] https://en.m.wikipedia.org/wiki/Class_invariant https://en.m.wikipedia.org/wiki/Class_invariant
- mrkeen 6y ago> If you need a new invariant, you make a new type. Agreed, but is that OO? From [2]: > Class invariants are established during construction and constantly maintained between calls to public methods. Code within functions may break invariants as long as the invariants are restored before a public function ends. That just sounds like a race condition with extra steps.
- wrsh07 6y agoI think you can use OO effectively to define invariants. (You could also do this with FP!) Beyond that, I'm not sure I understand your question.
- GordonS 6y agoI enjoyed reading Muratori's blog post you linked to - it's interesting to read the thought processes of a dev who writes so well. But I don't get how "semantic compression" is any different from the more commonly termed DRY (Don't Repeat Yourself)?
- wrsh07 6y agoI think DRY is a goal for the code and semantic compression (as described in the post) is a path towards that goal. In Muratori's world they're following best practices like YAGNI and DRY and that allows you to refactor code at the right time