What's the advantage of using getters and setters - that only get and set - instead of simply using public fields for those variables?

If getters and setters are ever doing more than just the simple get/set, I can figure this one out very quickly, but I'm not 100% clear on how:

public String foo;

is any worse than:

private String foo;public void setFoo(String foo) { this.foo=foo; }public String getFoo() { return foo; }

Whereas the former takes a lot less boilerplate code.

share|improve this question

closed as primarily opinion-based by Jarrod Roberson, Machavity, Paul Roub, Steve, Olaf Nov 13 '17 at 15:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    @Dean J: Duplicate with many other questions: stackoverflow.com/search?q=getters+setters– AsaphOct 14 '09 at 18:26
  • 8
    Of course, both are equally bad when the object doesn't need a property to be changed. I'd rather make everything private, and then add getters if useful, and setters if needed.– TordekOct 14 '09 at 18:29
  • 23
    Google "accessors are evil"– OMG PoniesOct 14 '09 at 18:45
  • 31
    "Accessors are evil" if you happen to be writing functional code or immutable objects. If you happen to be writing stateful mutable objects, then they are pretty essential.– Christian HayterOct 14 '09 at 19:10
  • 17
    Tell, don't ask. pragprog.com/articles/tell-dont-ask– Dave JarvisOct 14 '09 at 22:18

38 Answers38

up vote742down voteaccepted

There are actually many good reasons to consider using accessors rather than directly exposing fields of a class - beyond just the argument of encapsulation and making future changes easier.

Here are the some of the reasons I am aware of:

  • Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
  • Hiding the internal representation of the property while exposing a property using an alternative representation.
  • Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without affecting existing consumers.
  • Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
  • Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
  • Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
  • Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
  • Allowing the getter/setter to be passed around as lambda expressions rather than values.
  • Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.
share|improve this answer
  • 34
    +1. Just to add: Allowing lazy loading. Allowing copy on write.– NewbiZOct 16 '09 at 23:41
  • 4
    @bjarkef: I believe public accessor methods cause code duplication, and expose information. Public accessors are not necessary for marshalling (serialization). In some languages (Java), public get accessors cannot have the return type changed without breaking dependent classes. Moreover, I believe they run counter to OO principles. See also: stackoverflow.com/a/1462424/59087– Dave JarvisMar 5 '12 at 20:09
  • 15
    @sbi: One thing that is bought by using a property setter, even in a well-designed framework, is the ability to have an object notify another when a property changes.– supercatAug 23 '12 at 21:48
  • 17
    @supercat: However, I am not, generally, promoting public data. Notification of other objects can just as well be done from real methods providing a significant abstraction on a mere data container with (more or less) public data fields. Instead of plane.turnTo(dir); plane.setSpeed(spd); plane.setTargetAltitude(alt); plane.getBreaks().release(); I want to say plane.takeOff(alt). What inner data fields need to be changed in order to put the plane into the takingOff mode is none of my concerns. And what other objects (breaks) the method notifies I don't want to know either.– sbiAug 24 '12 at 9:35
  • 5
    @BenLee: I really don't know how else to say it. "Accessors" is just a synonym for "getters/setters", and in my first two comments I explained why those are an abuse of the term "OOP". If you need to reach into it and manipulate the state directly, it's not an object in the OOP sense of that term.– sbiDec 5 '12 at 8:22

In an object oriented language the methods, and their access modifiers, declare the interface for that object. Between the constructor and the accessor and mutator methods it is possible for the developer to control access to the internal state of an object. If the variables are simply declared public then there is no way to regulate that access.And when we are using setters we can restrict the user for the input we need. Mean the feed for that very variable will come through a proper channel and the channel is predefined by us. So it's safer to use setters.

