Uniform access principle

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.

While most examples focus on the "read" aspect of the principle, Meyer shows that the "write" implications of the principle are harder to deal with in his monthly column on the Eiffel programming language official website.

Explanation

The problem being addressed by Meyer involves the maintenance of large software projects or software libraries. Sometimes when developing or maintaining software it is necessary, after much code is in place, to change a class or object in a way that transforms what was simply an attribute access into a method call. Programming languages often use different syntax for attribute access and invoking a method, (e.g. obj.something versus obj.something()). The syntax change would require, in popular programming languages of the day, changing the source code in all the places where the attribute was used. This might require changing source code in many different locations throughout a very large volume of source code. Or worse, if the change is in an object library used by hundreds of customers, each of those customers would have to find and change all the places the attribute was used in their own code and recompile their programs.

Going the reverse way (from method to simple attribute) really wasn't a problem, as one can always just keep the function and have it simply return the attribute value.

Meyer recognized the need for software developers to write code in such a way as to minimize or eliminate cascading changes in code that result from changes which convert an object attribute to a method call(or vice versa). For this he developed the Uniform Access Principle.

Many programming languages do not strictly support the UAP but do support forms of it. Properties, which are provided in a number of programming languages, address the problem Meyer was addressing with his UAP in a different way. Instead of providing a single uniform notation, properties provide a way to invoke a method of an object while using the same notation as is used for attribute access. The separate method invocation syntax is still available.

UAP Example

If the language uses the method invocation syntax it may look something like this.

//Assume print displays the variable passed to it, with or without parens
//Set Foo's attribute 'bar' to  value 5.
Foo.bar(5)
print Foo.bar()

When executed, should display :

5

Whether or not Foo.bar(5) invokes a function or simply sets an attribute is hidden from the caller. Likewise whether Foo.bar() simply retrieves the value of the attribute, or invokes a function to compute the value returned, is an implementation detail hidden from the caller.

If the language uses the attribute syntax the syntax may look like this.

Foo.bar = 5
print Foo.bar

Again, whether or not a method is invoked, or the value is simply assigned to an attribute is hidden from the calling method.

Problems

However, UAP itself can lead to problems, if used in places where the differences between access methods are not negligible, such as when the returned value is expensive to compute or will trigger cache operations. It might not matter in principle to the client how the value of 42 was obtained, but if computing it requires running a city-sized computer for 7.5 million years, the client ought to know what to expect.

Language Examples

Ruby

Consider the following

y = Egg.new( "Green")
y.color = "White" 
puts y.color

Now the Egg class could be defined as follows

class Egg
  attr_accessor :color
  def initialize( color )
    @color = color
  end
end

The above initial code segment would work fine with the Egg being defined as such. The Egg class could also be defined as below, where color is instead a method. The calling code would still work, unchanged if Egg were to be defined as follows.

class Egg
  
  def initialize(color)
    @rgb_color = to_rgb(color)
  end

  def color
     to_color_name(@rgb_color)
  end
 
  def color=(color) 
     @rgb_color = to_rgb(color)
  end

  private
  def to_rgb(color_name)
     .....
  end

  def to_color_name(color)
     ....
  end
end

Note how even though color looks like an attribute in one case and a pair of methods in the next, the interface to the class remains the same. The person maintaining the Egg class can switch from one form to the other without fear of breaking any caller's code. Ruby enforces UAP, the attr_accessor :color only acts as syntactic sugar for generating accessor/setter methods for color. There is no way in Ruby to retrieve an instance variable from an object without calling a method on it.

Python

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, but to hide the fact that a method is being invoked instead of simply retrieving or setting a value.

In the strict sense, Python does NOT follow the UAP because there is a syntax difference between normal method invocations and attribute access.

In Python, we may have code that access an object as follows

egg = Egg( 4, "White")
egg.color = "Green"
print egg.weight, egg.color, egg.quack()  # prints: 4 Green quack

A Egg object could be defined such that weight and color are simple attributes as in the following

class Egg(object):
   def __init__(self, weight, color):
      self.weight = weight
      self.color = color
   def quack(self):
      return "quack"

Or the Egg object could use properties, and invoke methods instead

