CSC/ECE 517 Fall 2009/wiki319 SV
Problem Statement
"The principle that an access (read or write) to a feature of an object should be written the same whether the feature is an instance variable or method. Look at the current Wikipedia article on the subject and expand on it. Consider the reason for this principle and try to find countervailing arguments against it. If you do a good job, it could be submitted to Wikipedia. Since you are expanding on the current article, it is fine to lift text that is in the Wikipedia article right now."
Uniform Access Principle (UAP)
The Uniform Access Principle was put forth by Bertrand Meyer. It states "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation." This principle applies generally to object-oriented programming languages. In simpler form, it states that there should be no difference between working with an attribute, precomputed property, or method/query.
The Uniform Access principle simply means that if a module (the "client")is accessing a property managed by another module(the "supplier")it should not matter to the client whether the supplier keeps the property stored or computes it on demand.
Consider an example of a class Foo, and lets assume bar to be related to Foo. In a language like Java, if bar is an attribute, one would use foo.bar. If it were a function, we would use it as foo.bar(). Thus, in languages, that do not support Uniform Access Principle, the usage of bar would be different for cases when bar is an attribute or function. Due to these differences in the notational, there arises unwanted implementation details.
Also, there would be tight coupling to Foo, as when a change is made to bar from an attribute to a method, or the other way around, the the users of Foo must also be changed. The Uniform Access Principle seeks to eliminate this needless coupling. The languages that support the Uniform Access Principle do not have differences in their notations while accessing feature regardless of whether it is an attribute or a function. Thus, going with the above example, access to bar would always be in the form of foo.bar, regardless of how bar is implemented. The user or client need not bother if bar needs to be stored as an attribute or be computed on demand (function).This makes clients of Foo more resilient to change.
This example can be clearly understood below:
If a language allows access to a variable via dot-notation and assignment
Foo.bar = 5 //Assigns 5 to the object variable "bar"
then these operations should be the same :
//Assume print displays the variable passed to it, with or without parens //Assume Foo.bar = 5 for now print Foo.bar print Foo.bar()
Languages Supporting / Not Supporting Uniform Access Principle
Among Object Oriented languages, Eiffel, Ruby,Python, PHP support the Uniform Access Principle, although Smalltalk renders the distinction moot by not allowing any access to attributes from clients.
Ruby
Ruby blurs the line between names of variables and methods. The Uniform Access Principle is an excellent idea in a language where both variables and methods have to be declared and cannot overlap. But Ruby allows a symbol to identify both a variable and a method, and the disambiguation process is best described as eccentric.
class Foo attr_reader :x def initialize(x) @x = x end def squared_x return @x * @x end end y = Foo.new(2) puts y.x puts y.squared_x
This outputs
2 4
Note how even though x is an attribute and squared_x is a parameterless method call, they are accessed the same way.
Java
source: [[1]] public class Money { private double amount; public double getAmount() { return this.amount; } public void setAmount(double amount) { this.amount = amount; } }
In this example, we end up writing a lot of code to write just to define one single property, which is almost meaningless. But in Java we have to introduce getters and setters from the very beginning, or it will give problems in the future. It clearly contradicts with the DRY principle and discourages writing code that may be useless right now, but may (or may not) be needed in the future. In theory our methods should always have some meaningful behaviour, and our code should avoid trivial accessors in the public interface.
The syntax for accessing an attribute and calling a method in Java is completely different, and we can’t start with a simple public property and change it into a method later when it becomes necessary, keeping the public interface intact. So it is always advised not to use public properties and always define trivial accessors just in case.
Table showing languages that support/ don't support Uniform Access
| Languages | Support for Uniform Access Principle |
| Eiffel | Yes |
| Smalltalk | N/A |
| Ruby | Yes |
| Java | No |
| C# | No |
| C++ | No |
| Python | No |
| Perl | No |
| Visual Basic | Yes |
Most other languages, as well as UML, do not consider Uniform Access. They fundamentally distinguish between attributes (fields) and functions (methods). The result leads to a tricky situation. Although we can export an attribute, making [ATTRIB_ACCESS] valid if `price' is exported, this is not well accepted by most experts. This has two bad consequences. First, this is the case of putting a mechanism in a language and then discouraging people to use it. Second, people who follow the advice will have to rely on special functions whose only purpose is to return the value of the corresponding attributes. Instead of [ATTRIB_ACCESS], clients will write
(source: http://www.eiffel.com/general/column/2005/Sept_October.html) [FUNCTION_CALL] my_stock.get_price
which requires adding to STOCK a feature
(source: http://www.eiffel.com/general/column/2005/Sept_October.html) get_price: PRICE -- Return the value of `price' do Result := price end
or the equivalent in another language.
Such functions add to the noise, and make the code longer unnecessarily.
Arguments supporting Uniform Access Principle
In Object Oriented Programming where the programming is based on one of the principles “Encapsulation” which is to protect the integrity of the component during its external access. But most of the object-oriented programming languages provide the encapsulation feature through its getters and setters. In a programming language where an attribute is accessed through variable, the level to which the conversion from variable access to the method access depends on the support for Uniform Access Principle. In the languages which support this principle, the conversion from variable access to the method access can be achieved easily because of the principle ‘Uniform Access’. For instance, an accounting system has the Invoice class which provides the total value. The programmer has coded it in a way to store the total attribute as a separate attribute. Now to support the encapsulation, he tries to change it to method. In the accounting system, there are 15000 instances of total where to change from inv.total to inv.total() is difficult to implement. Hence with languages that provide the support for Uniform Access Principle, the change can be adapted easily. However in languages which does not support the UAP the mapping from variable access to method access can be done through getters and setters like getTotal() and setTotal(int).
Below example shows how to convert from variable access to method access in the language (java) which does not support the Uniform Access Principle.
class Invoice{
public int total;
// Logic to compute total
}
class Invoice{
private int total;
public int getTotal(){
return total;
}
public int setTotal(int tot){
total = tot;
}
}
Below example shows the same accounting system implemented using Ruby which supports UAP
class Invoice
attr_accessor :total
def initialize(tot)
@total = tot
end
// Logic to compute the total
end
puts Invoice.total
puts Invoice.total()
As the principle states, the client does not concern about how the implementation is, whether it is being implemented as an attribute or a function. For instance, Eiffel follows this principle. Most other languages, as well as UML, do not consider Uniform Access. They fundamentally distinguish between attributes (fields) and functions (methods). The result leads to a tricky situation. Although we can export an attribute, making [ATTRIB_ACCESS] valid if `price' is exported, this is not well accepted by most experts. This has two bad consequences. First, this is the case of putting a mechanism in a language and then discouraging people to use it. Second, people who follow the advice will have to rely on special functions whose only purpose is to return the value of the corresponding attributes. Instead of [ATTRIB_ACCESS], clients will write
(source: http://www.eiffel.com/general/column/2005/Sept_October.html) [FUNCTION_CALL] my_stock.get_price
which requires adding to STOCK a feature
(source: http://www.eiffel.com/general/column/2005/Sept_October.html) get_price: PRICE -- Return the value of `price' do Result := price end
or the equivalent in another language. Such functions add to the noise, and make the code longer unnecessarily.
The Uniform Access Principle constitutes an important principle in the software construction among with other principles – Linguistic Modular Units, Self-Documentation, Open-Closed and Single Choice. All services offered by a module must be available to its invoking classes through a uniform notation, which does not betray whether they are implemented through storage or through computation. The principle is in fact a design rule that influences many aspects of Object Oriented design. It follows the continuity criterion “a method satisfies Modular Continuity if a small change in a problem specification will trigger a change of just one module or a small number of modules”. It can also be viewed as a special case of Information Hiding. The UAP frees the clients from internal representation choices of whether it is being implemented as an attribute or method. The other principles are beyond the scope of this article.
Arguments countervailing Uniform Access Principle
While it is convinced that the Uniform Access Principle is a principle worth giving attention, its implementations often lack the love it deserves. For instance, when the designers of Java decided to implement Uniform Access, their solution was not to make methods and instance variables look similar. Instead they agreed to make everything look like a method. That is why Java forces you to write foo.setBar(bar.getBar()) where the simple implementation could have been foo.bar = bar.bar. Ruby has advantages over other programming languages with regards to UAP. Ruby lets us "assign" values to methods, so we can skip the whole accessor mess with getBar() and setBar(..). If bar is an instance variable, just expose it as such: attr_accessor :bar If we would like to change the nature of bar we can overwrite its accessors like this:
def bar # code for getting bar end
def bar=(value) # code for setting bar end
While C# supports Uniform Access principle in the spirit of Eiffel and Ruby, its implementation falls short in some important points. In C# we may define properties which look like this:
public class Bar {
get {
// code for getting Bar
}
set {
// code for setting Bar
}
}
The issues with respect to UAP in C# are, i) The property above will mutate into get_Bar and set_Bar during compilation. That means while most of your C# source is ignorant of how access to Bar is implemented, compiled code is not; so it is better to pay attention when accessing a class using reflection. ii) It is impossible to overload property setters. set_Bar takes another class as its value and that's all you get. iii) An interface which includes a get/set property cannot be implemented with a public instance variable of the same name. We need to type out the whole property construct instead, even though all it does is reading and writing to a variable.
The Uniform Access Principle does not have a significant problem when not directly supported by the language syntax.One potential drawback of Uniform Access is that it may hide the cost of calculation. If the calculation is expensive and/or time-consuming, but is disguised as a simple attribute, then one may risk excessively frequent accesses when a more appropriate treatment would be to copy it to a local memory variable. It would be difficult to tell the difference between what would otherwise be Game.SpectatorCount and Game.SpectatorCount()
[[2]]