share|improve this answer

    Getters and setters coming from data hiding. Data Hiding means Weare hiding data from outsiders or outside person/thing cannot accessour data.This is a useful feature in OOP.

    As a example:

    If you create a public variable, you can access that variable and change value in anywhere(any class). But if you create as private that variable cannot see/access in any class except declared class.

    public and private are access modifiers.

    So how can we access that variable outside:

    This is the place getters and setters coming from. You can declare variable as private then you can implement getter and setter for that variable.

    Example(Java):

    private String name;public String getName(){return this.name;}public void setName(String name){this.name=name;}

    Advantage:

    When anyone want to access or change/set value to balance variable, he/she must have permision.

    //assume we have person1 object//to give permission to check balanceperson1.getName()//to give permission to set balanceperson1.setName()

    You can set value in constructor also but when later on when you wantto update/change value, you have to implement setter method.

    share|improve this answer
    • your getBalance/setBalance aren't getter/setter if they have other code, are they? Also why expose balance? Wouldn't it be safer to have an applyPayment or applyDebt that allowed balance checking and maybe a memo field to say where the payment was from? Hey! I just improved your design AND removed the setter and getter. That's the thing about setters/getters, it pretty much always improves your code to remove them, not that they are "Wrong", just that they nearly always lead to worse code. Properties (as in C#), by the way, have exactly the same issue.– Bill KMay 1 '17 at 16:57

    In a pure object-oriented world getters and setters is a terrible anti-pattern. Read this article: Getters/Setters. Evil. Period. In a nutshell, they encourage programmers to think about objects as of data structures, and this type of thinking is pure procedural (like in COBOL or C). In an object-oriented language there are no data structures, but only objects that expose behavior (not attributes/properties!)

    You may find more about them in Section 3.5 of Elegant Objects (my book about object-oriented programming).

    share|improve this answer
    • 6
      Getters and setters suggest an anaemic domain model.– RaedwaldDec 12 '14 at 8:31
    • 4
      Interesting viewpoint. But in most programming contexts what we need is data structures. Taking the linked article's "Dog" example. Yes, you can't change a real-world dog's weight by setting an attribute ... but a new Dog() is not a dog. It is object that holds information about a dog. And for that usage, it is natural to be able to correct an incorrectly recorded weight.– Stephen CJul 1 '16 at 7:29
    • 1
      @StephenC that's exactly how procedural languages teach us to think. Object thinking is absolutely opposite. The object doesn't hold information about a dog. The object is a dog. This book of mine may help: Elegant Objects– yegor256Jul 1 '16 at 22:41
    • 2
      Well, I put it to you that most useful programs don't need to model / simulate real world objects. IMO, this is not really about programming languages at all. It is about what we write programs for.– Stephen CJul 2 '16 at 0:34
    • 2
      Real world or not, yegor is completely right. If what you have is truly a "Struct" and you don't need to write any code that references it by name, put it in a hashtable or other data structure. If you do need to write code for it then put it as a member of a class and put the code that manipulates that variable in the same class and omit the setter & getter. PS. although I mostly share yegor's viewpoint, I have come to believe that annotated beans without code are somewhat useful data structures--also getters are sometimes necessary, setters shouldn't ever exist.– Bill KMay 1 '17 at 16:51

    One relatively modern advantage of getters/setters is that is makes it easier to browse code in tagged (indexed) code editors. E.g. If you want to see who sets a member, you can open the call hierarchy of the setter.

    On the other hand, if the member is public, the tools don't make it possible to filter read/write access to the member. So you have to trudge though all uses of the member.

    share|improve this answer

      I know it's a bit late, but I think there are some people who are interested in performace :)

      I've done a little performance test. I wrote a class "NumberHolder" which, well, holds an Integer. You can either read that Integer by using the getter methodanInstance.getNumber() or by directly accessing the number by using anInstance.number. My programm reads the number 1,000,000,000 times, via both ways. That process is repeated five times and the time is printed. I've got the following result:

      Time 1: 953ms, Time 2: 741msTime 1: 655ms, Time 2: 743msTime 1: 656ms, Time 2: 634msTime 1: 637ms, Time 2: 629msTime 1: 633ms, Time 2: 625ms

      (Time 1 is the direct way, Time 2 is the getter)

      You see, the getter is (almost) always a bit faster. Then I tried with different numbers of cycles. Instead of 1 million, I used 10 million and 0.1 million.The results:

      10 million cycles:

      Time 1: 6382ms, Time 2: 6351msTime 1: 6363ms, Time 2: 6351msTime 1: 6350ms, Time 2: 6363msTime 1: 6353ms, Time 2: 6357msTime 1: 6348ms, Time 2: 6354ms

      With 10 million cycles, the times are almost the same.Here are 100 thousand (0.1 million) cycles:

      Time 1: 77ms, Time 2: 73msTime 1: 94ms, Time 2: 65msTime 1: 67ms, Time 2: 63msTime 1: 65ms, Time 2: 65msTime 1: 66ms, Time 2: 63ms

      Also with different amounts of cycles, the getter is a little bit faster than the regular way. I hope this helped you! :)

      By the way, I am a german seventh grade, using my own knowledge and Google Translator. So don't be so strict with my english ;)

      share|improve this answer
      • 1
        There's a "noticable" overhead having a function call to access the memory instead of simply loading an object's address and adding an offset to access the members. Chances are the VM flat-optimized your getter anyway. Regardless, the mentioned overhead isn't worth losing all the benefits of getters/setters.– AlexSep 6 '16 at 17:28

      Getters and setters are used to implement two of the fundamental aspects of Object Oriented Programming which are:

      1. Abstraction
      2. Encapsulation

      Suppose we have an Employee class:

      package com.highmark.productConfig.types;public class Employee {private String firstName;private String middleName;private String lastName;public String getFirstName() {return firstName;}public void setFirstName(String firstName) {this.firstName=firstName;}public String getMiddleName() {return middleName;}public void setMiddleName(String middleName) {this.middleName=middleName;}public String getLastName() {return lastName;}public void setLastName(String lastName) {this.lastName=lastName;}public String getFullName(){return this.getFirstName() + this.getMiddleName() + this.getLastName();}}

      Here the implementation details of Full Name is hidden from the user and is not accessible directly to the user, unlike a public attribute.

      share|improve this answer
      • 1
        To me having tons of getters and setters that do nothing unique is useless. getFullName is a exception because it does something else. Having just the three variables public then keeping getFullName will make the program easier to read but still have that fullname thing hidden. Generally I'm completely fine with getters and setters if a. they do something unique and/or b. you only have one, yeah you could have a public final and all that but nah– FacelessTigerDec 14 '16 at 1:06
      • 1
        The benefit with this is that you can change the internals of the class, without changing the interface. Say, instead of three properties, you had one - an array of strings. If you've been using getters and setters, you can make that change, and then update the getter/setters to know that names[0] is first name, names[1] is middle, etc. But if you just used public properties, you would also have to change every class accessed Employee, because the firstName property they've been using no longer exists.– Andrew HowsDec 8 '17 at 0:42

      Although not common for getter and setter, the use of these methods can also be used in AOP/proxy pattern uses.eg for auditing variable you can use AOP to audit update of any value.Without getter/setter it's not possible except changing the code everywhere.Personaly I have never used AOP for that, but it shows one more advantage of using getter/setter.

      share|improve this answer

        EDIT: I answered this question because there are a bunch of people learning programming asking this, and most of the answers are very technically competent, but they're not as easy to understand if you're a newbie. We were all newbies, so I thought I'd try my hand at a more newbie friendly answer.

        The two main ones are polymorphism, and validation. Even if it's just a stupid data structure.

        Let's say we have this simple class:

        public class Bottle {public int amountOfWaterMl;public int capacityMl;}

        A very simple class that holds how much liquid is in it, and what its capacity is (in milliliters).

        What happens when I do:

        Bottle bot=new Bottle();bot.amountOfWaterMl=1500;bot.capacity=1000;

        Well, you wouldn't expect that to work, right?You want there to be some kind of sanity check. And worse, what if I never specified the maximum capacity? Oh dear, we have a problem.

        But there's another problem too. What if bottles were just one type of container? What if we had several containers, all with capacities and amounts of liquid filled? If we could just make an interface, we could let the rest of our program accept that interface, and bottles, jerrycans and all sorts of stuff would just work interchangably. Wouldn't that be better? Since interfaces demand methods, this is also a good thing.

        We'd end up with something like:

        public interface LiquidContainer {public int getAmountMl();public void setAmountMl(int amountMl);public int getCapacityMl();public void setCapcityMl(int capacityMl);}

        Great! And now we just change Bottle to this:

        public class Bottle extends LiquidContainer {private int capacityMl;private int amountFilledMl;public Bottle(int capacityMl, int amountFilledMl) {this.capacityMl=capacityMl;this.amountFilledMl=amountFilledMl;checkNotOverFlow();}public int getAmountMl() {return amountFilledMl;}public void setAmountMl(int amountMl) {this.amountFilled=amountMl;checkNotOverFlow();}public int getCapacityMl() {return capacityMl;public void setCapcityMl(int capacityMl) {this.capacityMl=capacityMl;checkNotOverFlow();}private void checkNotOverFlow() {if(amountOfWaterMl > capacityMl) {throw new BottleOverflowException();}}

        I'll leave the definition ofthe BottleOverflowException as an exercise to the reader.

        Now notice how much more robust this is. We can deal with any type of container in our code now by accepting LiquidContainer instead of Bottle. And how these bottles deal with this sort of stuff can all differ. You can have bottles that writer their state to disk when it changes, or bottles that save on SQL databases or GNU knows what else.

        And all these can have different ways to handle various whoopsies. The Bottle just checks and if it's overflowing it throws a RuntimeException. But that might be the wrong thing to do. (There is a useful discussion to be had about error handling, but I'm keeping it very simple here on purpose. People in comments will likely point out the flaws of this simplistic approach. ;) )

        And yes, it seems like we go from a very simple idea to getting much better answers quickly.

        There's also the third thing that not everyone has addressed: Getters and setters use method calls. That means that they look like normal methods everywhere else does. Instead of having weird specific syntax for DTOs and stuff, you have the same thing everywhere.

        share|improve this answer
        • 2
          Thanks for the first half-decent explanation of interfaces I've read, sans any references to "remote controls" or "cars"– djvsFeb 10 '16 at 7:41
        • "You can have bottles that writer their state to disk when it changes, or bottles that save on SQL databases" I lolled so hard xD. But anyways, nice idea to present it!– XerusOct 18 '17 at 20:15

        This is a good question with even better answers. As there are a lot of them, I will just put there a little moreThis example is based on C#, just a useful piece of code. Validating data in the brackets were already explained.

        public class foo{public int f1 { get; set; } // A classic GSpublic int f2 { get; private set; } // A GS with public read access, the write is only on the private levelpublic int f3 { private get; set; } // A GS where "You can set, but you can't get" outside the classpublic int f4 { get; set; }=10; // A GS with default value, this is a NEW feature of C# 6.0 / .NET 4.6}
        share|improve this answer
        • In Java you don't have getters and setters like that. What you do have is Project Lombok which uses annotations to much the same effect. So if you want this niceness but in Java and not C#, then you know where to go. :)– Haakon LøtveitDec 16 '15 at 13:37

        A public field is not worse than a getter/setter pair that does nothing except returning the field and assigning to it. First, it's clear that (in most languages) there is no functional difference. Any difference must be in other factors, like maintainability or readability.

        An oft-mentioned advantage of getter/setter pairs, isn't. There's this claim that you can change the implementation and your clients don't have to be recompiled. Supposedly, setters let you add functionality like validation later on and your clients don't even need to know about it. However, adding validation to a setter is a change to its preconditions, a violation of the previous contract, which was, quite simply, "you can put anything in here, and you can get that same thing later from the getter".

        So, now that you broke the contract, changing every file in the codebase is something you should want to do, not avoid. If you avoid it you're making the assumption that all the code assumed the contract for those methods was different.

        If that should not have been the contract, then the interface was allowing clients to put the object in invalid states. That's the exact opposite of encapsulation If that field could not really be set to anything from the start, why wasn't the validation there from the start?

        This same argument applies to other supposed advantages of these pass-through getter/setter pairs: if you later decide to change the value being set, you're breaking the contract. If you override the default functionality in a derived class, in a way beyond a few harmless modifications (like logging or other non-observable behaviour), you're breaking the contract of the base class. That is a violation of the Liskov Substitutability Principle, which is seen as one of the tenets of OO.

        If a class has these dumb getters and setters for every field, then it is a class that has no invariants whatsoever, no contract. Is that really object-oriented design? If all the class has is those getters and setters, it's just a dumb data holder, and dumb data holders should look like dumb data holders:

        class Foo {public:int DaysLeft;int ContestantNumber;};

        Adding pass-through getter/setter pairs to such a class adds no value. Other classes should provide meaningful operations, not just operations that fields already provide. That's how you can define and maintain useful invariants.

        Client: "What can I do with an object of this class?"
        Designer: "You can read and write several variables."
        Client: "Oh... cool, I guess?"

        There are reasons to use getters and setters, but if those reasons don't exist, making getter/setter pairs in the name of false encapsulation gods is not a good thing. Valid reasons to make getters or setters include the things often mentioned as the potential changes you can make later, like validation or different internal representations. Or maybe the value should be readable by clients but not writable (for example, reading the size of a dictionary), so a simple getter is a nice choice. But those reasons should be there when you make the choice, and not just as a potential thing you may want later. This is an instance of YAGNI (You Ain't Gonna Need It).

        share|improve this answer
        • 9
          Great answer (+1). My only criticism is that it took me several reads to figure out how "validation" in the final paragraph differed from "validation" in the first few (which you threw out in the latter case but promoted in the former); adjusting the wording might help in that regard.– Lightness Races in OrbitJul 6 '13 at 21:12
        • 12
          This is a great answer but alas the current era has forgotten what "information hiding" is or what it is for. They never read about immutability and in their quest for most-agile, never drew that state-transition-diagram that defined what the legal states of an object were and thus what were not.– Darrell TeagueNov 6 '13 at 14:58
        • 1
          A key observation is that getters are much more useful than setters. A getter can return a computed value, or a cached computed value. All a setter can do is some validation and than change the private field. If a class has no setters it is easy to make it immutable.– RaedwaldDec 12 '14 at 8:38
        • 4
          Er, I guess you don't know what a class invariant is. If it is a non-trivial structure, it pretty much means that it has invariants to uphold and one simply cannot design it without those in mind. "There was a bug, one member was updated wrong." also pretty much reads like "A member update violated the class invariants". A well designed class does not allow client code to violate its invariants.– R. Martinho FernandesAug 5 '15 at 8:25
        • 2
          +1 for 'dumb data holders should look like dumb data holders' Unfortunately, everybody seems to design everything around dumb data holders these days, and lots of frameworks even require it...– Joeri HendrickxAug 29 '16 at 6:53

        It can be useful for lazy-loading. Say the object in question is stored in a database, and you don't want to go get it unless you need it. If the object is retrieved by a getter, then the internal object can be null until somebody asks for it, then you can go get it on the first call to the getter.

        I had a base page class in a project that was handed to me that was loading some data from a couple different web service calls, but the data in those web service calls wasn't always used in all child pages. Web services, for all of the benefits, pioneer new definitions of "slow", so you don't want to make a web service call if you don't have to.

        I moved from public fields to getters, and now the getters check the cache, and if it's not there call the web service. So with a little wrapping, a lot of web service calls were prevented.

        So the getter saves me from trying to figure out, on each child page, what I will need. If I need it, I call the getter, and it goes to find it for me if I don't already have it.

         protected YourType _yourName=null;public YourType YourName{get{if (_yourName==null){_yourName=new YourType();return _yourName;}}}
        share|improve this answer
        • So then does the getter call the setter?– icc97Sep 17 '14 at 20:24
        • I've added a code sample of how I've done it in the past - essentially, you store the actual class in a protected member, then return that protected member in the get accessor, initializing it if it is not initialized.– quillbreakerSep 19 '14 at 18:20
        • what is this? Definitely not runnable java code ^^– XerusOct 18 '17 at 20:06

        You should use getters and setters when:

        • You're dealing with something that is conceptually an attribute, but:
          • Your language doesn't have properties (or some similar mechanism, like Tcl's variable traces), or
          • Your language's property support isn't sufficient for this use case, or
          • Your language's (or sometimes your framework's) idiomatic conventions encourage getters or setters for this use case.

        So this is very rarely a general OO question; it's a language-specific question, with different answers for different languages (and different use cases).


        From an OO theory point of view, getters and setters are useless. The interface of your class is what it does, not what its state is. (If not, you've written the wrong class.) In very simple cases, where what a class does is just, e.g., represent a point in rectangular coordinates,* the attributes are part of the interface; getters and setters just cloud that. But in anything but very simple cases, neither the attributes nor getters and setters are part of the interface.

        Put another way: If you believe that consumers of your class shouldn't even know that you have a spam attribute, much less be able to change it willy-nilly, then giving them a set_spam method is the last thing you want to do.

        * Even for that simple class, you may not necessarily want to allow setting the x and y values. If this is really a class, shouldn't it have methods like translate, rotate, etc.? If it's only a class because your language doesn't have records/structs/named tuples, then this isn't really a question of OO…


        But nobody is ever doing general OO design. They're doing design, and implementation, in a specific language. And in some languages, getters and setters are far from useless.

        If your language doesn't have properties, then the only way to represent something that's conceptually an attribute, but is actually computed, or validated, etc., is through getters and setters.

        Even if your language does have properties, there may be cases where they're insufficient or inappropriate. For example, if you want to allow subclasses to control the semantics of an attribute, in languages without dynamic access, a subclass can't substitute a computed property for an attribute.

        As for the "what if I want to change my implementation later?" question (which is repeated multiple times in different wording in both the OP's question and the accepted answer): If it really is a pure implementation change, and you started with an attribute, you can change it to a property without affecting the interface. Unless, of course, your language doesn't support that. So this is really just the same case again.

        Also, it's important to follow the idioms of the language (or framework) you're using. If you write beautiful Ruby-style code in C#, any experienced C# developer other than you is going to have trouble reading it, and that's bad. Some languages have stronger cultures around their conventions than others.—and it may not be a coincidence that Java and Python, which are on opposite ends of the spectrum for how idiomatic getters are, happen to have two of the strongest cultures.

        Beyond human readers, there will be libraries and tools that expect you to follow the conventions, and make your life harder if you don't. Hooking Interface Builder widgets to anything but ObjC properties, or using certain Java mocking libraries without getters, is just making your life more difficult. If the tools are important to you, don't fight them.

        share|improve this answer

          There is a good reason to consider using accessors is there is no property inheritance. See next example:

          public class TestPropertyOverride {public static class A {public int i=0;public void add() {i++;}public int getI() {return i;}}public static class B extends A {public int i=2;@Overridepublic void add() {i=i + 2;}@Overridepublic int getI() {return i;}}public static void main(String[] args) {A a=new B();System.out.println(a.i);a.add();System.out.println(a.i);System.out.println(a.getI());}}

          Output:

          004
          share|improve this answer

            One relatively modern advantage of getters/setters is that is makes it easier to browse code in tagged (indexed) code editors. E.g. If you want to see who sets a member, you can open the call hierarchy of the setter.

            On the other hand, if the member is public, the tools don't make it possible to filter read/write access to the member. So you have to trudge though all uses of the member.

            share|improve this answer

              If you want a readonly variable but don't want the client to have to change the way they access it, try this templated class:

              template<typename MemberOfWhichClass, typename primative> class ReadOnly {friend MemberOfWhichClass;public:template<typename number> inline bool operator==(const number& y) const { return x==y; } template<typename number> inline number operator+ (const number& y) const { return x + y; } template<typename number> inline number operator- (const number& y) const { return x - y; } template<typename number> inline number operator* (const number& y) const { return x * y; } template<typename number> inline number operator/ (const number& y) const { return x / y; } template<typename number> inline number operator<<(const number& y) const { return x << y; }template<typename number> inline number operator^(const number& y) const { return x^y; }template<typename number> inline number operator~() const { return ~x; }template<typename number> inline operator number() const { return x; }protected:template<typename number> inline number operator=(const number& y) { return x=y; } template<typename number> inline number operator+=(const number& y) { return x +=y; } template<typename number> inline number operator-=(const number& y) { return x -=y; } template<typename number> inline number operator*=(const number& y) { return x *=y; } template<typename number> inline number operator/=(const number& y) { return x /=y; } primative x; }; 

              Example Use:

              class Foo {public:ReadOnly<Foo, int> cantChangeMe;};

              Remember you'll need to add bitwise and unary operators as well! This is just to get you started

              share|improve this answer
              • Please note that the question was asked without a specific language in mind.– Hubert GrzeskowiakAug 1 '16 at 9:59

              We use getters and setters:

              • for reusability
              • to perform validation in later stages of programming

              Getter and setter methods are public interfaces to access private class members.


              Encapsulation mantra

              The encapsulation mantra is to make fields private and methods public.

              Getter Methods: We can get access to private variables.

              Setter Methods: We can modify private fields.

              Even though the getter and setter methods do not add new functionality, we can change our mind come back later to make that method

              • better;
              • safer; and
              • faster.

              Anywhere a value can be used, a method that returns that value can be added. Instead of:

              int x=1000 - 500

              use

              int x=1000 - class_name.getValue();

              In layman's terms

              Representation of "Person" class

              Suppose we need to store the details of this Person. This Person has the fields name, age and sex. Doing this involves creating methods for name, age and sex. Now if we need create another person, it becomes necessary to create the methods for name, age, sex all over again.

              Instead of doing this, we can create a bean class(Person) with getter and setter methods. So tomorrow we can just create objects of this Bean class(Person class) whenever we need to add a new person (see the figure). Thus we are reusing the fields and methods of bean class, which is much better.

              share|improve this answer

                I can think of one reason why you wouldn't just want everything public.

                For instance, variable you never intended to use outside of the class could be accessed, even irdirectly via chain variable access (i.e. object.item.origin.x ).

                By having mostly everything private, and only the stuff you want to extend and possibly refer to in subclasses as protected, and generally only having static final objects as public, then you can control what other programmers and programs can use in the API and what it can access and what it can't by using setters and getters to access the stuff you want the program, or indeed possibly other programmers who just happen to use your code, can modify in your program.

                share|improve this answer
                • A clear example of this is when setting one attribute's value affects one or more other attribute values. Trivial example: Say you store the radius of a circle Using circ.set_radius()` doesn't really achieve anything setting radius directly through circ.radius doesn't. However, get_diameter(), get_circumference() and get_area() can perform calculations based on radius. Without getters, you have to perform the calculations yourself and check that you've got them right.– Agi HammerthiefDec 18 '14 at 20:37

                I will let the code speak for itself:

                Mesh mesh=new Mesh();BoundingVolume vol=new BoundingVolume();mesh.boundingVolume=vol;vol.mesh=mesh;vol.compute(); 

                Do you like it? Here is with the setters:

                Mesh mesh=new Mesh();BoundingVolume vol=new BoundingVolume();mesh.setBoundingVolume(vol);
                share|improve this answer
                • 3
                  You did not answer the question which was: "What's the advantage of using getters and setters - that only get and set ..." Your example is not this case, and therefor you answer does not apply to this question.– AgileProOct 28 '14 at 0:33
                • I think the semantics of the given code samples are totally different. The first sample also creates a circular reference: mesh.boundingVolume.mesh==mesh– Hubert GrzeskowiakAug 1 '16 at 9:58

                Code evolves. private is great for when you need data member protection. Eventually all classes should be sort of "miniprograms" that have a well-defined interface that you can't just screw with the internals of.

                That said, software development isn't about setting down that final version of the class as if you're pressing some cast iron statue on the first try. While you're working with it, code is more like clay. It evolves as you develop it and learn more about the problem domain you are solving. During development classes may interact with each other than they should (dependency you plan to factor out), merge together, or split apart. So I think the debate boils down to people not wanting to religiously write

                int getVar() const { return var ; }

                So you have:

                doSomething( obj->getVar() ) ;

                Instead of

                doSomething( obj->var ) ;

                Not only is getVar() visually noisy, it gives this illusion that gettingVar() is somehow a more complex process than it really is. How you (as the class writer) regard the sanctity of var is particularly confusing to a user of your class if it has a passthru setter -- then it looks like you're putting up these gates to "protect" something you insist is valuable, (the sanctity of var) but yet even you concede var's protection isn't worth much by the ability for anyone to just come in and set var to whatever value they want, without you even peeking at what they are doing.

                So I program as follows (assuming an "agile" type approach -- ie when I write code not knowing exactly what it will be doing/don't have time or experience to plan an elaborate waterfall style interface set):

                1) Start with all public members for basic objects with data and behavior. This is why in all my C++ "example" code you'll notice me using struct instead of class everywhere.

                2) When an object's internal behavior for a data member becomes complex enough, (for example, it likes to keep an internal std::list in some kind of order), accessor type functions are written. Because I'm programming by myself, I don't always set the member private right away, but somewhere down the evolution of the class the member will be "promoted" to either protected or private.

                3) Classes that are fully fleshed out and have strict rules about their internals (ie they know exactly what they are doing, and you are not to "fuck" (technical term) with its internals) are given the class designation, default private members, and only a select few members are allowed to be public.

                I find this approach allows me to avoid sitting there and religiously writing getter/setters when a lot of data members get migrated out, shifted around, etc. during the early stages of a class's evolution.

                share|improve this answer
                • 1
                  "... a well-defined interface that you can't just screw with the internals of" and validation in setters.– Agi HammerthiefDec 18 '14 at 20:45

                Getter and setter methods are accessor methods, meaning that they are generally a public interface to change private class members. You use getter and setter methods to define a property. You access getter and setter methods as properties outside the class, even though you define them within the class as methods. Those properties outside the class can have a different name from the property name in the class.

                There are some advantages to using getter and setter methods, such as the ability to let you create members with sophisticated functionality that you can access like properties. They also let you create read-only and write-only properties.

                Even though getter and setter methods are useful, you should be careful not to overuse them because, among other issues, they can make code maintenance more difficult in certain situations. Also, they provide access to your class implementation, like public members. OOP practice discourages direct access to properties within a class.

                When you write classes, you are always encouraged to make as many as possible of your instance variables private and add getter and setter methods accordingly. This is because there are several times when you may not want to let users change certain variables within your classes. For example, if you have a private static method that tracks the number of instances created for a specific class, you don't want a user to modify that counter using code. Only the constructor statement should increment that variable whenever it's called. In this situation, you might create a private instance variable and allow a getter method only for the counter variable, which means users are able to retrieve the current value only by using the getter method, and they won't be able to set new values using the setter method. Creating a getter without a setter is a simple way of making certain variables in your class read-only.

                share|improve this answer

                  Thanks, that really clarified my thinking. Now here is (almost) 10 (almost) good reasons NOT to use getters and setters:

                  1. When you realize you need to do more than just set and get the value, you can just make the field private, which will instantly tell you where you've directly accessed it.
                  2. Any validation you perform in there can only be context free, which validation rarely is in practice.
                  3. You can change the value being set - this is an absolute nightmare when the caller passes you a value that they [shock horror] want you to store AS IS.
                  4. You can hide the internal representation - fantastic, so you're making sure that all these operations are symmetrical right?
                  5. You've insulated your public interface from changes under the sheets - if you were designing an interface and weren't sure whether direct access to something was OK, then you should have kept designing.
                  6. Some libraries expect this, but not many - reflection, serialization, mock objects all work just fine with public fields.
                  7. Inheriting this class, you can override default functionality - in other words you can REALLY confuse callers by not only hiding the implementation but making it inconsistent.

                  The last three I'm just leaving (N/A or D/C)...

                  share|improve this answer
                  • 9
                    I think the crucial argument is that, "if you were designing an interface and weren't sure whether direct access to something was OK, then you should have kept designing." That is the most important problem with getters/setters: They reduce a class to a mere container of (more or less) public fields. In real OOP, however, an object is more than a container of data fields. It encapsulates state and algorithms to manipulate that state. What's crucial about this statement is that the state is supposed to be encapsulated and only to be manipulated by the algorithms provided by the object.– sbiAug 24 '12 at 9:29

                  Well i just want to add that even if sometimes they are necessary for the encapsulation and security of your variables/objects, if we want to code a real Object Oriented Program, then we need to STOP OVERUSING THE ACCESSORS, cause sometimes we depend a lot on them when is not really necessary and that makes almost the same as if we put the variables public.

                  share|improve this answer

                    Don't use getters setters unless needed for your current delivery I.e. Don't think too much about what would happen in the future, if any thing to be changed its a change request in most of the production applications, systems.

                    Think simple, easy, add complexity when needed.

                    I would not take advantage of ignorance of business owners of deep technical know how just because I think it's correct or I like the approach.

                    I have massive system written without getters setters only with access modifiers and some methods to validate n perform biz logic. If you absolutely needed the. Use anything.

                    share|improve this answer

                      From a object orientation design standpoint both alternatives can be damaging to the maintenance of the code by weakening the encapsulation of the classes. For a discussion you can look into this excellent article: http://typicalprogrammer.com/?p=23

                      share|improve this answer

                        I wanted to post a real world example I just finished up:

                        background - I hibernate tools to generate the mappings for my database, a database I am changing as I develop. I change the database schema, push the changes and then run hibernate tools to generate the java code. All is well and good until I want to add methods to those mapped entities. If I modify the generated files, they will be overwritten every time I make a change to the database. So I extend the generated classes like this:

                        package com.foo.entities.customclass User extends com.foo.entities.User{public Integer getSomething(){return super.getSomething(); }public void setSomething(Integer something){something+=1;super.setSomething(something); }}

                        What I did above is override the existing methods on the super class with my new functionality (something+1) without ever touching the base class. Same scenario if you wrote a class a year ago and want to go to version 2 without changing your base classes (testing nightmare). hope that helps.

                        share|improve this answer
                        • 4
                          "What I did above is override the existing methods on the super class with my new functionality." With functionality that we all hope was already properly documented for the old interface, right? Otherwise you just violated the LSP and introduced a silent breaking change that would have been caught by the compiler if there were no getters/setters in sight.– R. Martinho FernandesAug 24 '12 at 14:39
                        • @R.MartinhoFernandes "... and then run hibernate tools to generate the java code" this isn't a case of changing the behavior of some class, this is a work around to a shitty tool. Perhaps the contract (which in this case is in the subclass) always was for that "surprise". Could be an argument for has-a instead of is-a though.– PhilOct 29 '13 at 19:15
                        • I fail to see what you achieve by not using the superclass' properties directly.– Agi HammerthiefDec 18 '14 at 20:59

                        I spent quite a while thinking this over for the Java case, and I believe the real reasons are:

                        1. Code to the interface, not the implementation
                        2. Interfaces only specify methods, not fields

                        In other words, the only way you can specify a field in an interface is by providing a method for writing a new value and a method for reading the current value.

                        Those methods are the infamous getter and setter....

                        share|improve this answer
                        • 1
                          Okay, second question; in the case where it's a project where you're not exporting source to anyone, and you have full control of the source... are you gaining anything with getters and setters?– Dean JNov 9 '09 at 15:22
                        • 2
                          In any non-trivial Java project you need to code to interfaces in order to make things manageable and testable (think mockups and proxy objects). If you use interfaces you need getters and setters.– Thorbjørn Ravn AndersenNov 9 '09 at 18:13

                        I would just like to throw the idea of annotation : @getter and @setter. With @getter, you should be able to obj=class.field but not class.field=obj. With @setter, vice versa. With @getter and @setter you should be able to do both. This would preserve encapsulation and reduce the time by not calling trivial methods at runtime.

                        share|improve this answer
                        • 1
                          It would be implemented at runtime with "trivial methods". Actually, probably non-trivial.– PhilOct 29 '13 at 19:11
                        • Today this can be done with an annotation preprocessor.– Thorbjørn Ravn AndersenJan 7 at 19:56

                        Lots of people talk about the advantages of getters and setters but I want to play devil's advocate. Right now I'm debugging a very large program where the programmers decided to make everything getters and setters. That might seem nice, but its a reverse-engineering nightmare.

                        Say you're looking through hundreds of lines of code and you come across this:

                        person.name="Joe";

                        It's a beautifully simply piece of code until you realize its a setter. Now, you follow that setter and find that it also sets person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName, and calls person.update(), which sends a query out to the database, etc. Oh, that's where your memory leak was occurring.

                        Understanding a local piece of code at first glance is an important property of good readability that getters and setters tend to break. That is why I try to avoid them when I can, and minimize what they do when I use them.

                        share|improve this answer
                        • 7
                          Yes. Currently refactoring a large codebase, and this has been a nightmare. The getters and setters do way too much, including calling other very busy getters and setters that end up reducing the readability to nothing. Validation is a great reason for using accessors, but using them to do much more than that seems to remove any potential benefit.– FadecomicMay 14 '12 at 19:56
                        • 19
                          This is argument against syntactic sugar, not against setters in general.– PhilOct 29 '13 at 19:02
                        • 5
                          True and true but moreover, it points how why individual property setters open the door for invalid states with absolutely no remedy for ensuring the integrity of any given object that allows the abstraction to leak.– Darrell TeagueNov 6 '13 at 15:26
                        • "It's a beautifully simply piece of code until you realize its a setter" - hey, was the original post about Java or about C#? :)– Honza ZidekApr 13 '17 at 10:42
                        • I completely agree regarding readability. It's totally explicit what is happening when person.name="Joe"; is called. There's no cruft in the way of the information, syntax highlighting shows it's a field and refactoring is simpler (no need to refactor two methods and a field). Second, all those wasted brain cycles thinking "getIsValid()" or should it be "isValid()" etc. can be forgotten. I can't think of single a time I've been saved from a bug by a getter/setter.– WillOct 18 '17 at 10:41

                        In languages which don't support "properties" (C++, Java) or require recompilation of clients when changing fields to properties (C#), using get/set methods is easier to modify. For example, adding validation logic to a setFoo method will not require changing the public interface of a class.

                        In languages which support "real" properties (Python, Ruby, maybe Smalltalk?) there is no point to get/set methods.

                        share|improve this answer
                        • 1
                          Re: C#. If you add functionality to a get/set wouldn't that require recompilation anyway?– steamer25Oct 14 '09 at 19:11
                        • @steamer25: sorry, mis-typed. I meant that clients of the class will have to be recompiled.– John MillikinOct 14 '09 at 19:14
                        • 5
                          Adding validation logic to a setFoo method will not require changing the interface of a class at the language level, but it does change the actual interface, aka contract, because it changes the preconditions. Why would one want the compiler to not treat that as a breaking change when it is?– R. Martinho FernandesSep 26 '12 at 5:57
                        • @R.MartinhoFernandes how does one fix this "broken" problem? The compiler can't tell if it's breaking or not. This is only a concern when you are writing libraries for others, but you're making it out as universal zOMG here be dragons!– PhilOct 29 '13 at 19:33
                        • 3
                          Requiring recompilation, as mentioned in the answer, is one way the compiler can make you aware of a possible breaking change. And almost everything I write is effectively "a library for others", because I don't work alone. I write code that has interfaces that other people in the project will use. What's the difference? Hell, even if I will be the user of those interfaces, why should I hold my code to lower quality standards? I don't like working with troublesome interfaces, even if I'm the one writing them.– R. Martinho FernandesOct 30 '13 at 11:02

                        protected by Abhijit Jan 27 '14 at 3:02

                        Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

                        Would you like to answer one of these unanswered questions instead?

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