I rarely see inheritance used in practice in java code bases. Except where I would use a union type or sealed class in other languages anyways. I don't feel what youre describing is a real issue.
I know pytest does DI with fixtures, and trying to figure out what you're pulling into a test can be difficult.
The user doesn't write DI code for Django Class Based views. E.g. the view doesn't accept a Database upon instantiation.
If you're writing a few line script, you don't need a DI container. Once your program gets large, it becomes extremely messy without one. It's no surprise projects like [1] exist.
There's nothing wrong with this at all, say:
class MyClass:
def __init__(self, my_dep1=None):
if my_dep1 is None:
self.my_dep1 = get_my_dep1() # Or potentially raise
else:
self.my_dep1 = my_dep1
[...]
def test_my_class():
mocked_dep1 = MagicMock()
my_class = MyClass(my_dep1=mocked_dep1)
[...]There was a talk at PyCon a while back about that patterns commonly used in Java were non-existent in Python.
Any complicated DI solution must have a reason for it being there and I’ve seen too many projects complicating themselves on buzzwords like DI or MSOA without really needing either that much
There are still lots of folks who love 'protected' and deep hierarchies, of course. There is stuff like spring that uses way too many interfaces with a single implementation, doing something a bit off the regular road ends up implementing tons of the said interfaces anew.
However the 'hate' part is mostly the internet (well esp. Hacker news)warrior topic
I strongly suspect that in a few cases some Java devs using net new systems and avoiding common frameworks will perhaps be able to avoid lots of inheritance but I find it insane to say that that's common or even easy.
That seems absurd to me and I have a hard time understanding it, honestly.
However Java doesn’t support type union so you can get into some ugly and verbose situations but the JVM doesn’t really check type so this is more a compile-time issue and could be fixed in a future Java language revision.
Isn't the "sealed interface" described in the OP blog post a type union? Or you mean anonymous unions?
I haven’t written Java in a while and I can’t remember if you could sometimes fake a type union using a generic type on a method, but if you can, it’s definitely super ugly and would raise eyebrows during any code review.
Without some specific call-out, it can be assumed that this is a very niche viewpoint that has no bearing on modern development.
The vast majority of projects use inheritance, today.
Does it use Spring? extends SpringBootServletInitializer
Meaningful responses using values from a request? extends OncePerRequestFilter
Formatting exception handling responses on web requests? extends ResponseEntityExceptionHandler
Then there's all the interfaces you have to satisfy, because it's all tied into the standard library and popular libraries.
I don’t like modern Java because there’s too much non-Java magic code. Layers of stuff that “helps” but removes me from the language. Entire programs written in config and special text wrapping classes and methods. How it works requires understanding multiple intersecting languages that happen to be strung together in .java files.
Edit: when something is in config it’s not checked at compilation. Every environment from dev to prod can have its own config so when you compile in dev you don’t know what’ll happen in prod. I know: let’s add more tools and layers.
That's true of the Java compiler, for which the documentation is strewn around the intenet...but an example is here: https://medium.com/javarevisited/compiler-generated-classes-...
The Java syntax doe not require extending Object explicitly.eg This is a valid, useless, class:
public class App {}
It seems like this is the common path for popular languages. They develop their own library-backed DSL's for the most common use cases, which are often little more than macros (@data @getter, @notnull, etc). I am biased by what I've seen in the last 30 years though.
The OP is complaining about the difficulty of the API because it is _exposed_ through inheritance.
The complaint about `SpringBootServletInitializer`, for example, is exactly this. There's nothing wrong with inheritance. In fact, SpringBootServletInitializer is exactly what you want to use inheritance for - because you need to build your app using the servlet api.
There are http servers that aren't servlet api, such as https://vertx.io/docs/vertx-web/java/#_re_cap_on_vert_x_core... , which uses little to no inheritance (since the api surface is smaller).
Has the java culture move so far the last decade ?
Exactly what I referred to here:
Wide inheritance through mixins is common, though.
https://books.google.co.nz/books?id=Ra9QAAAAMAAJ&q=inheritan...
Why do you think DI is so prevalent in Java codebases? It's a great way of simplifying composition.
The GoF book (Design Patterns) had the same, somewhere early, like in the Introduction, in 1994:
With that said, even the Java EE/Spring complicated word has been moving towards a less inheritance-based future.
Long:
Please make your Point Understandable.