This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes inheritance violates encapsulation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "inheritance violates encapsulation" Watch "inheritance violates encapsulation" New topic
Author

inheritance violates encapsulation

Moni Marva
Greenhorn

Joined: Jan 24, 2005
Posts: 23
Is inheritance violates encapsulation
Peter Rooke
Ranch Hand

Joined: Oct 21, 2004
Posts: 800

Yes, use aggregation Unless you really know that an inheratance relationship is needed.


Regards Pete
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
Yes it violates encapsulation but use inheretence should be used frequently. You use it with IS-A relationships because you do not want to encapsulate a dog's behavior in a chihuahua. I want my chihuahua to shiver but it still needs to bark and roll over on command and I definitely would like to pass the chihuahua to a dog motel that accepts dogs in general. Inheritence is a powerful feature with major benefits.

Composition violates rules of loose coupling. You should use it frequently. Dogs aren't fleas. Loose coupling and encapsulation are qualities that you should start with as your default strategy. To do something useful, you will then determine that A needs to couple with B and C is-a D so D's methods need to be available to C users and so on.
Steve Morrow
Ranch Hand

Joined: May 22, 2003
Posts: 657

Just to muddy the waters: Inheritance of implementation violates encapsulation. Inheritance of interface does not.

Bruce Eckel, author of Thinking In Java, has this to say about composition vs. inheritance:

When deciding between inheritance and composition, ask if you need to upcast to the base type. If not, prefer composition (member objects) to inheritance. This can eliminate the perceived need for multiple base types. If you inherit, users will think they are supposed to upcast.

Choose composition first when creating new classes from existing classes. You should only used inheritance if it is required by your design. If you use inheritance where composition will work, your designs will become needlessly complicated.

Bill Venners: Composition versus Inheritance


[EDIT] Apologies in advance if this isn't a "beginner" topic.
[ August 18, 2005: Message edited by: Steve Morrow ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I don't worry too much about violating encapsulation when extending abstract classes. Extending concrete classes can get you into some problems that are very hard to predict or figure out. Still, prefer interfaces and prefer composition are both good bits of advice.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> prefer composition

Prefer inheritence for IS-A relationships since you gain dynamic binding and more reliable, simpler extensions. More skill is required to maintain a solid hierarchy but it's worth the extra effort is you truly have IS-A.

I think it's safe to assume you would drive reasonably skilled developers nuts if you stopped using inheritence and instead put all of your classes on call-forwarding.

IMO there is no valid case to be made for composition in place of inheritence where inheritence is the natural relationship. Microsoft always suggested that composition was the way to go. Then they came out with C# and some very, 'scuse the pun, sharp minds included it as an integral part of the language.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rick O'Shay:
>> prefer composition

Prefer inheritence for IS-A relationships since you gain dynamic binding and more reliable, simpler extensions. More skill is required to maintain a solid hierarchy but it's worth the extra effort is you truly have IS-A.

I think it's safe to assume you would drive reasonably skilled developers nuts if you stopped using inheritence and instead put all of your classes on call-forwarding.

IMO there is no valid case to be made for composition in place of inheritence where inheritence is the natural relationship.


I don't think there is something as a "natural inheritance relationship". Inheritance is a programming technique - it is as natural as a screwdriver.

And "IS-A" can only be a heuristic, if only because there is no hard and fast definition of what "IS-A" means.

The balance between composition and inheritance is one of flexibility vs. simplicity. The right balance is a function of the current and future requirements, and finding it is mostly a matter of educated guesses, guided by experience and some rather rough heuristics.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
No, inheritance does not violate encapsulation. This is an unfortunate consequence of the problematic article published by Allen Holub. The fact is, that "concrete inheritance" violates encapsulation, which is what you might well be describing. There is a legitimate form of inheritance - contract inheritance (or in a Java context, interface inheritance). Unfortunately, some people associate "inheritance" with "concrete inheritance" and in the case of Holub, the "extends" keyword with "concrete inheritance".

Here is a brief attempt at clarification:
http://www.jtiger.org/articles/why-extends-is-not-evil.html

It's good to hear that there are still developers out there who think for themselves; keep it up. ..and remember, declare all classes final, with the exceptional exception of exceptions, which are a poor man's metadata. Oh if only those guys at Sun knew what they were doing...
[ August 20, 2005: Message edited by: Tony Morris ]

Tony Morris
Java Q&A (FAQ, Trivia)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Tony, I wholeheartedly disagree. "Concrete inheritance" is a very useful tool. Like every tool it can be overused, but if you keep the balance, I don't see anything wrong with it. Design Patterns such as Template Method, Factory Method etc. can be quite elegant and would be a shame to fully ignore just because of some doctrine, in my opinion.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

Tony, I wholeheartedly disagree. "Concrete inheritance" is a very useful tool.

I know, and work with, many people who have (had) this opinion until I refuted all of their arguments, then provided a fundamental basis from which they could think for themselves. The result was either enlightenment on their part (realisation that they've been following trash for years) or ad hoc refutation before finally conceding with "I don't care". I have difficulty putting these arguments on paper/forums, but I assure you I've spent hundreds (thousands? I should keep a log) of hours arguing this single point with many reputable people.

It really is a straight forward process when some objective analytical skills are applied. I urge you to abandon preconception (doctrine ironically) and think for yourself. Fundamentals *do* exist (within some context/axiom), but very rarely in marketing literature, vendor documentation or technical publications such as books (typically, with a primary agenda of making money - how well would a book sell if it portrayed facts with reaoning instead?).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Tony, something in your tone worries me - you seem to imply that people who disagree with you don't think for themselves and that your position is obviously objective (and a different position obviously couldn't be).

I'd rather assume that we *all* read and listen to a lot of sources, evaluate the information in the context of our own, subjective experience and pick up what seems to make sense to us. I could even imagine that some of the people who "don't care" about the values you seem to care about might be *right* in doing so, in their personal situation.

Having said that, I'd be very interested in your reasons for totally scrapping implementation inheritance.

Originally posted by Tony Morris:

I urge you to abandon preconception (doctrine ironically) and think for yourself.


Interestingly, "never use implementation inheritance" looks much more like a doctrine to me than the suggestion to evaluate a specific situation to find a good balance (which probably would involve some "thinking for yourself"...).

But I'd like to re-think my opinion, if you can provide some new input...
James Hejmanowski
Greenhorn

Joined: Aug 22, 2005
Posts: 8
OK so I'm a complete newbie but my learning style is to get the basics *down* before I extend them so I'd really like to see you guys debate this topic!

Tony, in your reply could you explain why you favor marking all classes final?


"I drank what"?<br /> -Socrates
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
I concede on the point that I have not provided reasoning; and this is a potential weakness in my argument. I very much encourage discovery yourself rather than by listening to my apparantly religious preachings/doctrine. Let me pose the question to you, when one suggests to another to use concrete inheritance, is this not doctrine? ...since clearly, no reasoning is given, and if it were, it is easily disproven as fallacy and it's just as much an absolute statement as the contrary? Then, if I were to give some piece of information that is not taken from any source that has some other agenda and ask you to think about it, is this not doctrine, since it is up to you to discover it? That is to say, the Sun marketing literature, your text books, etc. that condone concrete inheritance without any reasoning whatsoever all have a primary agenda that has nothing at all to do with your education/learning. Yet, what agenda do I have? Sure, it's an internet forum where egos are high and one might argue that I'm here trying to gain brownie points for myself; I have no ambition to earn your (someone I do not know) trust - I have given information that is in your interest; take it, leave it, burn it, bothers me not.

One thing that does bother me a little is that I expended massive efforts proving this very point (and others), only to have it undermined by a "10 second thought rebuttal". Unfortunately, I have nothing to show for it yet. If a decent refutation does exist, I'd be keen to know about it - I'm not hanging on to this point religiously - but I believe a lot of thought, experience, reflection, etc. is required before that can occur. Until then, I reserve my right to make absolute statements without any reasoning whatsoever just like everyone else.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:
I very much encourage discovery yourself rather than by listening to my apparantly religious preachings/doctrine.


Well, until now it seems to me that I "discovered" that implementation inheritance (I assume that is what you mean by "concrete" inheritance) has it's valid place, even though it certainly can be overused. Part of my reasoning is that it's often less complex and totally sufficient for the near future, and not too hard to refactor to a more flexible approach, once it's needed.

Still I'd be interested in listening to and discuss experience reports that suggest otherwise.

Let me pose the question to you, when one suggests to another to use concrete inheritance, is this not doctrine?


Well, depends on how it's done. Might just be a suggestion, I suppose...

...since clearly, no reasoning is given, and if it were, it is easily disproven as fallacy and it's just as much an absolute statement as the contrary?


I always try to give reasoning about all the suggestions I give, and if the reasoning doesn't suffice, people often ask clarifying questions, which I try to answer. There certainly are some disagreements in detail from time to time, which most often results in the most interesting and enlightening parts of a discussion, but I can't remember any obvious "prove" of a fallacy.

That is to say, the Sun marketing literature, your text books, etc. that condone concrete inheritance without any reasoning whatsoever all have a primary agenda that has nothing at all to do with your education/learning.


I don't read "Sun marketing literature", but my text books (by authors such as the Gang of Four, Robert C. Martin, Martin Fowler and Kent Beck, to just name a few) don't "condone" implementation inheritance, they rather explicitely discuss the forces that balance inheritance against alternatives such as composition, or so it seems to me.


I have given information that is in your interest; take it, leave it, burn it, bothers me not.


I'd like to take it, but as is it isn't of much value to me. If you don't bother, I can certainly live with that, even though I would prefer a more detailed discussion. We all would likely learn something, and I would like that...

One thing that does bother me a little is that I expended massive efforts proving this very point (and others), only to have it undermined by a "10 second thought rebuttal".


Well, until now I haven't seen your massive efforts. Do you have some pointers on where I can research them?

But you can relax: I didn't try to undermine your point, I merely was interested in learning more about it and in discussing it. Providing a conflicting point of view based on actual experience seemed like a good starting point for that to me.

And I've already put much more than 10 seconds of thought into the issue and will continue to do so. I welcome any input that helps me to explore new directions of thought, but it will typically need more than just a blunt "don't ever do this" statement for that.

It would be nice if you could acknowledge that others might have thought about this issue too, and possibly even have come to different conclusions, without mindlessly being spoonfed by some authors with strange hidden agendas. In fact otherwise it's kind of comprehensable to me if you are not very successful at passing along your ideas.

No hard feelings...
 
Don't get me started about those stupid light bulbs.
 
subject: inheritance violates encapsulation
 
Similar Threads
subclassing violates encapsulation , its true ?
What are the principles of OOA/D?
Locking scheme
4 key points about Oops
Field hiding