CSC/ECE 517 Fall 2009/wiki319 SV

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

Table showing languages that / that do not support Uniform Access

'	Eiffel	Smalltalk	Ruby	Java	C#	C++	Python	Perl	Visual Basic
Support for Uniform Access Principle	Yes	N/A	Yes	No	No	No	No	No	Yes

Problems with Uniform Access Principle

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