5 ms·

(I have been professionally programming Java backends for the past 16 years). Java is not the culprit here. I think it is something that happened on the way t

(I have been professionally programming Java backends for the past 16 years). Java is not the culprit here. I think it is something that happened on the way that has something to do with J2EE and patterns craze we had a decade ago or two ago. It doesn't help that frameworks like Spring and their documentation go out of their way to propagate these boilerplate-heavy patters. Copying these lazy patterns is shortest, easiest way to get to working solution for a person that doesn't want to put any extra effort. And you can't get punished for doing this. Most developers don't even know there exist any other possibilities than mandatory controller calling service calling database layer and hordes of DTOs some people call "model".

andix 5y ago
It's not the fault of the language or the runtime. But some common Java/.NET frameworks nudge you into this direction. Also OOP is very commonly abused in those languages, to make easy stuff more complicated.
- lmilcin 5y ago
  Just because objects are involved doesn't mean it is OOP code... OOP is completely misunderstood especially in Java community to the point where it is pretty difficult to see actually object oriented code. A "service" with a bunch of stateless functions (I am intentionally not calling them methods) is really just a library of routines and the class is used mostly for namespace purposes (to group related functions together) and maybe deliver access to some dependencies. But those dependencies could be thought about almost the same way as global variables in a C program, because usually there exists only single instance of the service. Neither are DTOs being passed between these services an OOP meachanism -- they are almost C-like structs to make it easier to pass data between functions and to have single reference to them. The only exception maybe is things like equals(), hashcode() etc, but this is very shallow use of OOP patterns. So it is really difficult to say this is abuse of OOP, when there is very little of actual OOP in it.
  - andix 5y ago
    The pattern you are describing here (Service classes with static'ish methods together with data classes) is a very functional approach (modules and records). I would consider this much better than "real" OOP. The OOP "abuse" I was referring to is mostly caused by inheritance. Five or more levels of inheritance is not so uncommon in some enterprise business logic. And once you have to work with that, you arrived in hell. Especially if it is split into different projects, that you can't navigate or debug as one easily.
    - tynpeddler 5y ago
      In java 16, they've added record objects to help with this pattern.
moonchrome 5y ago
>Java is not the culprit here. It definitely is the culprit. They didn't even want to add `var` to the language until recently, and let's not even go to the anonymous class vs lambdas retardation. These are just the things that they eventually buckled on, but Java is extremely boilerplatey - the bad patterns and XML crap got invented to deal with that problem. DDD and onion are another issue, mostly coming out of the TDD movement and "make everything unit-testable". If I liked one thing about working with Rails is that they just gave you E2E tests from the start. But if Java/.NET were more flexible (dynamic or FP do far better at enabling simpler unit testing from my experience) mocking would be simpler so the unit testing part would be simpler too.
- discreteevent 5y ago
  The TDD movement came from smalltalk programmers (not that I think it has anything to do with smalltalk, just the programmers came from there). In my experience it was in Ruby and javascript code where I have seen the most inane micro(nano?)-unit tests. Some of this was partly because the unit tests were testing what a static typechecker could verify automatically (at the cost of a little verbosity). I don't see how you figured there is a relationship between DDD and "make everything unit testable". DDD is about high level architecture. It's at the opposite end of the spectrum.
  - mumblemumble 5y ago
    Also, smalltalkers didn't mean the same thing by "unit". What would be called unit tests in one context may mostly be considered integration tests in another. I agree, the crazy mock- and stub-heavy unmaintainable micro unit testing thing seems to have been an innovation that came out of the Ruby scene.
  - moonchrome 5y ago
    Maybe I shouldn't call it TDD camp, but the people that were prothletising TDD were also selling onion/DDD in C# world, so I just bunch those together, it's more about onion, layered architectures, testing at different layers and mocking them, etc. While I consider TDD the wrong approach in 90% of scenarios, in dynamic languages it works out much better because the object model is so flexible you can mock just about anything trivially. In C# and Java it's just boilerplate on top of boilerplate.
serial_dev 5y ago
I'm working on a Dart / Flutter project where most devs are coming from Java and Android backgrounds. For me, coming mostly from JavaScript, TypeScript, and Python, the amount of pointless over-engineering is very frustrating. We need to jam through every change through 10 layers now, because of "clean architecture". The team is very slow and can't implement even small changes quickly. The worst part is that I feel like I'm the idiot for thinking about whether the 50 classes (dtos, models, mappers, blablabla) actually make sense and reduce coupling. I see that anytime a tiny requirement changes, I need to update the 50 classes again, so in practice, it's just doesn't bring anything positive. When I raise my concerns, they just roll their eyes, and make me feel like "I'm just not a senior enough guy" who just accidently got in the team.
- lmilcin 5y ago
  I feel your pain, I am in much the same situation just in a tech lead position. It takes a lot of patience to undo this damage and explain that simplicity is much more important than lazily, mindlessly repeating "best" practices. I am using quotes intentionally because they aren't actually best -- "best" would suggest there are no better practices which obviously cannot be true. The goal should always be to make the application simple and easy to work with. Patterns should be tools to achieve the goal rather than being goals themselves. Simple is important because it allows understanding your application (which is important for developer efficiency as well as improving reliability). It also enables you to modify your application much more easily (more code usually means more work to change it) and this is important to fighting technical debts and to reduce cost of any future development.
- datameta 5y ago
  > When I raise my concerns, they just roll their eyes, and make me feel like "I'm just not a senior enough guy" who just accidently got in the team. Easier to do that than just admit technical dept. Some people cannot acknowledge a problem and live alongside it if it is too large to tackle immediately. It has to be explained away or compartmentalized. How simple it is blame the messenger. Sorry you had to experience that from your team.
- andix 5y ago

andix 5y ago

It's not the fault of the language or the runtime. But some common Java/.NET frameworks nudge you into this direction. Also OOP is very commonly abused in those languages, to make easy stuff more complicated.

lmilcin 5y ago
Just because objects are involved doesn't mean it is OOP code... OOP is completely misunderstood especially in Java community to the point where it is pretty difficult to see actually object oriented code. A "service" with a bunch of stateless functions (I am intentionally not calling them methods) is really just a library of routines and the class is used mostly for namespace purposes (to group related functions together) and maybe deliver access to some dependencies. But those dependencies could be thought about almost the same way as global variables in a C program, because usually there exists only single instance of the service. Neither are DTOs being passed between these services an OOP meachanism -- they are almost C-like structs to make it easier to pass data between functions and to have single reference to them. The only exception maybe is things like equals(), hashcode() etc, but this is very shallow use of OOP patterns. So it is really difficult to say this is abuse of OOP, when there is very little of actual OOP in it.
- andix 5y ago
  The pattern you are describing here (Service classes with static'ish methods together with data classes) is a very functional approach (modules and records). I would consider this much better than "real" OOP. The OOP "abuse" I was referring to is mostly caused by inheritance. Five or more levels of inheritance is not so uncommon in some enterprise business logic. And once you have to work with that, you arrived in hell. Especially if it is split into different projects, that you can't navigate or debug as one easily.
  - tynpeddler 5y ago
    In java 16, they've added record objects to help with this pattern.

moonchrome 5y ago

>Java is not the culprit here. It definitely is the culprit. They didn't even want to add `var` to the language until recently, and let's not even go to the anonymous class vs lambdas retardation. These are just the things that they eventually buckled on, but Java is extremely boilerplatey - the bad patterns and XML crap got invented to deal with that problem. DDD and onion are another issue, mostly coming out of the TDD movement and "make everything unit-testable". If I liked one thing about working with Rails is that they just gave you E2E tests from the start. But if Java/.NET were more flexible (dynamic or FP do far better at enabling simpler unit testing from my experience) mocking would be simpler so the unit testing part would be simpler too.

discreteevent 5y ago
The TDD movement came from smalltalk programmers (not that I think it has anything to do with smalltalk, just the programmers came from there). In my experience it was in Ruby and javascript code where I have seen the most inane micro(nano?)-unit tests. Some of this was partly because the unit tests were testing what a static typechecker could verify automatically (at the cost of a little verbosity). I don't see how you figured there is a relationship between DDD and "make everything unit testable". DDD is about high level architecture. It's at the opposite end of the spectrum.
- mumblemumble 5y ago
  Also, smalltalkers didn't mean the same thing by "unit". What would be called unit tests in one context may mostly be considered integration tests in another. I agree, the crazy mock- and stub-heavy unmaintainable micro unit testing thing seems to have been an innovation that came out of the Ruby scene.
- moonchrome 5y ago
  Maybe I shouldn't call it TDD camp, but the people that were prothletising TDD were also selling onion/DDD in C# world, so I just bunch those together, it's more about onion, layered architectures, testing at different layers and mocking them, etc. While I consider TDD the wrong approach in 90% of scenarios, in dynamic languages it works out much better because the object model is so flexible you can mock just about anything trivially. In C# and Java it's just boilerplate on top of boilerplate.

serial_dev 5y ago

I'm working on a Dart / Flutter project where most devs are coming from Java and Android backgrounds. For me, coming mostly from JavaScript, TypeScript, and Python, the amount of pointless over-engineering is very frustrating. We need to jam through every change through 10 layers now, because of "clean architecture". The team is very slow and can't implement even small changes quickly. The worst part is that I feel like I'm the idiot for thinking about whether the 50 classes (dtos, models, mappers, blablabla) actually make sense and reduce coupling. I see that anytime a tiny requirement changes, I need to update the 50 classes again, so in practice, it's just doesn't bring anything positive. When I raise my concerns, they just roll their eyes, and make me feel like "I'm just not a senior enough guy" who just accidently got in the team.

lmilcin 5y ago
I feel your pain, I am in much the same situation just in a tech lead position. It takes a lot of patience to undo this damage and explain that simplicity is much more important than lazily, mindlessly repeating "best" practices. I am using quotes intentionally because they aren't actually best -- "best" would suggest there are no better practices which obviously cannot be true. The goal should always be to make the application simple and easy to work with. Patterns should be tools to achieve the goal rather than being goals themselves. Simple is important because it allows understanding your application (which is important for developer efficiency as well as improving reliability). It also enables you to modify your application much more easily (more code usually means more work to change it) and this is important to fighting technical debts and to reduce cost of any future development.
datameta 5y ago
> When I raise my concerns, they just roll their eyes, and make me feel like "I'm just not a senior enough guy" who just accidently got in the team. Easier to do that than just admit technical dept. Some people cannot acknowledge a problem and live alongside it if it is too large to tackle immediately. It has to be explained away or compartmentalized. How simple it is blame the messenger. Sorry you had to experience that from your team.
andix 5y ago