Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T03:10:00Z

Smurali3: /* '''Languages Supporting / Not Supporting Uniform Access Principle''' */

== '''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 [http://en.wikipedia.org/wiki/Uniform_Access_Principle 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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

== '''Uniform Access Principle (UAP)''' ==
The '''Uniform Access Principle''' was put forth by [http://se.ethz.ch/~meyer/ 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.

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attribute] is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

== '''UAP illustration with an Example''' ==

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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, [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel], [http://en.wikipedia.org/wiki/Ruby Ruby],[http://en.wikipedia.org/wiki/Python_%28programming_language%29 Python], [http://en.wikipedia.org/wiki/PHP PHP] support the Uniform Access Principle, although [http://en.wikipedia.org/wiki/Smalltalk 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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Conclusion''' ==
The Uniform Access Principle as defined in the article is the principle by which all services should be made available through uniform notation irrespective of whether it has been implemented through computation or through storage. The languages which support and which do not have been clearly mentioned in this article. Also, it has been clearly illustrated with examples as to how the UAP has been implemented in different languages. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T03:05:32Z

Smurali3: /* '''Problem Statement''' */

== '''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 [http://en.wikipedia.org/wiki/Uniform_Access_Principle 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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

== '''Uniform Access Principle (UAP)''' ==
The '''Uniform Access Principle''' was put forth by [http://se.ethz.ch/~meyer/ 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.

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attribute] is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

== '''UAP illustration with an Example''' ==

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Conclusion''' ==
The Uniform Access Principle as defined in the article is the principle by which all services should be made available through uniform notation irrespective of whether it has been implemented through computation or through storage. The languages which support and which do not have been clearly mentioned in this article. Also, it has been clearly illustrated with examples as to how the UAP has been implemented in different languages. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T03:04:36Z

Smurali3: /* '''Uniform Access Principle (UAP)''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

== '''Uniform Access Principle (UAP)''' ==
The '''Uniform Access Principle''' was put forth by [http://se.ethz.ch/~meyer/ 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.

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attribute] is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

== '''UAP illustration with an Example''' ==

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Conclusion''' ==
The Uniform Access Principle as defined in the article is the principle by which all services should be made available through uniform notation irrespective of whether it has been implemented through computation or through storage. The languages which support and which do not have been clearly mentioned in this article. Also, it has been clearly illustrated with examples as to how the UAP has been implemented in different languages. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T03:00:40Z

Smurali3: /* '''Uniform Access Principle (UAP)''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

== '''Uniform Access Principle (UAP)''' ==
The '''Uniform Access Principle''' was put forth by [http://se.ethz.ch/~meyer/ 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.

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

== '''UAP illustration with an Example''' ==

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Conclusion''' ==
The Uniform Access Principle as defined in the article is the principle by which all services should be made available through uniform notation irrespective of whether it has been implemented through computation or through storage. The languages which support and which do not have been clearly mentioned in this article. Also, it has been clearly illustrated with examples as to how the UAP has been implemented in different languages. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T02:59:06Z

Smurali3: /* '''UAP Illustration with an Example''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

== '''UAP illustration with an Example''' ==

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Conclusion''' ==
The Uniform Access Principle as defined in the article is the principle by which all services should be made available through uniform notation irrespective of whether it has been implemented through computation or through storage. The languages which support and which do not have been clearly mentioned in this article. Also, it has been clearly illustrated with examples as to how the UAP has been implemented in different languages. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T02:57:23Z

Smurali3: /* '''Uniform Access Principle (UAP)''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

== '''UAP Illustration with an Example''' ==

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Conclusion''' ==
The Uniform Access Principle as defined in the article is the principle by which all services should be made available through uniform notation irrespective of whether it has been implemented through computation or through storage. The languages which support and which do not have been clearly mentioned in this article. Also, it has been clearly illustrated with examples as to how the UAP has been implemented in different languages. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T02:22:22Z

Smurali3:

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Conclusion''' ==
The Uniform Access Principle as defined in the article is the principle by which all services should be made available through uniform notation irrespective of whether it has been implemented through computation or through storage. The languages which support and which do not have been clearly mentioned in this article. Also, it has been clearly illustrated with examples as to how the UAP has been implemented in different languages. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-24T01:23:46Z

Smurali3:

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''[http://en.wikipedia.org/wiki/Information_hiding Information Hiding: ]''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''[http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation:]''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units Principle:]''' It states "Modules must correspond to syntactic units in the language used"

'''[http://www.ece.uprm.edu/~borges/OO-1.pdf Self Documentation Principle:]''' It states "The designer of a module should strive to make all information about the module part of the module itself."

'''[http://en.wikipedia.org/wiki/Open/closed_principle Open-Closed Principle:]''' It states "Modules should be both open and closed."

'''[http://en.wikipedia.org/wiki/Single_choice_principle Single Choice Principle:]''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T03:15:22Z

Smurali3: /* '''References''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''Information Hiding:''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''Encapsulation:''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''Linguistic Modular Units Principle:''' It states "Modules must correspond to syntactic units in the language used"

'''Self Documentation Principle:''' It states "The designer of a module should strive to make all
information about the module part of the module itself."

'''Open-Closed Principle:''' It states "Modules should be both open and closed."

'''Single Choice Principle:''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

http://www.ece.uprm.edu/~borges/OO-1.pdf

http://www.netalive.org/swsu/archives/2005/04/

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T03:13:42Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 [http://en.wikipedia.org/wiki/Information_Hiding 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''Information Hiding:''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''Encapsulation:''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''Linguistic Modular Units Principle:''' It states "Modules must correspond to syntactic units in the language used"

'''Self Documentation Principle:''' It states "The designer of a module should strive to make all
information about the module part of the module itself."

'''Open-Closed Principle:''' It states "Modules should be both open and closed."

'''Single Choice Principle:''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T03:12:22Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 – [http://www.ece.uprm.edu/~borges/OO-1.pdf Linguistic Modular Units], [http://www.ece.uprm.edu/~borges/OO-1.pdf Self-Documentation], [http://www.ece.uprm.edu/~borges/OO-1.pdf Open-Closed] and [http://www.ece.uprm.edu/~borges/OO-1.pdf 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''Information Hiding:''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''Encapsulation:''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''Linguistic Modular Units Principle:''' It states "Modules must correspond to syntactic units in the language used"

'''Self Documentation Principle:''' It states "The designer of a module should strive to make all
information about the module part of the module itself."

'''Open-Closed Principle:''' It states "Modules should be both open and closed."

'''Single Choice Principle:''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T03:09:56Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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 [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''Information Hiding:''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''Encapsulation:''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''Linguistic Modular Units Principle:''' It states "Modules must correspond to syntactic units in the language used"

'''Self Documentation Principle:''' It states "The designer of a module should strive to make all
information about the module part of the module itself."

'''Open-Closed Principle:''' It states "Modules should be both open and closed."

'''Single Choice Principle:''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T03:06:53Z

Smurali3: /* '''Glossary''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''Information Hiding:''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''Encapsulation:''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

'''Linguistic Modular Units Principle:''' It states "Modules must correspond to syntactic units in the language used"

'''Self Documentation Principle:''' It states "The designer of a module should strive to make all
information about the module part of the module itself."

'''Open-Closed Principle:''' It states "Modules should be both open and closed."

'''Single Choice Principle:''' It states "Whenever a software system must support a set of alternatives, one
and only one module in the system should know their exhaustive list."

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T02:55:30Z

Smurali3: /* '''Glossary''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
'''Information Hiding:''' It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

'''Encapsulation:''' It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T02:54:56Z

Smurali3: /* '''Glossary''' */

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

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

