CSC/ECE 517 Fall 2009/wiki319 SV: Difference between revisions
No edit summary |
No edit summary |
||
Line 7: | Line 7: | ||
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. | 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: | This example can be clearly understood below: | ||
Line 20: | Line 22: | ||
Revision as of 11:19, 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
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