static and protection

[Hasan Aljudy]

Regan Heath wrote:
> On Wed, 01 Mar 2006 16:43:07 -0800, Kyle Furlong 
> <kylefurlong at gmail.com>  wrote:
> 
>> Jarrett Billingsley wrote:
>>
>>> "Hasan Aljudy" <hasan.aljudy at gmail.com> wrote in message  
>>> news:du56te$1rn5$1 at digitaldaemon.com...
>>>
>>>> friendship works, my point was that it shouldn't be there in the 
>>>> first  place, it's not part of the OO paradigm, it's a hack 
>>>> introduced by C++
>>>
>>>  Just because it's not part of some archaic OO paradigm doesn't mean 
>>> it  can't exist.  It might be a hack, but I think it's kind of borne 
>>> out of  necessity. Sometimes the rules in OO need to be .. bent a 
>>> little, and  friend classes do just that.  I mean, which would you 
>>> rather have?  Two  classes that need to work together friended so 
>>> they can access each  others' internals, and so no one else can 
>>> access those internals?  Or  be required to make those internals 
>>> public just so those classes can  work together?  If two classes 
>>> really need to work together but still  need to be separate classes, 
>>> I really don't see any other solution..
>>
>>
>> Well, do people use your *ORGANS* when you work with them?
> 
> 
> No. However a better analogy is "I will let my neighbour come over and 
> use  my basketball hoop, but not the general public."
> 
> class Me {
>   private BasketBallHoop hoop;
> }
> 
> class Neighbour {
>   void playSomeBall(BasketBallHoop hoop) {}
> }
> 
> void main()
> {
>   Neighbour bob = new Neighbour();
>   Me regan = new Me();
>   bob.playSomeBall(regan.hoop);
> }
> 
> Regan

Why would you *not* allow the general public to play with your hoop?
obviously, if you neighbour can play with it without negatively altering 
your state (as an object), then everyone else should be allowed to play, 
since they too won't be able to negatively alter your state.

 From the way I understand OOP, the main reason for encapsulation is to 
increase the cohesion of code that maintains the state of the object.

You don't want other objects to directly access your fields (data 
members) because most of the time there are maintainance tasks that need 
to be taken when reading/writing values to/from local fields. You want 
these tasks to be performed in one place, that is the get/set methods 
inside the class itself.

That's why OOP says you should always use accessor methods for object 
varaibles and to never make them public!!

If you have an "age" variable for a "Person" class, you probably want to 
always make sure that this age is reasonable, i.e. it's between 0 and 
200. So, you need to write code to make sure this condition is always 
met; you don't want to suddenly have a person with a negative age.
The only reason why would disallow direct access to the "age" field is 
so that you can be sure that no invalid age can be set for any person 
object. If you don't privitize age, then you have to splatter the age 
validation code everywhere you access/modify "age" fields of "Person" 
objects ... you don't want that to happen!!

That's the idea behind enapsulation.

It's got nothing to do with "forbidding" users from knowing how your 
code works. There's no purpose in hiding a method just for sake of 
hiding it. If you can make it public for some objects, it should be 
allowed to be public for all objects.

That's OOP, which bythe way, is a purist paradigm. I know D is not for 
language purists, but OOP must be supported properly.

Can you give me a real life example where one class needs to expose 
certain parts of itself to only one or two other classes? and why would 
providing a public accessor for this feild be a bad thing?