Posted by Tony Marston on 10/08/41 11:51

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:IrOdnQkOaac8Gz3ZnZ2dnUVZ_omdnZ2d@comcast.com...
> Henk Verhoeven wrote:
>> Jerry Stuckle wrote:
>> > Actually, things like private declarations are very important.
>>
>> IMHO private declarations are too rigid and therfore decrease
>> reusability. I agree that it can be very usefull to know the intentions
>> of the developer of some code one is evaluating to call or some member
>> variable one is avaluating to access. But every now and then there are
>> good reasons to do it anyway, even if it was intended to be private. For
>> example lazy initialization and default reasoning both are often
>> implemented using direct access to member variables. Another example is
>> using a visitor to implement persistency.
>>
>> Now maybe you would say that i should change these member variables to
>> protected or public. There are two problems with this:
>> 1. It may not be my own code. Then if i get an upgrade of this code,
>> these member variables will once again be private, unless i re-apply my
>> changes. This is uneccessary overhead.
>> 2. By changing the private declaration the intension of the other
>> developer gets lost. Now i could put a comment in that it was intended to
>> be private, but in that case: why not put the @private marker in the
>> comment in the first place?
>>
>> The fundamental point is: With these private and protected declarations
>> you get stuck with the uneccessarily limitations introduced by the
>> author. Object-orientation can lead to more reusability then conventional
>> parameterized code exactly because the code can be overridden and
>> extended in ways the original author did not provide for. private and
>> protected declarations are a step backwards that is only reasonable if
>> you assume that future developers that will maintain or reuse your code
>> will ignore your intentions becuase they are fools. If this is the case,
>> i think you should tell your boss that you are limiting the reusability
>> of your code because you are aniticipating him to hire fools and let them
>> work on/with your code ;-)
>>
>> Greetings,
>>
>> Henk Verhoeven,
>> www.phpPeanuts.org.
>
> Henk,
>
> Private declarations are key to OO programming.

No they are not. Encapsulation is not the same as data hiding. Please refer
to:
http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.itmweb.com/essay550.htm

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

> One of the basic tenets of OO programming is that you don't know the
> internals of the object you're operating on (encapsulation). You can then
> change the internals of that object - and not affect any code depending on
> that object (as long as you don't change the interface - the message
> passing). Contrast to public variables - if you find you need to change
> one, it's hard telling how many places you have to change it in the code.
>
> For instance. Lets say you have a variable in your class containing a
> name, which you access directly throughout your code. Now suddenly you
> find you need to keep that as first name and last name - instead of just
> name. How many places are you going to have to change in your code?
>
> Contrast this with a GetName() function, which in the first case returns
> the name field. When you change the code to have first_name and
> last_name, your GetName() function just returns the concatenated fields
> (with a space between). You have to make no changes in the rest of your
> code.
>
> Second example. You have a Person class with a name. You reference it
> directly. But now you find you need to split the class - you need class
> Employee and class Contractor. Both can be derived from Person - but now
> Employee doesn't have a Name. That's in the parent class Person. But
> while you can't access Name in Employee, you can access GetName because
> that has been inherited from Person.
>
> Last example. You have a Date field in your class in the format of
> MM/DD/YYYY (U.S. format). Someplace in your code you suddenly get "this
> is garbage" in the field. Where did it come from? If the variable is
> private, a change to an invalid value can be intercepted *before* the
> value is stored, and an error message produced. Otherwise you may be
> hundreds of thousands of LOC later before finding the invalid value.
>
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstucklex@attglobal.net
> ==================

[Back to original message]