|
|
|
|
|
|
by goostavos
1910 days ago
|
|
|
>why not make them public in the first place? If you're in an old school "OOP" style java codebase, where each class is its own little island of encapsulated state and behavior, the coupling of the two means that strictly controlling access via getters is usually required. Even in more "modern" java, where you do most of your programing against plain data, having Lombok attach getters still gives you some quality of Life benefits because you can use method reference rather than anonymous functions for high-order access (e.g. `things.map(MyClass::getName)` rather than `things.map(myclass -> myclass.name)`) I'm with you on mixed Lombok feelings, though. It's great right up until its not. It fails or doesn't work in really unexpected or weird ways, and is the source endless pain when you've got other annotation based things (like dagger) which then imposes annotation processing order failures. |
|
|
That I agree. My comment was meant to be cheeky a little bit as it is actually pretty difficult to find trully OOP application, at least in area of backend apps I am working in.
Obviously, in OOP you are not supposed to expose your internal state but rather accept messages to run behaviour.
If you are working on a truly OOP application then Lombok is useless. Your public class interface is all that matters then and you would spend more time fighting Lombok than just writing it manually.
Lombok is only good at automating boilerplate which, if you have a lot of, is a sign of some other problem.
> It's great right up until its not. It fails or doesn't work in really unexpected or weird ways
That is exactly the point. Magic is fun until you find out that it leaks horribly and causes unintended side effects with all sorts of stuff.
What's the point of replacing simple problem (just really use templating mechanism you have in your IDE) with complex problem (dealing with magic failing on you).