Public member variables acceptable?
in [C++]
|
Prev: Why not reject the dynamic instantiation of a class with non-virtual destructor?
Next: Example (3.3.6) from standard puzzles me
From: francis_r on 27 Jun 2008 16:27 I made it a habit to always, without any exception, declare my member variables private. However, there are some situations where it seems that it's ok to make an exception. For example in a Point class: class Point { public: Point(); Point(int inX, int inY); int x; int y; }; Would this be bad design? On what principles would the decision to declare a member public be based? Kind regards, Francis -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seungbeom Kim on 28 Jun 2008 07:11 francis_r wrote: > I made it a habit to always, without any exception, declare my member > variables private. However, there are some situations where it seems > that it's ok to make an exception. For example in a Point class: > > class Point > { > public: > Point(); > Point(int inX, int inY); > > int x; > int y; > }; > > Would this be bad design? Probably not, if what's above is all about Point. > > On what principles would the decision to declare a member public be > based? My principle is to check whether the class is meant to enforce any class invariant. Otherwise, it's just an aggregate of data. For example, if you want x or y to be in a certain range, that's a class invariant, and you need to make them private and provide member functions to change them while still enforcing that invariant. In particular, a particular relationship to be maintained among data members is a class invariant. For example, you may want to keep a list of items in one order and another list of iterators to the items in another order; then the class invariant is that the items in the first list and the iterators in the second list form a one-to-one correspondence. -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Erik Wikström on 28 Jun 2008 07:25 On 2008-06-28 09:27, francis_r wrote: > I made it a habit to always, without any exception, declare my member > variables private. However, there are some situations where it seems > that it's ok to make an exception. For example in a Point class: > > class Point > { > public: > Point(); > Point(int inX, int inY); > > int x; > int y; > }; > > Would this be bad design? > > On what principles would the decision to declare a member public be > based? In my opinion there are two kinds of classes, the first is the classical object-oriented class where an instance represents an object with a state and the state have to be consistent at all time. In these cases you want private member variables so you can control the how the state is changed. The other kind of class is the record type, a few pieces of data stored together but there might not be very much relation between the values stored in the different members (such as the X and Y coordinates of a point), in other words the class is used primarily for grouping. In these cases public members are fine, and many uses struct when declaring these kinds of classes. -- Erik Wikstr�m [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin York on 28 Jun 2008 07:38 On Jun 28, 12:27 am, francis_r <francis.ramme...(a)gmail.com> wrote: > I made it a habit to always, without any exception, declare my member > variables private. However, there are some situations where it seems > that it's ok to make an exception. For example in a Point class: > > class Point > { > public: > Point(); > Point(int inX, int inY); > > int x; > int y; > > }; > > Would this be bad design? Bad is relative and always depends on the situation. What this does do; is lock you into an interface. In future versions you must always provide accesses to the data via members x and y. If this is bad depends on your usage. This could be bad if (for example) you wanted to change the internal representation. Say: std::pair<int,int>. In this situation you would have a lot of extra work to maintain the interface. Just 2p worth. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pavel Minaev on 28 Jun 2008 07:57
On Jun 28, 11:27 am, francis_r <francis.ramme...(a)gmail.com> wrote: > I made it a habit to always, without any exception, declare my member > variables private. However, there are some situations where it seems > that it's ok to make an exception. For example in a Point class: > > class Point > { > public: > Point(); > Point(int inX, int inY); > > int x; > int y; > > }; > > Would this be bad design? > > On what principles would the decision to declare a member public be > based? There is no consensus. A rough rule of thumb is, when your class is mainly an aggregation of data, and when there are no constraints on data members or other class invariants that you would want to maintain, then public fields are okay. A good example of such class is std::pair - it's really just an aggregation of two values with no additional semantics, and this is intentional rather than coincidential, so there is no chance that a future version of std::pair might need to enforce some new invariant on the data contained within, requiring encapsulation. Then again, if you need a POD type, you can't have private fields either, so there's another, C++-specific reason. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |