[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Some thoughts on kdelibs et al.
From:       Martijn Klingens <martijn () martijn ! homeip ! net>
Date:       2001-09-25 8:01:51
[Download RAW message or body]

On Mon, 24 Sep 2001, Richard Moore wrote:
> Actually, I'd say it's highly likely that the QLineEdit in this class *will*
> be removed. It should be a combo box in order to support a history. If thee
> code had been written to use an accessor method to obtain the QLineEdit
> pointer then this could have been accomodated without breaking source
> compatibility (using the QLineEdit accessor in QComboBox). Giving direct
> access to member variables is almost always the wrong choice, and should be
> avoided.

I think the much better approach would be to make _all_ data members
private, but provide access to them by means of an accessor method:

class foo
{
public:
  foo();
private:
  int m_myMember;
protected:
  int myMember();
  void setMyMember( int m );
};

This comes most close to the way e.g. Delphi handles this problems by
means of the 'property' keyword (Borland C++ Builder and MS C# do it like
this as well): You can specify a method that is automatically called
whenever you try to read and/or write a property. The internal data member
can (and should) be private and can never be accessed outside the class
itself.

I do agree that there must be _some_ way to access many data members,
because currently lots of classes don't even have the protected accessor
methods. That is quite a bit less desirable...

And don't make the accessors inline, because then you can't reimplement
them later on when the API changes and the old function nees to be
emulated.

Martijn


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]