This week's giveaway is in the Spring forum.
We're giving away four copies of Learn Spring Security (video course) and have Eugen Paraschiv on-line!
See this thread for details.
Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

inheritance violates encapsulation

 
Moni Marva
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is inheritance violates encapsulation
 
Peter Rooke
Ranch Hand
Posts: 847
1
Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, use aggregation Unless you really know that an inheratance relationship is needed.
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 657
Clojure Spring VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>> 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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic