Me: here's the code.

Sr: allright, looks fairly ok. Just change all *FIELD* modifiers to protected rather than private.

Me: what? Why???

Sr: bcz that's the code style we've adopted.

Me: srsly? If so.. Where do you use private fields then?

Sr: nowhere. We use either protected or public so we could extend any class we want

@AndSoWeCode

1. messed up scopes

2. no strict responsibility isolation

3. working with semi-global scoped variables (since when is that a good thing?)

4. ...

How do private fields get in a way?

And what are the positive sides of never-private fields? TBH I can see none. The only non-private fields required in my experience are only statics/constants (public static/public static final). The rest should be encapsulated (i.e. accessed via getters/setters)

This is an honest query.

@AndSoWeCode if your code is used as library and people use the fields directly you'll get a lot of complaints if you decide to refactor the slightest

while in development : *uses protected* in a variable which was supposed to be private but mutable.

while in production : *spends whole day debugging* trying to figure out why 10 external class are modifying it.

Well the same could be applied to global variables :) as long as you documment each and every one of them, they are okay to use, bcz user might want to alter behaviour/fix dev's mistakes himself..

Imho it is a very bad idea., when you buy a tv and it does breaks you do not go for tv docs and try to fix it yourself.. And tv docs do not mention which capacitors can be tangled with and which diodea are not recommended to touch. It was the case some 20 years ago, i know. But we've sort of moved on to hiding component's/product's implementation from the user. And I believe it was a wise, a good change.

I see where you're going with this. However wouldn't it be just safer, simpler and nicer in every possible way to give the 'hacky developer' an ability to implement the same interface as class X does and swap X instance with custom implementation? Or even beter - hide all variables as private, but give an ability to extend class X, override any getter/setter to add custom logic, and swap X with XX? I'm leaning towards a component-based structure so a customer-dev can extend some parts of your machinery easily and wire custom implementations in rather than messing arround with plain variables? Take Spring Framework as an example. It's the most beautiful structure I have seen yet. Developer can easily extend any part of it and autowire just like that. If you see a bug in, say, jparepository, take the interface, build your own implementation and hook it up in the context to be used instead of the default implementation. No need to dig deeper into the default impl any more than u rly need

internal variables depend ONLY to the implementation and are quite likely to change in further releases. This means you will have to remember to adopt your "hack" on each release of the library you are using. Otherwise say hello to undefined behaviour.

Interfaces, however, are there to stay. And even if they change (which should be incredibly rare) -- you will get a compile-time error giving you a heads-up that you need to adopt to the changes.

If the machinery in a lib changes, you will not be tied to some variable which can be used, reused and abused internally, you will not be in danger of breaking the lib more. By using interfaces or overriding public methods of the implementation you bind yourself to the functionality ONLY. Not going places you're not supposed to.

be SOLID :)

At least that's how I see it. Any criticism is welcome - I'm open for discussion :)