To self access - or not
One topic that generates a lot of heat is the question, "Should one use self accessors?". First, for clarity, self accessors are accessors used to access private instance variables. My opinion is that they should be avoided and one should not automatically use self accessors. There are situations where self accessors should be used but that should be determined as the code evolves.
Let's look at the reasons people use self accessors and what I think.
1. Using an accessor instead of a direct reference provides consistency with the message sending paradigm.
This only works if one does not use method temporary variables or refer to message arguments, to me this is rather weak. Additionally, when one uses a direct reference it is clear from the code that state is being read or changed. If the code uses a setter or getter a user reading the code, who is unfamiliar with the code, cannot be 100%25 sure that nothing else is being done by the accessor and must also read the accessor. Trying to maintain consistency with the message sending paradigm is a lot less important than readability.
2. Object state variables can also be considered attributes and using accessors maintains consistency with the concept that attributes are represented by methods.
I agree with this and is what I consider to be the strongest argument for using self accessors. When I am creating a new design I frequently write my code using self accessors, but later change them to use direct references. This is because, other than working, I consider readability to be the most important goal of the code. Additionally, I have seen too much code where other objects improperly used the accessors, resulting in brittle code that needed to be reworked. This tends to be more of a problem with novice smalltalk programmers who have not yet rid themselves of their procedural thinking.
3. Using accessors allows one to more readily reuse a design and specialize in a subclass.
While there is some truth to this, what frequently also occurs, is the subclass changes are sufficiently different that the method names no longer are a good representation of what the methods are doing. Also frequently, the programmer has designed the class with re-usability in mind, but has no actual use cases. This results is a class that is immature with respect to re-usability and is less readable than its actual use would dictate. Using self accessors in an abstract class is something that should be arrived at through design evolution.
4. Forcing state access through a couple of methods makes debugging easier.
This is because of a lack of good tools. The proper solution here is to get, or create, good tools instead of making your code compensate. In the current version of VisualWorks if you want to trace state access or interrupt execution, there are browser menu commands that allow the user to place probes on all instance variable accesses.
