Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
Why do we need private variables?

I know that it's best practice to stay safe, and that we should always prevent others from directly accessing a class' properties. I hear this all the time from university professors, and I also see this all the time in a lot of source code released on the App Hub. In fact, professors say that they will actually take marks off for every variable that gets declared public.

Now, this leaves me always declaring variables as private. No matter what. Even if each of these variables were to have both a getter and a setter.

But here's the problem: it's tedious work. I tend to quickly lose interest in a project every time I need to have a variable in a class that could have simply been declared public instead of private with a getter and a setter.

So my question is, do I really need to declare all my variables private? Or could I declare some variables public whenever they require both a getter and a setter?

share|improve this question

marked as duplicate by maple_shaft Apr 11 '12 at 14:39

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

6  
There are reasons to do so in e.g. Java. There is absolutely no reason to in e.g. Python. This is (one minor) part of why I use the latter... –  delnan Mar 13 '11 at 8:29
    
In a language like Java where you don't have syntactical support for creating simple accessors there are cases where a public variable makes sense. Sometimes you just know that it will never be more than a simple field. –  Ed S. Mar 13 '11 at 8:49
3  
Use lombok.Data or other annotations from it to generate the accessors for you without changing the source code. –  maaartinus Mar 13 '11 at 14:28
1  
@maartins Big +1 for lombok in Java. I used to be in the same boat of "I hate getters" until I found out I can just type @Data and be done with it –  TheLQ Mar 13 '11 at 16:53
2  
The answer is completely language-dependent, and also dependent on the clients of the class. –  kevin cline Feb 8 '12 at 17:32
show 3 more comments

10 Answers 10

up vote 17 down vote accepted

Proffessors saying "ALWAYS do this or that" in regard to programming should be fired, or go back to school themselves. In programming there is never one single best way to do something, it all depends on the particular application.

Example for your case: suppose you have a class representing a simple configuration structure with 10 fields, but no actual functionality, so no methods except a constructor maybe. All members can be read/written. Personally I would prefer

class MyConfig
{
public:
  int a;
  int b;
  int c;
  int d;
  int e;
};

much, much more than the next one, which also adds no extra functionality over the original..

class MyConfig
{
public:
  int GetA() const{ return a; }
  void SetA( int i ){ a = i; }
  int GetB() const{ return b; }
  void SetB( int i ){ b = i; }
//you get the point.. 
private:
  int a;
  int b;
  int c;
  int d;
  int e;
};
share|improve this answer
27  
You fail to mention the main reason sane persons write getters/setters: For validation or other more complex logic on getting/setting, and for future-proofness in case you need to add some of this. –  delnan Mar 13 '11 at 9:13
2  
@delnan indeed, but KeesDijk's answer already pointed to that information so I saw no need to repeat it @Thorbjørn MyConfig is just a simple sample of a class of which all members have as requirement they need to be read from and written to within the application, hence needing both getters and setters. Or, if no validation/whatever required, are suitable candidates for making them public and omitting the getters/setters. –  stijn Mar 13 '11 at 10:11
2  
@stjin: But if you're condemning X, you should at least mention that there are legimitmate use cases (assmuning there are, of course). Your answer as-is, on its own, is barely better than "you must always write getter/setters", as it implies getters/setter have no reason to exist. Also, the validity of a struct-like class is questionable from a pure OOP perspective. –  delnan Mar 13 '11 at 10:20
4  
Don't be so hard on the professors. There are valid educational reasons for enforcing rules that are almost always valid. I'd consider "never make variables public, except if the class/struct is a bundle of related data with no behavior" a good rule. Once the student is experienced enough, he or she will know why the rules are there and when to break them. –  David Thornley Feb 8 '12 at 14:54
4  
@stijn: This question is all about OOP. Asking this question outside the context of OOP is pointless. Your answer comes down to "No, not all fields must have accessors. Look at how this piece of bad code becomes even worse when I add them." Your example is extremely bad to start with in a question tagged "best-practices". –  back2dos Feb 8 '12 at 16:31
show 7 more comments

In general yes, I and many others make exceptions for DTO's see this short blogpost by uncle Bob Martin.

If all you are doing is making private variables and using getters and setters you might want to think about why you are doing this ? There are a lot of people who say that getters and setters are evil, see this article or this article by Alan Holub. From that article:

Summing up

Let's pull everything together: You shouldn't use accessor methods (getters and setters) unless absolutely necessary because these methods expose information about how a class is implemented and as a consequence make your code harder to maintain. Sometimes get/set methods are unavoidable, but an experienced OO designer could probably eliminate 99 percent of the accessors currently in your code without much difficulty.

Getter/setter methods often make their way in code because the coder was thinking procedurally. The best way to break out of that procedural mindset is to think in terms of a conversation between objects that have well-defined responsibilities. Cunningham's CRC card approach is a great way to get started.

share|improve this answer
9  
Exactly. The first question should not be "how do I give access to these variables" but "why am I giving access to these variables?" –  Dave DuPlantis Aug 3 '11 at 20:17
    
