Why use getters and setters accessors

Question

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

User · Answer

One advantage of accessors and mutators is that you can perform validation.

For example, if foo was public, I could easily set it to null and then someone else could try to call a method on the object. But it's not there anymore! With a setFoo method, I could ensure that foo was never set to null.

Accessors and mutators also allow for encapsulation - if you aren't supposed to see the value once its set (perhaps it's set in the constructor and then used by methods, but never supposed to be changed), it will never been seen by anyone. But if you can allow other classes to see or change it, you can provide the proper accessor and/or mutator.

User · Answer

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

User · Answer

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- gt getVar         Instead of  doSomething  obj- gt 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

User · Answer

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

User · Answer

From my experience  it is ideal to set variables as private and to provide accessors and modifiers to each variable  This way  you can create read only variables  or write only variables depending on your requirements  Below implementation shows a write only variable  private String foo  public void setFoo String foo    this foo   foo    private String getFoo     return foo     Below shows a read only variable  private String foo  private void setFoo String foo    this foo   foo    public String getFoo     return foo

User · Answer

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

User · Answer

Additionally  this is to  future-proof  your class  In particular  changing from a field to a property is an ABI break  so if you do later decide that you need more logic than just  set get the field   then you need to break ABI  which of course creates problems for anything else already compiled against your class

User · Answer

Depends on your language   You ve tagged this  quot object-oriented quot  rather than  quot Java quot   so I d like to point out that ChssPly76 s answer is language-dependent   In Python  for instance  there is no reason to use getters and setters   If you need to change the behavior  you can use a property  which wraps a getter and setter around basic attribute access   Something like this   class Simple object      def  get value self          return self  value -1     def  set value self  new value          self  value   new value   1     def  del value self          self old values append self  value         del self  value     value   property  get value   set value   del value

User · 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

User · Answer

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

User · Answer

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

User · Answer

Getters and setters are used to implement two of the fundamental aspects of Object Oriented Programming which are     Abstraction 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

User · 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 lt typename MemberOfWhichClass  typename primative gt                                         class ReadOnly       friend MemberOfWhichClass  public      template lt typename number gt  inline bool   operator   const number amp  y  const   return x    y         template lt typename number gt  inline number operator   const number amp  y  const   return x   y         template lt typename number gt  inline number operator-  const number amp  y  const   return x - y         template lt typename number gt  inline number operator   const number amp  y  const   return x   y          template lt typename number gt  inline number operator   const number amp  y  const   return x   y         template lt typename number gt  inline number operator lt  lt  const number amp  y  const   return x  lt  lt  y        template lt typename number gt  inline number operator  const number amp  y  const    return x y        template lt typename number gt  inline number operator    const                   return  x        template lt typename number gt  inline operator number   const                    return x    protected      template lt typename number gt  inline number operator   const number amp  y    return x   y               template lt typename number gt  inline number operator   const number amp  y    return x    y              template lt typename number gt  inline number operator-  const number amp  y    return x -  y              template lt typename number gt  inline number operator   const number amp  y    return x    y              template lt typename number gt  inline number operator   const number amp  y    return x    y              primative x                                                                                             Example Use   class Foo   public      ReadOnly lt Foo  int gt  cantChangeMe       Remember you ll need to add bitwise and unary operators as well  This is just to get you started

User · Answer

I spent quite a while thinking this over for the Java case  and I believe the real reasons are    Code to the interface  not the implementation 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

User · Answer

There are many reasons  My favorite one is when you need to change the behavior or regulate what you can set on a variable  For instance  lets say you had a setSpeed int speed  method  But you want that you can only set a maximum speed of 100  You would do something like   public void setSpeed int speed      if   speed  gt  100         this speed   100      else       this speed   speed          Now what if EVERYWHERE in your code you were using the public field and then you realized you need the above requirement  Have fun hunting down every usage of the public field instead of just modifying your setter   My 2 cents

User · Answer

One of the basic principals of OO design  Encapsulation   It gives you many benefits  one of which being that you can change the implementation of the getter setter behind the scenes but any consumer of that value will continue to work as long as the data type remains the same

User · Answer

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

User · Answer

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    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

User · Answer

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

User · 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 custom class 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

User · Answer

Thanks  that really clarified my thinking  Now here is  almost  10  almost  good reasons NOT to use getters and setters    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  Any validation you perform in there can only be context free  which validation rarely is in practice  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  You can hide the internal representation - fantastic  so you re making sure that all these operations are symmetrical right  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  Some libraries expect this  but not many - reflection  serialization  mock objects all work just fine with public fields  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

User · Answer

Getters and setters coming from data hiding  Data Hiding means We   are hiding data from outsiders or outside person thing cannot access   our 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 balance person1 getName      to give permission to set balance person1 setName     You can set value in constructor also but when later on when you want to update change value  you have to implement setter method

User · Answer

This is a good question with even better answers  As there are a lot of them  I will just put there a little more This 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 GS     public int f2   get  private set           A GS with public read access  the write is only on the private level     public int f3   private get  set           A GS where  You can set  but you can t get  outside the class     public int f4   get  set      10           A GS with default value  this is a NEW feature of C  6 0    NET 4 6

User · 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            Override         public void add                 i   i   2                      Override         public 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   0 0 4

User · Answer

One other use  in languages that support properties  is that setters and getters can imply that an operation is non-trivial   Typically  you want to avoid doing anything that s computationally expensive in a property

User · 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 capacityMl   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        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         private void checkNotOverFlow         if amountOfWaterMl  gt  capacityMl          throw new BottleOverflowException              I ll leave the definition of the 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 write 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   Please note also that you can t change the capacity of a bottle  It s now set in stone  You could do this with an int by declaring it final  But if this was a list  you could empty it  add new things to it  and so on  You can t limit the access to touching the innards   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

User · Answer

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

User · Answer

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

User · Answer

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

User · 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

User · Answer

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

User · Answer

I know it s a bit late  but I think there are some people who are interested in performance   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 method anInstance 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  741ms Time 1  655ms  Time 2  743ms Time 1  656ms  Time 2  634ms Time 1  637ms  Time 2  629ms Time 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  6351ms Time 1  6363ms  Time 2  6351ms Time 1  6350ms  Time 2  6363ms Time 1  6353ms  Time 2  6357ms Time 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  73ms Time 1  94ms  Time 2  65ms Time 1  67ms  Time 2  63ms Time 1  65ms  Time 2  65ms Time 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

User · Answer

One aspect I missed in the answers so far  the access specification    for members you have only one access specification for both setting and getting for setters and getters you can fine tune it and define it separately

User · 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

User · Answer

Because 2 weeks  months  years  from now when you realize that your setter needs to do more than just set the value  you ll also realize that the property has been used directly in 238 other classes  -

User · Answer

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

User · 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

User · Answer

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

User · 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

[java] Why use getters and setters/accessors?

Examples related to java

Examples related to oop

Examples related to setter

Examples related to getter

Examples related to abstraction