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

Sounds legit

Why use private members anyway? Most of the time they just get in the way rather than solve any particular problem.

@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.

@netikras

Just make everything public. If you don't want to mess up suggestions in the IDE and it doesn't impair unit tests, make them protected. With protected members people could at least fix your stupid mistakes without having to decompile/recompile the code or begging for access to your private repository to fix it upstream. And all of us make stupid mistakes, there's no use in denying that.

With private members you're limiting the abilities to use your code, by the same things like unit tests.

As for encapsulation - you can encapsulate public members as well, as long as you define it very well in documentation or comments, that usage of encapsulated members is strongly discouraged.

Because, depending on software, I WILL STILL MAKE USE of the private members if I have to. The problem is whether you want that to end up being a 1 line simple code that everyone understands, or a clusterfuck of 100 lines of reflection and hacky bullshit that will definitely break later.

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.

@netikras the problems with global variables is that they get modified in whatever scope you can imagine, and there's no way to separate them into scopes.

A class member will be owned by a class only. So as long as you ask to only use accessors and not value members directly, in 1 line of documentation at the very start, you're fine.

Crappy developers that do not read that one single bold line will screw up. Developers that do read, will use the getters and setters, and work with otherwise the methods that handle those members. HOWEVER if they do need to do some hacky stuff with that library, they can, without extra bullcrap.

And trust me, I've fixed a ton of bugs this way, because it was either closed source, or the maintainer didn't accept my pull request because he disappeared from the face of the planet and comes back once a year.

The TV example is a bad one. They just went to cheap prefabs and miniaturization.

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 :)