Internal Stripping

March 16, 2008

tags: ,
5 comments
Technorati Tags: ,,

Sasha has notify me about a post of Oren Eini about internal stripping. I have a deep respect to Oren, but I don’t agree with his thought about the subject. Developers today are talking a lot about SOA and other “new” ideas, but forget sometimes the good old ideas of Object Oriented Programming. This time we are talking about encapsulation and decoupling.  Here is my point of view: 

  1. Using private or internal types/members is something that should be avoid in most of the cases. There are many reasons that a developer doesn’t expose an internal implementation to the public. Just to give a few good reasons:
  2. The object has to keep its own invariants. It can be a nightmare finding who changes or uses in a wrong way an internal part of a module/class.
  3. The internal method has a certain “safe” ways to be used, and internally the developer knows how to use it, but a very bad side effect can be happen in a wrong usage (wrong protocol)
  4. It’s not an easy task to make something public, to make extension points (protected) and so on. You have to think a lot and you have to test it. Making it internal at first place tells that it is an implementation code for the internal dev team.
  5. Coupling, Coupling, Coupling. A good software engineering is to reduce coupling by exposing only few interfaces. Making everything public will not help.
  6. Maintenance and upgrading, do you want each time a hot fix, service pack or new version of .NET/Windows is installed to go over your million lines of code software and fix all your “internal” usages. O.K maybe not everything has changed, but you have to test your software again anyway.
  7. You will not get any breaking change document about internal code, and you may not get Microsoft support if you use internal mechanism.

I think that you have got the point. I know that sometimes you will not agree with the internal/private keyword. But this is the privileges of the developer; he does not have to give you everything. And if you don’t get enough in the interface (public) don’t use it at all.

There are times that you may use internals API. For example sometime I use ntdll functions even though there are not documented APIs. I even implemented many FXCop custom rules when I knew that the SDK will be changed. But I am doing it with a known risk. I document it; I try to find a better way and if there is no one I take my chances. But at least I know the risks.

Add comment
facebook linkedin twitter email

Leave a Reply to nick_noeltc Cancel Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

5 comments

  1. Sasha GoldsheinMarch 16, 2008 ב 10:19

    I totally agree with every single point.

    And from experience, what happened was that NTDLL almost never changes (because practice has made it a documented interface). However, the architecture of Code Analysis (FxCop) has changed twice already and it’s probably going to change again in vNext. And yes, we’re aware of it, and yes, it costs us a lot.

    Reply
  2. SidneyDecember 14, 2008 ב 15:08

    please alon call me,it is very argent

    Sidney
    CTO
    IVIVO
    sid@ivivo.tv

    Reply
  3. kookimebuxFebruary 1, 2009 ב 20:12

    Hello. And Bye. 🙂

    Reply