Apparently he replaces null with null objects or throwing exceptions, and creates objects for every static method. Go figure.
Actually, there are a few gems:
> The Map interface (no offense to its authors) has a design flaw.
> It is a good practice to make your code as fragile as possible, letting it break when necessary.
> The method is basically asking the object about its… race. Black objects go right while white objects go left. That’s what this instanceof is doing, and that’s what discrimination is all about.
That's what Optional was introduced for in Java 8. If you want to be absolutely null-safe, using it makes sense. But if you want to optimise performance, going with the slightly more risky route is still the better choice.
It was mostly just meant to cover the zero or one case on fluent-style interfaces like the Streams API, so check as getFirst() or getAny(). In hindsight, the name Optional was a poor choice if they didn't want the idiom coming over.
I don't understand why the names are so bad. FtFoo, TkBar, XyBaz. Not pronounceable, meaning not inferable. I like Yegor's stuff mostly, but the naming just kills me.
Not trying to knock the work, but why is no static methods a selling point? How does one do utility classes instead? And do you eschew static factory methods entirely?
Yegor has quite orthodox view on Java development. You might want to read his blog to get better understanding on his position. While I don't agree with many of his points, it's a very interesting and refreshing perspective that is useful to learn IMO.
"Native"? "At home"? "Happy Commoner in the Kingdom of Nouns[0]"? Or stockholm syndrome... I kind of get on "no static methods! 'util' and 'helper' are smells!" bends myself from time to time in order to make designs clearer and unit testing somewhat saner (because the even more sane approach of writing or refactoring to smaller pure functions and keeping them that way is too much to ask for sometimes) but it's all just because I spend too much time working in an insane language with a broken idea of what OOP is. Still, I appreciate write-ups like the author's, and at least he's right about immutability being good in general.
Because static methods/variables/things are hard to test code with because they're hard to replace. IME getting rid of static is the wrong solution though, the difficulty is only because of a limitation of current languages, unit test frameworks and build systems. If you can inject your substitutes at compile time (which I think you should be able to do at the test link step with java) then static isn't a problem.
There's also the issue of people seeing OO as the goal not the tool, which I think might be the case here too.
I write very annotation/static method heavy Java at work, and I write Haskell for fun at home, and my kneejerk reaction to seeing this code in the "Why are static methods bad" link:
void transform(File in, File out) {
Collection<String> src = new Trimmed(
new FileLines(new UnicodeFile(in))
);
Collection<String> dest = new FileLines(
new UnicodeFile(out)
);
dest.addAll(src);
}
I was reminded of golang as well. I kind of like this framework, because I dislike the overly magic dispatch mechanisms of annotation-driven java. Basic request dispatching in golang can look and be clunky, but that one clunky place tells you where to look.
Unknown if this framework adheres to it, but the JavaEE standard allows one to deploy apps that don't contain a main method, and in fact can run in a security restricted environment that prohibits reading properties, environment variables, and a lot more. So that's a long way of saying that if it doesn't need a main method unless they're trying to deploy their own webserver, too
I think it's safe to assume "no public static interface to the framework". The rest are hidden implementation details.
It's like saying that a program in Java can be completely object oriented. Of course it can't because the innards still contain pieces of procedural code and they still use primitives which may not be actual instances of objects. What counts is how it presents itself on the outside.
https://www.yegor256.com/2014/05/13/why-null-is-bad.html
https://www.yegor256.com/2014/05/05/oop-alternative-to-utili...
Apparently he replaces null with null objects or throwing exceptions, and creates objects for every static method. Go figure.
Actually, there are a few gems:
> The Map interface (no offense to its authors) has a design flaw.
> It is a good practice to make your code as fragile as possible, letting it break when necessary.
> The method is basically asking the object about its… race. Black objects go right while white objects go left. That’s what this instanceof is doing, and that’s what discrimination is all about.