Follow

has four different access modifiers: public, private, protected and default.

When choosing which to use always start from the most restrictive and move to the most permissive.

Don't just make everything public. Especially if you are creating libraries.

· · Web · 1 · 1 · 3

@deshipu if you ship libraries, each time you change the signature of a public method or remove it completely you introduce a breaking change.

That means you need to step a major version each time.

And that makes no sense if the end-user was never even supposed to use that method in the first place.

@igorski I don't really see the connection.

First of all, not every project is a library. Second, not every library follows semantic versioning. And third, you only need to bump the version when changing the documented API of your library, which has no relation with the internal access modifiers of your implementation.

@deshipu I would recommend a good book on object-oriented design in that case.

From what I've gathered in my career, proper usage of access modifiers has NOTHING to do with style and everything to do with design. Which needs to be intentional.

On another note, when you add new functionality in a backwards-compatible way (make a method public) you bump the minor, not the major version.

@igorski It has nothing to do with design. You can have exactly the same design with all the access set to public, and it will all work exactly the same. All those modifiers do is making it harder to change the design, because then you have to explicitly change the modifiers first. It's called knock-on viscosity, and it may be useful to discourage bad practices, but does nothing if you already avoid them.

Minor or major version (again, not all projects use semantic versioning), you still have to bump it.

@deshipu it can work the same but have a completely different design. The fact that "it works" tells you nothing about the design.

Btw, there is a huge difference between stepping a minor and a major version. You can just say "stepping is stepping".

semver.org

@igorski It will have exactly the same design, to the point of exactly the same code getting executed. If you don't believe me, just try it: take any of your code, and replace all access modifiers with public. It will still have exactly the same architecture, the same dependencies between the parts, the same structure. You have just removed some velvet ropes that were to supposed to restrain you, but as long as you don't stray outside the lines, there is no difference.

@igorski Semantic versioning is not the only way to do versioning, and in fact if you are doing semantic versioning without doing full integration testing, you are just lying to the users — because you never know if your next version actually breaks the backward compatibility and should increase the major version, or doesn't and should just increase the minor. Most projects can't afford doing such testing, and should not mislead their users by pretending to use semantic versioning.

@igorski @deshipu Interesting discussion. I've always followed this practice because it was how I was taught, but I think I mainly like it because I like to keep things extremely organized for myself. I like to break methods down as small as possible I don't want to see methods that I shouldn't in the wrong context and probably confuse myself.

@emartin @igorski It's a valid programming style, and it's especially good when you are implementing something that has been well planned in advance, so there are few surprises and not much refactoring.

But I think it's important to remember that it's only one possible style, and there are others that may have other advantages, especially at the beginning of the project, when the structure is not yet as developed. Remember that changing a method from private to public also requires you to bump the version.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!