Attributes are the properties of a class; on the whole they are things that can be measured or observed. For example, an important attribute of the class Animal is “number of legs”. Different animals have different numbers of legs, but all animals have the property “number of legs”. Even a snake has a number of legs: it just happens to be zero. However, it would make no sense to talk about a plant's having “zero legs”. The attribute “number of legs” is not a valid attribute of plants.

Attributes are used rather vaguely in classification in general. For example, biologists distinguish between insects and spiders because insects have the attribute “has six legs” and spiders have the attribute “has eight legs”. There is a numerical difference here. However, one of the ways that biologists distinguish between reptiles and mammals is that reptiles are cold-blooded and mammals are warm-blooded. There is no numerical difference in this case.

In class modelling the nature of attributes is formalised. We can say that:

For example, suppose the class “Book” in our library example has attributes “title”, “publisher”, and “date of publication” (there will, no doubt, be others, but these will do for now). The attribute “title” has a name (“title”), it has a type (probably “text” or “string”). Objects of class “Book” will have values for this attribute, for example, “War and Peace”. The attribute “date of publication” has a name, and its type is “Date”. Again, objects of class “Book” will be published on different dates, but all objects will have a value for the attribute.

The important point here is that, although all instances of class “Book” have different values for these attributes, they all have the attribute, and they are all the same type. The date of publication of a book will always be a date, and never a height. The title will always be a piece of text and never a colour, and so on.

In some cases the values of attributes distinguishes one object from another. For example, if Rover is a brown dog and Fido is a black dog, we may reasonably say that their “colour” attributes are different. There is no chance of confusing Rover for Fido. However, common sense indicates that if we see two brown dogs, we cannot assume they are the same dog: there are many brown dogs in the world. Indeed, even if all the attributes of two objects are identical, this does not make the objects identical.

There is an interesting philosophical issue behind this; many students have argued (sometime fiercely) in classes that if we really knew all the attributes of a particular class, and two objects had all those attributes in common, then they would of necessity be the same object. For example, two brown dogs may be indistinguishable by colour, but the are distinguishable by position. If two putative objects occupy the same point in space, then they must be identical.

This is all well and good, but irrelevant for this subject. Whatever the philosophical contentions, the principle which object-oriented designers work to is that:

For example, the person Mary Smith is identical to herself, and if Mary Smith is the world-record holder for (say) javelin throwing, then the object “Mary Smith” is identical to the object “world record holder for javelin throwing”.

Ignorance of this principle leads to very subtle problems when designs are translated into programs. For example, consider the following portion of a Java program:

String response = "HELLO".toLowerCase();
    if (response == "hello")
    {
    System.out.println("They are identical.");
    }
    else
    {
    System.out.println("They are NOT identical.");
    }

This Java snippet creates an object of class String and sets it equal to the lower-case text "hello". The program then tests whether the “response” is equal to the object "hello". Since both objects have the value “hello”, we might expect the program to consider them equal. But in fact the program will inform us that the two objects are not equal; the object "hello" and the object “response” have identical attributes, but they are not equal to each other. The correct way to test whether two String objects have equal attributes in Java is to write something like:

String response = "HELLO".toLowerCase();
    if (response.equals("hello"))
    {
    System.out.println("They are equal.");
    }
    else
    {
    System.out.println("They are NOT equal.");
    }
    

The equals method tests two objects to see if their attributes are equal. The == operator, on the other hand, tests whether the objects themselves are, in fact, the same object.

It is a key principle of object-oriented design that attributes should be simple. The technical term is atomic, meaning “not capable of division into smaller components”. If an attribute appears to have attributes of its own, then it is not an attribute at all, and is probably an object in its own right. You will find that programmers, of necessity, do not follow this rule. This is because it is standard practice to use classes to extend the functionality of a programming language. In Java, for example, numbers — such as 12 and 4.7 — are atomic, but text strings are represented as objects. In this case it is often necessary to make objects attributes of other objects.

Also, although “has six legs” may be an attribute of insects to a biologist, it will never be an attribute of any class in an object-oriented design. This is because it is not precise enough. A designer would say that the class “insect” has an attribute “number of legs” whose value, by default, is 6. We would write this in a formal way (as will be discussed later):

      numerOfLegs:integer(6)
    

Having said that, in the initial stages of design, it is inadvisable to be too precise about attributes. In particular, usually the names are established first before the types and values. In some cases the types of attributes will not be determined until writing the program code; however, at this point it must be specified: many programming languages require the types of attributes to be fully specified.

In addition, during design there is no reason why the types of attributes have to match the types that are available to a particular programming language. For example, real numbers (that is numbers with fractional parts) are represented in Java by the types “float” and “double”. These are technical terms with no meaning outside of certain programming languages. In design there is nothing to prevent the use of attribute types “number”, rather than “float”, simply because it is easier for non-specialists to follow. The translation into programming terms can be made later in the development if necessary.

It is important to understand that an object's attributes belong to the object in some way, that is, they tend to be “private”. One object cannot automatically obtain, or change, the attributes of another. This is just another way of saying the objects are self-contained. Part of the process of object-oriented design is determining which of an object's attributes may be read and written by other objects, and which will remain private.