|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |