Monday, March 29, 2010

Why I Don't Like The Private Access Specifier

I like the concept of encapsulation. Really. I do. Hiding implementation details behind an interface is top-notch design work. I'm all for it. As long as it's done with "protected" and not "private".

The problem that I have with the private access specifier is that it discourages or prevents entirely code reuse in certain situations. Let me explain: as is often the case, I find myself coding with certain libraries or frameworks. Just as often they do not do everything exactly how I would like. Perhaps they are missing a feature, or maybe they have a small bug somewhere. No problem! They are coded with OOP principles, so if I want to add a feature, I'll just subclass it and do what I need to do, right? Wrong!

All too often the particular hook that I need to add my feature is marked private. And since it's marked private, at the discretion of the original author, I can't do what I need to do. Let me lay this out: I have access to the original source code in one form or another, I understand what the original source code is doing, I've identified exactly what I need to change, and yet I'm stuck. What are my options?

One is to change the original source code. However, this is not always possible. Take the .NET Framework for example. The framework comes in a "compiled" form, yet the source code is readable thanks to tools like Reflector. Even if I can change the source code, I don't always want to. Perhaps I want to be able to distribute my application without packaging my custom build of the library. In the case of Javascript, perhaps the library is coming from a CDN like Yahoo provides for YUI.

Another option is to use what hooks I do have available. For instance, if protected MemberA calls private MemberB, and I need to change MemberB, I can override MemberA, copying most of the code, and have it call my custom MemberC instead of the original MemberB. Sometimes this requires changing code many levels deep, and the final product is a copy/pasted mess of the original.

It seems to me that a balance could be struck between the concepts of encapsulation and the flexibility of OOP inheritance and code-reuse. This balance, I think, is called "protected". If somebody has the time and dedication to read and understand the implementation details of a class, I do not think they should be barred from subclassing and having full access to that implementation. I do not believe that it should be up to the original authors to decide what should and should not be changed; they do not have enough foresight. It is impossible to imagine every single feature that could potentially be added and create an extension point for each. Using protected means that normal users of the code still have encapsulation, and those that want or need to go the extra step have the flexibility to do so.

I don't recall a time when I ever thought to myself: "I sure am glad that member is private. That really saved me a lot of hassle." I know of numerous times when I've thought the opposite. Very dark thoughts indeed.

24 comments:

  1. بادر بالتواصل مع شركة تنظيف خزانات بمكة المتخصصة التي تقدمها شركة العنود حتى تتمكن من الحصول على جميع خدمات تنظيف خزانات بمكة المتكاملة التي تحتاجها لخزانات منزلك بأقل الاسعار

    ReplyDelete
  2. The article is very interesting. And I also want to share articles about health, I'm sure this will be useful. Read and share it. Thank you very much :)

    Khasiat dan manfaat QnC Jelly Gamat
    Obat Benjolan Di Ketiak
    Solusi Sehat Alami
    Jamu Tradisional Penyubur Kandungan/Herbal Khusus Wanita

    __

    ReplyDelete
  3. After reading and understanding this article. in my opinion this is very useful .

    ReplyDelete
  4. When you’re contemplating a significant move to a place like Anchorage, you might mentally “try on” your new hometown, much like stepping into a dressing room and pulling on a new outfit.
    transportation service Exeter

    ReplyDelete
  5. This comment has been removed by the author.

    ReplyDelete
  6. GREAT JOB! This blog presents a very valuable information. Keep up the good work! Visit our website too. Thanks!
    고스톱

    ReplyDelete
  7. Thanks for sharing the informative post. If you are looking the Linksys extender setup guidelines . so, we have a best technical expert for handlings your quires. for more information gets touch with us.
    한국야동

    ReplyDelete
  8. Nice post! This is a very nice blog that I will definitively come back to more times this year! Thanks for informative post 토토사이트

    ReplyDelete
  9. The Best Casino Apps of 2020 - DrmCMD
    Best casino 세종특별자치 출장마사지 apps: · 광양 출장마사지 1. 강릉 출장샵 Bovada · 2. Slots 부산광역 출장안마 Casino · 양주 출장샵 3. Vegas Slots Casino · 4. BetMGM · 5. The Atlantis · 6. Bovada.

    ReplyDelete