5 ms·

>That said, if you go for functional style in OOP, i.e. shoving as much as you can into static helper functions and most of the rest into dumb private stateless

>That said, if you go for functional style in OOP, i.e. shoving as much as you can into static helper functions and most of the rest into dumb private stateless functions, you suddenly gain both a clean architecture and lots of test points to use in unit tests. So you can have testable code, but you have to chill out with the OOP thing a bit. Wow, this is exactely totally opposite of how one can achieve testability in OOP! For more details I recommend excellent Misko Hevery's article "Static Methods are Death to Testability" [1]. Also, I'd argue that "functional style in OOP" is an oxymoron - you're either OO or something else (functional, imperative...) [1] http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/ http://misko.hevery.com/2008/12/15/static-methods-are-death-...

majewsky 9y ago
I'm not sure if this article is clever satire. > The basic issue with static methods is they are procedural code. So is any object-oriented code. OOP is a subparadigm of procedural programming. > Unit-testing needs seams, seams is where we prevent the execution of normal code path and is how we achieve isolation of the class under test. seams work through polymorphism, we override/implement class/interface and than wire the class under test differently in order to take control of the execution flow. With static methods there is nothing to override. Why did it not occur to him that the function boundary is the "seam" he's trying to find? I mean, `method(a, b)` is equivalent (as in: equally expressive, and usually implemented in the same way) as `a.method(b)`. Therefore, any problems with one case equally apply to the other case. If his problem is that `method(a, b)` may call other, non-mockable functions, then that criticism equally applies to `a.method(b)`. (As I'm writing this, it occurs to me that the author may be suffering from the "OOP = Java" delusion.)
- andrewaylett 9y ago
  The OOP = Java trap is all too common, but the converse is also a trap: just because you've written OOP code in a different environment doesn't mean that pattern will work in Java. Go with what the ecosystem supports, and you'll find your tooling helps you a lot more than if you fight against it by trying to force non-idiomatic structures. Your colleagues will appreciate it, too.
profalseidol 9y ago
He probably meant no-side-effect static functions. I myself find using these a lot. For common CRUD web apps, you have Spring doing most of the stuff for you and you simply need to write stateless methods. However, for not-common requirements, you might need to use classes and OOP patterns to implement a complex logic.
- TeMPOraL 9y ago
  I did. I even wrote the magic word a moment later, but forgot it there, and realized only past the edit window.
bpicolo 9y ago
It seems the encouraged method is IoC these days, and that's just dreadful. IoC/Dependency resolution all over make it insanely hard to reason about code without running circles through the codebase. For me, IoC seems invented almost entirely to make up for how difficult testing can be in particular languages. Which, sure, making up for shortcomings as good, but the necessity to use IoC for it feels bad.
- GordonS 9y ago
  This is how I felt about IoC as a junior dev 15 years ago, before I'd actually used it myself. Nowadays the benefits are clear to me: more modular, testable code, and also lifecycle management. Give it a try, you may well change your views.
  - bpicolo 9y ago
    I've used it a fair deal. I've found I prefer languages that don't require IoC to make code testable. I agree that it's one of the sanest options when it's required, I just think that language design should incorporate testing ergonomics from the start.

majewsky 9y ago

I'm not sure if this article is clever satire. > The basic issue with static methods is they are procedural code. So is any object-oriented code. OOP is a subparadigm of procedural programming. > Unit-testing needs seams, seams is where we prevent the execution of normal code path and is how we achieve isolation of the class under test. seams work through polymorphism, we override/implement class/interface and than wire the class under test differently in order to take control of the execution flow. With static methods there is nothing to override. Why did it not occur to him that the function boundary is the "seam" he's trying to find? I mean, `method(a, b)` is equivalent (as in: equally expressive, and usually implemented in the same way) as `a.method(b)`. Therefore, any problems with one case equally apply to the other case. If his problem is that `method(a, b)` may call other, non-mockable functions, then that criticism equally applies to `a.method(b)`. (As I'm writing this, it occurs to me that the author may be suffering from the "OOP = Java" delusion.)

andrewaylett 9y ago
The OOP = Java trap is all too common, but the converse is also a trap: just because you've written OOP code in a different environment doesn't mean that pattern will work in Java. Go with what the ecosystem supports, and you'll find your tooling helps you a lot more than if you fight against it by trying to force non-idiomatic structures. Your colleagues will appreciate it, too.

profalseidol 9y ago

He probably meant no-side-effect static functions. I myself find using these a lot. For common CRUD web apps, you have Spring doing most of the stuff for you and you simply need to write stateless methods. However, for not-common requirements, you might need to use classes and OOP patterns to implement a complex logic.

TeMPOraL 9y ago
I did. I even wrote the magic word a moment later, but forgot it there, and realized only past the edit window.

bpicolo 9y ago

It seems the encouraged method is IoC these days, and that's just dreadful. IoC/Dependency resolution all over make it insanely hard to reason about code without running circles through the codebase. For me, IoC seems invented almost entirely to make up for how difficult testing can be in particular languages. Which, sure, making up for shortcomings as good, but the necessity to use IoC for it feels bad.

GordonS 9y ago
This is how I felt about IoC as a junior dev 15 years ago, before I'd actually used it myself. Nowadays the benefits are clear to me: more modular, testable code, and also lifecycle management. Give it a try, you may well change your views.
- bpicolo 9y ago
  I've used it a fair deal. I've found I prefer languages that don't require IoC to make code testable. I agree that it's one of the sanest options when it's required, I just think that language design should incorporate testing ergonomics from the start.