Craig Castelaz's Blog

Are Encapsulation, Polymorphism, and Inheritance peers?

I spend most of my time as a Java developer happily writing code without explicitly thinking about encapsulation, polymorphism, and inheritance as underlying principles. I mean those things are given. It would be like noticing wheels are round each time I get in my car. Just like I exploit the roundness of my tires as I tool down the street, I make use of the object-oriented features of Java without necessarily being consciously aware that is what I'm doing.

This isn't to say I drive with my head stored in the trunk, or that I have it shoved somewhere else when I code. Although my family and co-workers may have other opinions, I like to believe I'm concentrating on the things that matter most whether I'm driving or programming. In the case of programming this would include things like fulfilling the spec, designing a system that is maintainable, and writing code that is readable. I don't set out to create a program that exploits polymorphism. I create a program to solve a problem. Encapsulation, polymorphism, and inheritance are means towards that end. They are not the goals.

On the other hand, I'm not neutral in my use of these object-oriented features. When I reflect upon past work, I detect a strong pattern in my code. My greatest concern seems to be with encapsulation. I like to keep as much as I can private. I'm pretty stingy with the public keyword, and rarely, if ever, use protected. Polymorphism creeps silently into a number of my projects, but mostly as separate implementations of a common interface, rather than through extension of another class. In other words, my code tends to emphasis polymorphism over inheritance.

I suspect most of these inclinations date back to my years as a C programmer. I originally encountered the ideas behind The Big Three of OO while coding in that language. I was already doing both encapsulation and polymorphism through the use of module-level variables and function pointers, but without the cool names for the practice. When I migrated over to a true OO language, those two concepts traveled with me. Perhaps I've been damaged somewhere along the line, but I fear inheritance will always come up third in my personal OO lexicon.

Then again, isn't that the real beauty of a rich language like Java. While we can discuss and debate the relative merits of one approach over another, the language is open and flexible enough to allow different interpretations of what is important, and how it should be used.

Comments

• Nothing to see here...
  I don't think your comments are going to suprise the majority of experience Java programmers.

  Encapsulation is always the key design technique, no matter what kind of language is being used.

  Within my Java projects I find myself, as you note, using polymorphism primarily by calling different implementations through an interface. This is perfectly valid, and there is no particular reason why we associate polymorphism so strongly with inheritance.

  Inheritance has mostly been replaced with composition in my work, and that's simply because I rarely find domain objects that I can model easily - most of them time A is-like B, not is-a B. Where I do use inheritance tends to be within the supporting framework code; things like loggers which do not model business cases directly.

  Posted by: david_kennedy on September 25, 2003 at 03:46 AM

• Encapsulation to the point of componentization
  I agree with ranking encapsulation as the primary concern. Encapsulation, particularly when you go so far as to consider your objects as components, allows you to build loosely coupled systems. Loose coupling seems to be the most important characteristic in avoiding dead-end applications.
  Polymorphism ranks as number 2 on my scale, since polymorphism allows abstraction, and abstraction (you guessed it) allows for looser coupling.
  Inheritence is on the bottom of the scale, and I have to express my concern that it can be down-right counter productive as a design criteria. I have way too often seen folks lost in the quest for the perfect class hierarchy when they should have been focussing on the interfaces (I think this is why I prefer CRC to RUP). Inheritence is about code reuse. This may reduce bugs, but it's not going to reduce coupling.

  Posted by: johnreynolds on September 25, 2003 at 07:09 AM

• Encapsulation through polymorphism
  I use minimal interfaces a lot as a way of reducing dependencies and coupling. As a result of this you also get encapsulation, since an object is always handled through one of it's interfaces.

  I seldom use inheritance of implementation (which is overrated), I rather use composition, which is more powerful and easier to maintain.

  Btw, the "interface" keyword is the best feature in the Java language. Thanks Gosling!
  

  Posted by: mayhem on September 26, 2003 at 04:21 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling on December 13, 2007 at 01:23 AM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  网络营销软件
  网站推广软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版

  Posted by: bininine on December 16, 2007 at 01:14 AM

This work is licensed under a Creative Commons License.