CSC/ECE 517 Fall 2009/wiki3 16 rn

From Expertiza_Wiki
Jump to navigation Jump to search

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. Note that since you are expanding on the current article, it is fine to lift text that is in the Wikipedia article right now.

INTRODUCTION

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.

Many languages have various degrees of support for UAP, where some of the implementations violate the spirit of UAP. The inclusion of 'properties' in some programming languages is another way to address the problem that Meyer discusses. Properties don't provide a uniform notation, but they do make the call to the method which provides a service opaque.

UAP Example

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

When executed, should display : 

5
5

This allows the object to still hide information as well as being easy to access.

The same should be true for setting the data. 

Foo.bar = 5
Foo.bar(5)
//These should achieve the same goal

EXPLAINATION OF EXAMPLE

Say that bar is a feature of a class named Foo. For languages that do not support the Uniform Access Principle, the notation used to access bar differs depending on whether it is an attribute (storage) or a function (computation). For example, in Java you would use foo.bar if it were an attribute, but you would use foo.bar() if it were a function. Having this notational difference means that users of Foo are exposed to unnecessary implementation details and are tightly coupled to Foo. If bar is changed from attribute to method (or vice versa), then any users of Foo must also be changed.

UAP SUPPORT IN LANGUAGES

The Languages that Support UAP are:

  • Eiffel
  • Ruby
  • Visual Basic

The Languages that don't support UAP are:

  • Ada
  • Java
  • C #
  • C++
  • Perl
  • Small Talk

Explanation: As we can see in the figure, in the languages that do not support UAP, the method balance has to be called in a specific manner, depending upon its prototype of the method in the class in which it is defined. Where as in Eiffel, a language that supports UAP, the specific details of balance are not important to the function call.

Languages Supporting UAP WITH EXAMPLES

Ruby

class Foo
 attr_reader :x
 def initialize(x)
   @x = x
 end
 def squared_x
   return @x * @x
 end
 end

y = Foo.new(2)
puts y.x
puts y.squared_x

Output for Above Example: 

2
4

Observation: Note how even though x is an attribute and squared_x is a parameterless method call, they are accessed the same way.

Python

The following example uses python properties. 

class Foo(object):
    def __init__(self, x):
        self.setx(x)

    def getx(self):
        return self.__x

    def setx(self, x):
        if type(x) != int:
            raise ValueError('Not an integer')
        self.__x = x

    def getsquared_x(self):
        return self.x * self.x
    
    x = property(getx,setx, doc="x attribute of Foo object")
    squared_x = property(getsquared_x, doc="getter for squared x")

y = Foo(2)
print y.x
print y.squared_x

Outputs for the Above Example 

2
4

Observation: Python properties may be used to allow a method to be invoked with the same syntax as accessing an attribute. Whereas Meyer's UAP would have a single notation for both attribute access and method invocation (method invocation syntax), a language with support for properties still supports separate notations for attribute and method access. Properties allow the attribute notation to be used to invoke a method where that is desirable.

PHP

class Foo{
    private $x;

    function __construct($x){
        $this->x = $x;
    }

    function x(){
        return $this->x;
    }

    function squared_x(){
        return $this->x * $this->x;
    }
}

$y = new Foo(2);
echo $y->x();
echo $y->squared_x();

Outputs for the above Example: 

2
4

Observation: There are many other ways to achieve the same functionality in PHP, for example making x public and accessing it directly or using magic methods function __get($variable)

Languages NOT Supporting UAP WITH EXAMPLES

Java

import java.util.* ;
class BankAccount {
….
public int balance(){
int depositSum = 0;
int withdrawalSum = 0;
for (int i = 0; i < deposits.size(); i++){
depositSum = depositSum + ((Integer)deposits.get(i)).intValue();
}
for (int i = 0; i < withdrawals.size(); i++){
withdrawalSum = withdrawalSum +
((Integer) withdrawals.get(i)).intValue();
}
return depositSum – withdrawalSum;
}
…
protected ArrayList deposits;
protected ArrayList withdrawals;
}

Observation: When looking at the code deposits.size(), the client can immediately see that deposits is an attribute (a “field” in Java terminology) and that size is a routine of class ArrayList (a “method” in Java terminology) because there is no opening and closing parentheses to access attributes whereas parentheses are compulsory for routine calls. This policy breaks the principle of Uniform Access; clients should not know whether a service is implemented by computation (routine) or by storage (attribute).

Small Talk

In SmalltalkLanguage, UAP is not supported. But since variables are local to objects, you only have to worry about the difference within that object's methods, and nowhere else. By insisting that every variable access (even local ones) be through a getter/setter, UAP can be supported in Smalltalk. This is also extraordinarily helpful if the object in question is persistent, and therefore subject to various db synchronization/transaction issues.

ADVANTAGES OF UAP

Some of the Advantages of using UAP are as follows:-

  • Hiding implementation from the client (i.e. hiding the fact a service is implemented by computation or by storage) provides flexibility. It is possible to change the implementation (for example, decide to use an attribute rather than a routine) at no cost for the clients. The supplier does not have to tell its clients about this change; the client code will continue to work.
  • The Uniform Access Principle seeks to eliminate this needless coupling. A language supporting the Uniform Access Principle does not exhibit any notational differences between accessing a feature regardless of whether it is an attribute or a function. Thus, in our earlier example, access to bar would always be in the form of foo.bar, regardless of how bar is implemented. This makes clients of Foo more resilient to change.

DISADVATAGES OF UAP

Dis-advantage of using UAP is as follows:-

The UAP is only appropriate in a system that supports information hiding to the full (and in a way, implies this), as otherwise a client would be entirely justified in trying to perform an operation such as

x.f = y;

Where f is in fact a routine defined on x! Whereas if they are aware that everything in the public interface of a class is a function, they would not be justified in trying to perform such an action.

SUMMARY

The article discusses about uniform access principle by expanding the current wiki article. The features discussed include the necessity for UAP, the Languages that support it, specific examples for the same and the advantages of the principle. Also we continue to discuss the languages that do not support this principle with reasons and a specific example in Java supporting it. Disadvantage of the principle has also been cited as a countervailing argument.

GLOSSARY

Information Hiding: Information hiding in computer science is the principle of segregation of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation (the details that are most likely to change).

REFERENCES

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_16_rn&oldid=29799"