Returning to Java (and Kotlin) development after a couple of months of Go development, [...] I discovered the value of a certain sort of "plain speaking" in code.
This resonates with me. I've spent 1 year+ in each of C, C++, C#, PHP, Java, Python, and JS. There are obvious benefits to taking advantage of a platform's strengths, but the "plain" code has merits too. Easier to reason about, often more maintainable, faster to ramp up new team members, etc.
Simpler code almost always wins. Predicting the future is hard, refactoring simple code that does the minimum it needs to is comparatively easy. Don't write what-if code, YAGNI.
Furthermore, when opening a new project you can just read through the interfaces quickly and get a good idea of what the code is doing. You can't just read thru a whole bunch of implementations and get as good of an idea.
If the implementation doesn't provide more methods than the interface (a transparent class in GoF terminology) you should not name it.
In Java, the implementation is usually created inside a static method (a static factory) of the interface as a lambda or an anonymous class.
Again, moot point if there's only one implementation.
> If the implementation doesn't provide more methods than the interface (a transparent class in GoF terminology) you should not name it.
> In Java, the implementation is usually created inside a static method (a static factory) of the interface as a lambda or an anonymous class.
And how's that not needlessly convoluted and ugly? You're illustrating guitarbill's point about applying design patterns blindly.
I do acknowledge that XImpl is kinda ugly as name.
Until you cast the object...
You should use truly immutable data types unless you specifically need otherwise, most modern languages and libraries encourage you to do so.
Now, you can be good at planning ahead and know what the abstraction should be in many cases. This is still much rarer than all cases. Indiscriminately creating an interface for every class means you're probably not giving the interface much thought.
I strongly agree with this point.
I speculate that some people tend to add unnecessary code because they are thinking of all those well-written libraries they use every day, which have evolved to support multiple uses, including the uses that clearly they don't need but they can see are useful to others. Therefore they conclude good software must add features that are useful for other coders!
I strongly agree ! At my current company we are ramping up the team and want to go from 4 very senior engineers to 35. The very complex architecture based on functional programming that we are using will probably be a major hindrance here.
I don't understand your remark on interfaces though. I tend to have many, even for one click method. If I want to have a callback for a list item tap, I create an interface for that very specific item, that way it is very easy to decouple view and business and it also is extremely easy to debug in Intellij. In one click I get from the interface declaration in the viez to it's implemenentation in the business logic.
Why does it hinder debugging in your use case ?
Examples of things that C# has over Java:
- Operator overloading: .Add() is really not that much more annoying to write...
- Properties: Shorthand for getters and setters, because auto-completion isn't a feature in IDEs since forever. And, like Java, they've introduced lambdas, but have then also changed the automated code generation of Properties in their IDEs to use lambdas, because apparently even an IDE needs to be lazy and give junior devs a harder time.
- The out-keyword: Somewhat formalized way of passing along a variable to have it populated via side effects by a method. In Java, you'd refactor your code to not need two return values, or you'd return an object with those values in class variables (or you'd just do this dirty side effect method without telling anyone).
[0] Bit like Python: https://docs.microsoft.com/en-us/dotnet/api/system.tuple?vie...