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

© Information Disciplines, Inc.
May 4, 2002


Composite1 data items that represent principal objects of the application domain are called entities2. Many kinds of entity have one or both of these attributes:

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

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_;


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_;

      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:

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

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

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

Return to Technical articles
Return to IDI home page.