"I would make the stronger statement: No attribute shall be accessed except via a get/set method"

I agree with this one, and it should actually be extended to cover access from within the class itself. That's actually the point the original post is trying to make.

"that access should itself be limited to within the class in the vast majority of cases"

I disagree with this. If I understand this correctly, you mean that those getters and setters shall not be used by other classes. This is way too general. We are not making black boxes. In fact:

• If the attribute shall be observable from outside, the getter/setter for that attribute shall be publicly accessible (Update: I modified the last two words to fix language problems. I realized the mistakes after I read the anonymous reply. Thanks, Anonymous Monk ;-).
• If the attribute is only used for program itself for programing reasons, yes, its getter/setter shall be restricted to the class itself.

There is a very subtle difference here, some attributes are real attributes that descibe the characteristics of the class, in this sense, the meaning of attribute matches its real world meaning. The setters/getters of those attributes shall be publicly accessable (although the variable represents the attribute shall be private), so that other classes instantiating this class, can understand it, measure it, observe it.

There is another type of "attributes", which are really just global variables within the class itself (most of the time, introduced by the programming of the class, but not the class itself), and no other class actually need to know them, then not just the variable itself, but its getter/setter shall be private.

Also, getter and setter of the same attribute could have different access level. Some of the attributes could be readable, but not writable from outside, so their getters are public, but setters are private.

Also, in some languages, for example Java, there is a protect access level in between private and public, so that some methods (obviously including setters/getters) are only accessible from certain classes, but not all classes. That makes a lot sense to me.

If the attribute shall be observable from outside, the getter/setter for that attribute shall be public acessable.

I agree. I meant that far too often, public getter/setter methods are a sign of poor OO design: objects as datastructures rather than objects as behaviors/responsibilities and state.

Okay, so my previous post shall really be taken as a detailed extension of your post, not a disagreement ;-) This is the nature of discussion, after couple rounds of given and taken, people gain better understanding between each other.

I agree with what you said here.

Although I am inclined to agree with some of the points made I would not make a blanket generalization about accessor methods like that. They can be detrimental to your design.

This article at the javaworld website enumerates the argument against get/set methods. It goes even further than I would in arguing against accessor methods but I feel that it brings up some important points.

Here is a quote from the article that gives you an idea of the angle it takes:

"Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: they provide external access to implementation details. What if you need to change the type of the accessed field? You also have to change the accessor's return type. This return value is used in numerous places, so you must also change all of that code. I want to limit the effects of a change to a single class definition. I don't want them to ripple out into the entire program.

Since accessors violate the principle of encapsulation, you can reasonably argue that a system that heavily or inappropriately uses accessors simply isn't object oriented."

The simplest example of this is changing an internal data structure from an array to a hash. If you have get and set methods for it you have to go out to every place in your code where you pulled the array out with a get() method (and put it back with a set() call) and fix the code to handle a hash. This violates the data encapsulation principle of OO.

I think you have missed the distinction made about internal vs external access. That java-world article is talking about get/set methods that are exposed to the world outside of the object. Within an object/class, accessors are the preferred way to manipulate attribute data, and this thread has been discussing access within the class.