Conventions for related entity types,
identifier types, and name types

Background

Composite¹ data items that represent principal objects of the application domain are called entities². Many kinds of entity have one or both of these attributes:

• An external name (not-necessarily unique)
• An internal code or identifier (unique for the type, often used as the key field in a database record)

In OOP, we can and often should define types for all three, i.e. the entity itself, the entity name, and the entity identifier.

Type names

To avoid confusion, we need to assign type names that make it absolutely clear which kind of thing we're dealing with. Here's one set of naming standards.

1. The complete entity has a simple type name reflecting the real-world object, e.g. City, Company, Course.
2. The corresponding external name appends Name or Title to the entity type name, e.g. CityName, CompanyName, CourseTitle.
3. The corresponding internal identifier appends ID or Code to the entity type name, e.g. StateCode, CourseID. Altenatively where an industry standard name is in common use, it can be substituted, e.g. ISBN instead of BookID.

C++ Implementation

• The complete entity is almost always implemented as a composite-data-item class. The external name and internal identifier are private member data items, which may or may not be accessible through accessor functions.
• The corresponding name is most often implemented as an elementary text (string) class. Alternatively in a very simple case, a typedef can be used.
• The corresponding identifier is most often implemented as an elementary discrete class. Alternatively in a very simple case, an enum can be used.

Any accessor functions in the complete entity class that yield the name or identifier must return a value of that type. For example:

       Class City {
            CityName  name_;

          public:

            CityName  name() const
                     {return name_;}
              .
       };

A common mistake among newcomers to OOP is to ignore the name and identifier classes and expose their internal represntation. For example the following, although rather common even in textbooks, seriously violates encapsulation:

    Class City {
        String  name_;

    public:
      String name() const     // NO!!
             {return name_;}
        .
   };

This issue is discussed in more detail in Pseudo-classes and Quasi-classes Confuse Object-Oriented Programming. Naturally the name and identifier classes must support sufficient functionality to render such violations unnecessary. Typically that functionality includes:

• Equality and inequality operators
• For the name class, ordering operators.
• I-O stream operators
• Editing and conversion functions for common external formats

Java implementation

Implmenting these related types in Java follows the C++ model with just two exceptions:

1. The typedef and enum options don't exist. All three types have to be defined as classes.
2. The equality and ordering operators have to be defined as named functions. See Conventions for Arithmetic Operations in Java

¹ As contrasted with elementary or container types, as explained in Data-item Taxonomy and Object-Oriented Class Definition.

² The OOA community sometimes calls them business objects. Coad & Yourdon call them subjects

Return to Technical articles
Return to IDI home page.