On Wednesday, January 30, 2013 15:26:32 1100110 wrote: > On 01/30/2013 09:10 AM, Jacob Carlborg wrote: > > On 2013-01-30 02:40, TommiT wrote: > >> I always thought that having public member variables is a bad style of > >> programming because of the lack of encapsulation. So, if there's a > >> language feature that enables you to write public member variables, and > >> later on, replace them with property functions, wouldn't that mean that > >> the language is encouraging this particular kind of bad style of > >> programming? > > > > I really don't see much point in properties/methods that just forwards > > to an instance variable. > > Me either. > > I mean yes, for anything that is part of a public api you should > probably double check everything. But insisting on getters and setters > regardless of the requirements of what you are getting and setting? > > Sounds like an excuse to not think, to me.
The main reason for it is that you can add additional code later when it no longer needs to just get or set the variable. But one of the goals of properties is to make it so that you can just make it a public variable to begin with and then swap it out with a property function later when you need to add code like that. However, that never quite seems to work perfectly, as there's always something that you can do with a variable that you can't do with a property function (e.g. take its address or pass it by ref). Without properties though, you definitely want the getters and setters so that you don't lock yourself out of being able to properly protect the variable when you actually need to later. - Jonathan m Davis
