Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   The idea with having objects rather than raw data is that objects can
> > be made abstract, ie. have an abstract public interface which hides the
> > implementation).

> So why is it better to have member functions at all, vs just passing the 
> object to a function?  What's the benefit of being able to say
>     p = pixels[23].lightened();
> vs
>     p = lightened(pixels[23]); // Like you would in Java

  The benefit is that, at least in theory, the member function can be
dynamically bound, while the regular function can't.

  With static member functions I suppose it doesn't make too much of a
difference (except that they are less writing because you don't have to
befriend all the functions explicitly).

  Although in some situations it could make a difference also with static
member functions, regarding to access rights. For example, a member
function of a derived class can access the functions in the protected
part of the base class, but an regular function can't. (Making the regular
function a friend of the base class would open even the private part of
it, which might not be what you want.)

> >   I don't see how "anObject.someFunction()" hides the implementation
> > better than "someFunction(anObject)", 

> Because it looks like it's part of the class. You don't have to remember 
> which members are built in and which ones were added by a library you're using.

  One could maybe argue that that's a *bad* thing. If it looks like part
of the class but isn't, that might cause problems when you reuse the class
somewhere else, where you might not have the extension in question.

-- 
                                                          - Warp

Post a reply to this message