Private - encapsulation or inheritance (but not both)

Question

Suppose that your class has some internal computation or logic that it performs, and that you wish to encapsulate this in a method that can not be called by other classes.
You provide public methods that filter, format, or somehow modify the input and/or output of this encapsulated method.
class pseudoCodeClass {
private coreLogic(Objects inputs) {
Maybe some complicated math stuff;
Or password stuff;
Or pay out functionality for a slot machine;
return(stuff);
public getUserData(inputs) {
format/check the inputs;
coreLogic(inputs);
format the output;
Now, how do you leveradge the power of OO inheritance to extend the internal logic that you encapsulated? If you make the interal logic private, then it's encapsulated, but you lose the power of OO inheritance, or you can make it protected and lose the encapsulation. I thought an OO language was supposed to have encapsulation and inheritance, not encapsulation or inheritance. (And, yes I realize that there is some techincal sense in which private methods are still inherited, but I'm talking about the general OO concept of inheritence where it includes overriding or extending.)
Suppose you want to:
class pseudoCodeSubclass extends pseudoCodeClass {
private coreLogic(inputs) {
super.coreLogic(inputs);
additional more specific code; // The whole point of OO inheritence
You can't extend super.coreLogic through your access to super.getUserData because it does all sorts of filtering and formating that is not a part of the internal logic that you wish to extend/override. And, providing other more public accessor methods to the core logic just defeats the encapsulation.
I have seen many discussions of this, but none with any answers to my satisfaction. One line of answers is that you don't want encapsulated stuff to be part of your object's contract. Some times people with this sort of answer even suggest coppying the code from the super class into the subclass. People with this sort of answer don't seem to even want the option to use inheritence because of the obligation that might go with it. But without the option of inheriting encapsulated logic, they are forced to either use cut and paste (in an OO language that seems wrong to me) or to abandon encapsulation all together. Being forced into those 2 extreems doesn't seem to me like it would simplify future support of your class, and future support seems to be the primary point of the contract line of response.
The way some people argue about this, I amost want to say - Look! In C you can encapsulate everything you want, and never have to worry about inheritance. (But you still shouldn't have to cut and paste.)
Another line of response that I have seen is that private methods should only be used in breaking up code that would have gone into a single method. In other words, the private methods aren't really 'units of program logic' they are just a mater of organizational convenience. So if you had:
public oneBigMessyMethod() {
100 lines of A;
100 lines of B;
100 lines of C;
you could maintain it as:
public oneBigMessyMethod() {
a();
b();
c();
private a() {
100 lines of A;
private b() {
100 lines of B;
private c() {
100 lines of C;
I agree private works well in this situation. Presumably since a(), b() and c() are divided up for convenience rather than because of distinct logical function, you wouldn't want to extend just a() with inheritance. But this also seems to dodge the question. Just because sometimes you might not want encapsulated functionality to be available for extention, does not mean that you would never want it. I think that I'd also have to disagree with the permise that encapsulation is only for hiding stuff that is just a convention of convenience. The main point of encapsulation is to hide information or functionality. If encapsulation is only used for the convenient breakdown of your primary functionality, then all of your primary functionality is public, package or protected. That does make it inheritable. But, now all of the primary functionality is a part of the contract for that class.
Is there an answer to this issue that does not ignore the value of either encapsulation or inheritance?
There is one way that I can see to do exactly what I think should be possible. That is to put only classes from the same hierarchy in a package. Then both package and protected effectively provide encapsulation with the ability to inherit (and you do still have the option to use private or final if there is a case where you want to disable inheritence).
What I'd like to know is - What do people actually do? In the real world, do people:
1) use private + cut and paste
2) use package/protected + self discipline
Where 2 is that you drop encapsulation within your package but then excercise self dicipline and just don't call/access stuff that you intend to be for that class only...
Or is there some 3rd thing that I'm missing? I've tried to think how maybe you could design your objects in such a way that you'd never need to inherit/extend something that you would also want to encapsulate. But I just don't see how that's possbile.
So, what do people do?
Chris

Answer 1

First of all, you have got to understand that I am not
suggesting that Private and Final should be changed or
removed from java. It looks to me like there should
be an additional access option (and there was
originaly).
I understand that if a class inherits something, it
could expand the access or put public accessor methods
around it. Obviously with ultra sensitive code this
would be a nightmare. So private and final are very
important. But if the very possibility of another
class expanding a given level of access is a reason
for not even having that level of access, then why do
we have package and protected?
There are a great number of places in common coding where that access does restrict usage in a usable way.
>
If the only re-use of your code that you allow is
through the public interface, what do you even need an
OO language for? Just for the polymorphism and a
different way to organize your code?
Not sure what you mean by that but see below.
But as I've said. I've seen this whole thing argued a
number of times. But what I haven't seen is any
explanation of what people who take the poslition that
I'm taking actually do when they write code. Because
I can sit here with a bunch of other people and say 'I
wish Java had this or that'. And then of couse a
bunch of people will resopond and say 'no that's dumb'
or 'I don't see the point'. But at the end of the
day, Java still is what it is. So, arguing about what
it 'should be' is not going to effect how anyone
codes.
Sure it can. That is why java now has assert().
So, what I started out wanting to know is how people
actually code. Particularly people who wish that Java
had a subclass only access modifier.
I don't wish that.
Perhapse I should also be asking about how things are
done by people who see this level of access as
unnececary. How they code is easy enough to
understand. Making everything that is not intended to
be accessed by any other class private is easy enough
to do. But what would be interesting to know is how
do you design your classes to leveradge inheritance if
you do this. Maybe there is some way of desinging
around ever having 'internal functionality' that you
would want to extend and I'm just not getting it.
There are three broad classifications of objects.
1. Those that only use encapsulation
2. Correct inheritence hierarchies
3. Incorrect inheritence hierarchies
The first of those, which I consider most classes to fall into, do not need this.
The third area occurs when programmers use inheritence as a convenience mechanism to propogate behavior amoung different classes rather than using encapsulation as should be done. They don't understand the difference between "is-a" relationships (design) and coding convienence. I would estimate that at least 50% of existing object hierarchies fall into this area. Since in this case the entire design is wrong an extension is not needed.
The second area is the only correct area where this might be needed. Since I personally believe that very few classes belong in hierarchies and this proposed extension would only be useful in a sub fraction of those. Since the correct usage is so small I don't think it would be useful addition to the language.