What's the use of private?

[Lew]

- don't make everything private and final, you may regret it later

Unless you tend to use composition over inheritance. Inheritance tends to be
overused.

The "design by contract" approach tends to reduce the kind of errors you're
talking about. If the contract of the class is clear, and the designer wants
to restrict extension, that's the designer's choice. It isn't a mistake
because someone else wants to extend it and is frustrated that they cannot get
at the internals. It was the designer's intention to frustrate that attempt;
if anything the fact that the would-be extender gripes is ratification that
the API designer did their job correctly.

 

[Mike Schilling]

There's no disagreement here: it is my opinion too, and I stated it,
that variables had better, as a rule, be kept private. This means
manipulating the more important of them through getters and
setters, implicitly.
A word, however, on this recurring reference to "rearranging" the
workings of a class. It might be one occasionally has to rearrange
private variables and how they're used. That's a good reason to keep
them private to begin with. But the overall contract of a class is
something that never ought to have to be changed.

Exactly. That's why the bits of implementation that you don't want to
make part of the contract should be marked private or perhaps
package-private.

 

[Daniel Pitts]

Exactly. That's why the bits of implementation that you don't want to
make part of the contract should be marked private or perhaps
package-private.

Right, and my only point is that includes ALL implementation details
that you don't want exposed. There is a good reason to make a lot of
methods private. I once heard (not sure if I agree with it) that
private methods needn't be as concerned with invariants. Pre-conditions
and post-conditions should be met by public methods, but private methods
may leave things hanging. Think fragments of a process.

Anyway, I haven't given that enough thought to whole-heartedly endorse
it, but it sounds reasonable anyway.

 

[jrobinss]

Unless you tend to use composition over inheritance. Inheritance tends to be
overused.

I wholeheartedly agree, of course. With both sentences.
However, your correction is for "final", not for "private".

The "design by contract" approach tends to reduce the kind of errors you're
talking about. If the contract of the class is clear, and the designer wants
to restrict extension, that's the designer's choice. It isn't a mistake
because someone else wants to extend it and is frustrated that they cannot get
at the internals. It was the designer's intention to frustrate that attempt;
if anything the fact that the would-be extender gripes is ratification that
the API designer did their job correctly.

As I said in my previous post, if the design is flawless, the
accessibility is generally obvious. However, code lives, and having
lived, lives some more. And most of the designs I deal with are large
systems with stuff added when it was needed, resulting in unforeseen
evolution of the code.

Additionally, this may vary with examples, but I maintain that it's
more efficient, or generous, whatever, to write a class as a new tool
for your ever-growing kit than as a tailored solution to a precise
problem. Of course, it's not a very accurate remark without any
example, but this is how I prefer to imagine the perfect OO coder. I
prefer to wonder why to restrict access instead of why to enable it.

However I think Patricia provides a very useful insight, by comparing
two evils. In essence, she's saying that over-protected classes are
easily corrected, which is true, when modification of uselessly over-
displayed stuff is tricky at best.
Only thing missing from her reasoning, if you read my (longish) post,
is that I've almost never had to modify public/protected stuff, but
have in a number of occasions been disturbed by private annoyances. Of
course that's only my own experience.

Perhaps it all boils down to a point of view: Java is powerful,
because you can choose what to deliver, a foolproof closed system, or
a powerful tin-opener that may badly cut. Translate that to any
production domain, maybe the alternative is present everywhere...

 

[Mike Schilling]

Right, and my only point is that includes ALL implementation details
that you don't want exposed.

No argument here. And that includes details you might want to expose
in a later version, once you've had time to think them through
further, but not now.

 

[Lew]

I once heard (not sure if I agree with it) that
private methods needn't be as concerned with invariants. Pre-conditions
and post-conditions should be met by public methods, but private methods
may leave things hanging. Think fragments of a process.

It's the opposite. You can control invariants in private methods, because you
completely control the gozintos and comezouttas, thus you can ensure
invariants. Certainly one should be aware of the invariants of a private
method; in fact, many times the purpose of a private method is to ensure an
invariant.

With public methods, you also have to control invariants, for example by
massaging the inputs until they conform.

Wherever there is an algorithmic invariant, you have to be concerned with it.
Figuring out where and what the invariants are is an important part of
program analysis and design.

The 'assert' keyword is the Java way of enforcing invariants. You can
'assert' an invariant directly on arguments to a private method, but not on
arguments to a public method. First you have to run normal validity checks on
the inputs to a public method, then the invariant manifests as the
post-condition of the validity check.

 

[Arne Vajhøj]

As I said in my previous post, if the design is flawless, the
accessibility is generally obvious. However, code lives, and having
lived, lives some more. And most of the designs I deal with are large
systems with stuff added when it was needed, resulting in unforeseen
evolution of the code.

So true.

Code tens to live for many many years. Java code written today
may very likely still run in 25 years. We have 25 year old
Fortran and Cobol still being used.

Arne

 

[Mike Schilling]

So true.

Code tens to live for many many years. Java code written today
may very likely still run in 25 years. We have 25 year old
Fortran and Cobol still being used.

You could at least double that.