class Egg(object):
    def __init__(self, weight, color):
      self.__weight = toGrams(weight)
      self.__color = toRGB(color)

    def setColor(self, colorname):
      self.__color = toRGB(colorname)

    def getColor(self):
      return toColorName(self.__color)
    
    color = property(getColor, setColor, doc="Color of the Egg")

    def setWeight(self, weightOz);
       self.__weight = 29.3*weightOz

    def getWeight(self):
       return self.__weight/29.3;

    weight = property(setWeight, getWeight, doc="Weight in Ounces")

    def quack(self):
       return "quack"

Regardless of which way Egg is defined, the calling code can remain the same. The implementation of Egg can switch from one form to the other without affecting code that uses the Egg class. Languages which implement the UAP have this property as well.

Common Lisp

Common Lisp does not enforce UAP, but it provides language constructs that make it possible. That, together with the fact that the Common Lisp Object System makes no distinction between function invocation, object attribute, and method syntax, means that UAP-conformant style is customary and it is very unusual to see interfaces that fail to provide it. In fact, Common Lisp includes the concept of extensible "places", which allows arbitrary expressions to be made into writeable locations.

For example:

(defvar *egg* (make-instance 'egg :weight 4 :color "white"))
(setf (color *egg*) "green")

(format t "~A ~A ~A" (weight *egg*) (color *egg*) (quack *egg*)) ; prints: 4 green quack

The egg class could be defined as follows:

(defclass egg ()
    ;; "%WEIGHT" is just a naming convention to distinguish the slot names from
    ;; their accessors' names, to make it harder to access raw slots and thus
    ;; violate UAP accidentally. These names live in separate namespaces in Common
    ;; Lisp, and there is nothing preventing us from naming the slot "WEIGHT".
    ;; There are multiple different conventions used, depending on the programmer.
    ((%weight :accessor weight :initarg :weight :initform 0   :type number)
     (%color  :accessor color  :initarg :color  :initform nil :type (or string null))))

(defmethod quack ((egg egg))
    "quack")

The :accessor weight part in the above definition instructs CLOS to generate reader and writer methods named WEIGHT and (SETF WEIGHT) respectively (the latter name signifies that it is used by the SETF operator in so called SETF expansions). These auto-generated methods simply retrieve and store unmodified values in the object's slots.

If we later decide that the weight for example should always be rounded to the nearest multiple of 2, we can change the definitions:

(defclass egg ()
    ;; We no longer want the writer to be auto-generated, only reader
    ((%weight :reader weight :initarg :weight :initform 0 :type number)
     ...))

(defmethod (setf weight) (new-weight (egg egg))
    ;; ROUND takes optional second argument to divide by
    (setf (slot-value egg '%weight) (* 2 (round new-weight 2))))

(setf (weight *egg*) 16.9)
(format t "~A" (weight *egg*)) ; prints: 16

However, there is nothing to prevent the programmer from accessing and setting the slot value directly if they wish to:

(setf (slot-value *egg* '%weight) (* 3 (sqrt 2)))
(format t "~A" (weight *egg*)) ; prints: 4.2426405

It is bad form and unwise to do so without very good reasons, but the language does not forbid it. It is also for this reason that slot names are conventionally named differently than their accessors, so as to make accidental violation of UAP difficult, but deliberate possible (this also has the side benefit of allowing export of accessor names from the package while keeping the slot names internal, raising the barrier for confusion even more).

C++

C++ has neither the UAP nor properties, when an object is changed such that an attribute (color) becomes a pair of functions (getA, setA). Any place in that uses an instance of the object and either sets or gets the attribute value ( x = obj.color or obj.color= x) must be changed to invoke one of the functions. ( x = obj.getColor() or obj.setColor(x)). Using templates and operator overloading, it is possible to fake properties, but this is more complex than in languages which directly support properties. This complicates maintenance of C++ programs. Distributed libraries of C++ objects must be careful about how they provide access to member data.

Scala

Scala allows methods of arity 0 to be accessed as plain properties. More specifically, it is allowed (and encouraged) to reference a method with an empty argument list like a normal property. Methods which modify the object's state are by convention written with empty parens to signify intent.

class Rectangle(var width: Double, var height: Double) {
  def area: Double = width * height
  def randomize(): Unit = ??? // mutate width/height
}

// REPL-session follows:

scala> val rect = new Rectangle(3.0, 4.0)
rect: Rectangle = Rectangle@59328357

scala> rect.area
res0: Double = 12.0