CSC/ECE 517 Fall 2009/wiki319 SV: Difference between revisions
Line 47: | Line 47: | ||
Note how even though x is an attribute and squared_x is a parameterless method call, they are accessed the same way. | 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 / | === '''Table showing languages that support/ don't support Uniform Access''' === | ||
Revision as of 12:30, 18 November 2009
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 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 |
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()