CSC/ECE 517 Fall 2009/wiki319 SV

Problem Statement

"The principle that an access (read or write) to a feature of an object should be written the same whether the feature is an instance variable or method. Look at the current Wikipedia article on the subject and expand on it. Consider the reason for this principle and try to find countervailing arguments against it. If you do a good job, it could be submitted to Wikipedia. Since you are expanding on the current article, it is fine to lift text that is in the Wikipedia article right now."

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 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). [[1]]

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. [[2]]

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. [[3]]

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: [[4]]

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.

[[5]]

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

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

[[6]]

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

[[7]]

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

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