 <p>In most cases you should not think of a class as a set of attributes that you operate on externally, but as an entity that provides certain services to the application. Most attributes of the class will end up being private and not having get or set methods.</p> <p>There are exceptions though: for example in some settings you will find classes that only hold values and have little or no logic themselves. The usual rule for these kinds of classes is to make fields private and provide get and set methods because once you make something public and some other class depends on it you can't change it. For example you may want to ensure that the value of a particular field is never null or do some other validation; if you used a set method you could add the check there, but if the field is public there's nothing you can do. Another example: you may want to change the field type to do some optimization, but if the field is public, there's nothing you can do.</p> <p>All rules are meant to be broken though. If you know that you will never need get and set methods there's not much point in adding them. Some people may complain about "lack of encapsulation" but if every attribute of the class can be read and written from the outside anyway where's the encapsulation?</p>