Dave u are right. And Kees the example with Uncle Bob is exciting ;-) I would allways declare variables private and let them be accessable by Properties. Its part of a good coding to do that. –  Smokefoot Feb 8 '12 at 17:11
add comment

There is a very good reason to use getters and setters in Java instead of having public fields.

The reason is because you should always code to interfaces, and interfaces do not allow specifying fields but only methods.

share|improve this answer
4  
To quote the accepted answer: "Professors saying "ALWAYS do this or that" in regard to programming should be fired, or go back to school themselves." –  Ant Mar 13 '11 at 10:31
2  
@Ant, 1) good I'm not a professor, 2) please note the word "should". Java programmers not knowing why they should be coding to interfaces, are in my opinion unexperienced. –  user1249 Mar 13 '11 at 16:05
2  
Stressing should makes no difference to the sentence; if you'd said "should usually" that'd be different. Java programmers always doing things, regardless of the situation, is why the language has such a bad reputation for being a cesspool of bloated crapware. –  Ant Mar 13 '11 at 22:35
1  
@Ant, you wouldn't happen to be an inexperienced Java progammer? –  user1249 Mar 13 '11 at 22:50
    
Getters and setters do not always indicate proper object orientation‌​. Though that very much depends on the language. –  mario Mar 14 '11 at 2:14
show 1 more comment

As you put it yourself:

But here's the problem: it's tedious work.[emphasis mine] I tend to quickly loose interest in a project every time I need to have a variable in a class that could have simply been declared public instead of private with a getter and a setter.

You are getting around the tedious work by trying to argue it's necessity out of existence, rather than making it less tedious, which basically means working around the problem instead of solving it. To solve it:

Use the right tools and use them right

If creating plain accessors is too much work, then your current toolset needs improvement.
In fact, any time there is some tedious work, your toolset needs improvement.

For many languages, there's some sort of syntactic sugar available to create accessors or you can use preprocessors for that and most IDEs provide code snippets/code generators. In fact in any decent IDE it is a matter of one keystroke to convert a public field into a private one with accessors.

I could provide a rather lengthy explanation on why using public fields completely violates OOP. At the same time, OOP is not the ultimate truth and it is sometimes better to consciously choose an alternative, if you know what you're doing and the circumstances are right. So yes, there are cases where using plain public fields is ok.
This however is no such case, because you are not making this decision based on any sort of technical constraints, but only because your workflow needs optimization.

share|improve this answer
    
Given a type which holds nothing but public fields, it is very easy to look at the data structure and know how it will behave. In .net, that is especially true of the data structure is a struct and the only heap references contained therein either refer to immutable objects, or else are used semantically to hold the identity of objects rather than their properties. Value-types which mutate this in any context other than property setters can cause problems, but since compilers no longer allow stupid code like SomeList[4].X=6; value types with exposed fields are safe and useful. –  supercat Jul 13 '12 at 21:33
    
@supercat: What's your point exactly? –  back2dos Jul 15 '12 at 13:10
    
If a member is declared as a public field, such declaration says that a read or write that member does not now, and will not ever, do anything other than change that member. If one is using an IDE which auto-generates verbose source code for getters/setters, someone using the object would have to look closely at the source code to be certain the getters/setters don't do anything other than read/write the field. Even if one is using a language with "auto-generated" properties, users of the class wouldn't know whether future versions of the class might do something beyond read/write the field. –  supercat Jul 16 '12 at 14:59
    
A type like Rectangle, which has four exposed fields, poses no mysteries regarding fundamental semantics. If it didn't expose any fields, one would have to examine the code for the type to find out whether e.g. changing the X coordinate of a Rectangle would leave the width constant, or change the width so as to keep the right edge constant. –  supercat Jul 16 '12 at 15:06
    
@supercat: If you make any assumption about how the property X is read/written, then you're breaching the abstraction barrier and thus violating encapsulation. You blur your separation of concerns, and throw your modularity overboard. This is fine, if you want to operate on structs/records in a procedural or functional manner, but it goes totally against OOP, which is all I said. This might be a good choice, but my point was, this is not the choice being made here. The choice here was giving in to laziness or not. –  back2dos Jul 16 '12 at 16:04
show 3 more comments

Java, differently from other languages like Ruby, differentiate between direct access to a property and acces to a property through accessors/mutators. Good object-oriented practice says that you should, whenever possible, hide the internal state of an object from the outside. Meaning, the internal representation of the data should not be directly manipulated by external objects. The reason is that you could apply some logic to the value before the action is taked (ie: validate it, cleanup a string, format the return, ...). The problem is that most of people think that "POJO"s should be "as clean as possible", and end up implementing these validations/formattings/cleanup elsewhere, leaving the POJOs dumb and tedious to write.

That said, I recently came accross a library called "lombok", which allows me to write just the properties and it'll generate the getters/setters on-the-fly. If I need to do some extra logic in any accessor/mutator, I just do the actual implementation for it and lombok will ignore that specific method.

share|improve this answer
add comment

Exposing members whether as public fields or through simple getter and setters goes against the original ideas of OO.

If you are modelling values and not objects there might be reason to model them as values.