[[Image:UAP.jpg]]

image taken from : http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

As shown in the above image, a feature is an operation available on instances of a class. A feature can be
either an attribute or a routine.

This classification, which you can follow by starting
from the right on the figure above, is based on implementation considerations:

• An attribute is a feature implemented through memory.

• A routine describes a computation applicable to all instances of the class.

• Routines are further classified into functions, which will return a result, and
procedures, which will not.

If we instead take the viewpoint of the clients of a class (the classes relying on its
feature), we can see the relevant classification by starting from the left on the figure:
• Commands have no result, and may modify an object. They may only be procedures.

• Queries have a result: they return information about an object. We may
implement a query as either an attribute (by reserving space for the corresponding
information in each instance of the class, a memory-based solution) or a function
(a computation-based solution). [[http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf]]

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. [[http://en.wikipedia.org/wiki/Uniform_access_principle]]

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.
[[http://en.wikipedia.org/wiki/Uniform_access_principle]]

source: http://en.wikipedia.org/wiki/Uniform_access_principle
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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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.

[[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

=== '''Table showing languages that support/ don't support Uniform Access''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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
|-
|
|}

[[http://www.jvoegele.com/software/langcomp.html]]

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

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==
Information Hiding: It is the principle of segregation of design decisions in a way to protect parts of the program from extensive modification if the design decision is changed.

Encapsulation: It is often used interchangeably with Information Hiding. It is a mechanism for hiding the internal representation of the object from outside of the object's definition.

== '''References''' ==

[1] http://archive.eiffel.com/doc/online/eiffel50/intro/language/tutorial.pdf

[2] http://en.wikipedia.org/wiki/Uniform_access_principle

[3] http://en.wikipedia.org/wiki/Uniform_access_principle

[4] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[5] http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us

[6] http://www.jvoegele.com/software/langcomp.html

[7] http://reocities.com/tablizer/meyer1.htm

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:55:36Z

Smurali3:

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

== '''Glossary''' ==

== '''References''' ==

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:54:22Z

Smurali3:

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

== '''Summary''' ==
The Uniform Access Principle has been studied in detail and explained with examples from various languages like Ruby, Eiffel. Further, the article is bolstered by the arguments that support and countervail the Uniform Access Principle.

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:50:25Z

Smurali3:

== '''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."

== '''Introduction''' ==
This article throws light on the principle "Uniform Access Principle". It initially gives the definition and then explains in detail with an example. The next section focuses on the languages which supports and do not support the UAP. To make it simple, it gives the tabular form of languages that support/do not support UAP. It then discusses the actual crux of the article by giving the arguments that support and countervail the Uniform Access Principle.

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:44:40Z

Smurali3: /* '''Arguments countervailing Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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 our 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 we 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()

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:43:07Z

Smurali3:

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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()

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:34:06Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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.

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:32:57Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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.

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:32:02Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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.

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:28:07Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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()

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:26:11Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:25:03Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:24:36Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:23:43Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:23:11Z

Smurali3:

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:20:04Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:19:38Z

Smurali3: /* '''Arguments supporting Uniform Access Principle''' */

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:18:47Z

Smurali3:

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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;
}
}

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:16:20Z

Smurali3:

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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).

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:04:21Z

Smurali3:

== '''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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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.

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:03:29Z

Smurali3:

== '''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."

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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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.

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki319 SV

2009-11-19T01:02:22Z

Smurali3:

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

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: [[http://74.125.95.132/search?q=cache:h8xqHDduJ_oJ:planet.codesprinters.com/tag/programming/+uniform+access+principle+in+java&cd=6&hl=en&ct=clnk&gl=us]]

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''' ===

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Languages'''
| align="center" style="background:#f0f0f0;"|'''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.

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

[[http://reocities.com/tablizer/meyer1.htm]]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-11T03:27:28Z

Smurali3: /* '''Ongoing Research''' */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]