Puristically speaking objects are about behaviour any member variable is an implementation detail and no value is part of the behaviour. So if you wish to do puristic OO every time you want to create a setter or getter, you should ask your self questions about your design seeing that the need for getters and setters (when not talking about values as oppossed to objects) is a smell that you are not modelling what the system does (behaviour) but what it is (data). A paradigm that focuses on the separation of these concepts is DCI

share|improve this answer
    
Smalltalk is not "the original ideas of OO." Remember, the original OO language was Simula, not Smalltalk. Smalltalk took the basic concepts of Simula and mixed a bunch of weird, overly-complicated stuff into it until they had something that hardly looked like real OOP at all anymore. There's a reason why the all major OO languages today use the Simula model. (Except for Objective-C, which nobody uses unless Apple's forcing them to, of course.) –  Mason Wheeler Feb 8 '12 at 18:49
    
@Mason I wasn't referring to the Smalltalk part but to the Alan Kay part and he sure was part instrumental to the original ideas of OO. It was he, after all, that coined the term –  Rune FS Feb 8 '12 at 19:15
add comment

Always is a very strong word, and I would avoid it. If its just a matter of the typing thats what keyboard macros are for. Write a small script that will take a java source fill find all the public vars convert them to private and write the getters and setters for you.

I find that it is always a good idea to automate the boring and boiler plate parts of the job. It improves code quality because the dull stuff is done by the computer.

Just remember the following:

  1. Source code is just data

  2. Programs manipulate data

  3. Write a program to manipulate your data in useful ways!

Good luck!

share|improve this answer
add comment

The point with getters/setters vs. public variables is separation of concerns. Internal variables are an implementation detail of a class and thus should not be seen from outside.

What should be visible from outside is the properties that are handled by the class, and these properties may not have a one-to-one matching with internal variables.

For instance a class may handle a 'temperature' property. An internal variable may be linked to this temperature but users should make no assumption of what represent the value stored in that variable: °C, °F, °K, or even, depending on the sensor, raw measure expressed in: mm, V...

Getters and setters should apply to properties, not internal variables, thus allowing calibration or conversion functions to be included.

That way, class internals may change without updating its interface and all other components depending on that class.

share|improve this answer
add comment

After reading some answers my first point would be that in this context I do not believe should is the same as saying must which is not the same as saying have to, I think you are perhaps over emphasizing always.

  • should implies there this is a generalized consensus that this is a better or more appropriate approach
    • you should always declare your members private
  • must implies that this is the way it is done
    • you must always declare your members private
  • have to implies no other option
    • you have to always declare your members private

Indeed in all three examples (particularly given the circumstance from which this question derived) one would and IMO should (though neither must or have to) query any statement put to them, this is how you program the best computer of all. For example if someone was to say you should always do something despite the fact you know that this time doing so would be detrimental would you do it without questioning their rational?

I imagine in this case your tutor (quite probably for ease) has surmised to you, a better practice which indeed I (and perhaps many others) would agree with. The question I feel should never be why make a member private but in fact the inverse as to why make it public, taking as an example facebook, people clearly like to publicize information about themselves but, even then, maybe just my friends can see this, my family can see that, and you who I don't know can't see anything.

Bringing this back to OOP and in particular Java, one of the main reasons for getters and setters is IMO (and I may be wrong) a case of good semantic practice, you obj.getState() and obj.setState() as opposed to obj.state and obj.state = 'foo', in both cases I would argue the process of doing so is imperative. I'd like to think object orientation is not solely about breaking away from this paradigm but among others encapsulating data and function into a reusable component. If we didn't hide anything do we just end up with some namespace for storing data and methods?

Another key point I believe boils down to overriding, classes inheriting from a super class containing public variables is now stuck with a public variable which to me sounds as though this could lead to a decrease in re-usability. By using getters and setters you have provided a way for sub-classes to override access to your variables, maybe add that bit of validation you never bothered with.

As for it being tedious regarding writing getters and setters this is really null and void as I think most IDE's will do much of this for you (and as I have just found lombok which looks pretty cool and reminds me of @property etc in objective-c)

In short yes you should always use private members unless you have a good reason not to (DTO's would be, to some extent, a reasonable exception)

share|improve this answer
    
I also believe other benefits of always using private variables would be when refactoring some fundamental logic that needs to be applied everywhere (you only have to update your getters and setters), and quite possibly benefit concurrency though I am not sure about these two –  T I Feb 8 '12 at 16:22
add comment

The reason why you always have to implement getters and setters is because everybody tells you to (sane people call that a Dogma). In the 10 years I program Java, probably 99 percent of the properties I used are publicly available through getters and setters, so in practice they ARE public. We facilitate the exception, instead of the rule.

share|improve this answer
6  
Hi Pierre could you please tone it down a bit? There is some valuable insight in your answer, but we would prefer all posts to be written in a more... professional tone. –  Yannis Rizos Feb 8 '12 at 14:07
4  
it's a shame that the true parts in this answers is hidden behind slanter and profanity –  Rune FS Feb 8 '12 at 14:10
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.