This paper addresses an important conceptual gap that exists between object-oriented modeling and object-oriented programming (OOP), as practiced by users of various OOP languages. Collections are normally used in OOP to represent one-to-many object relationships, and the paper proposes the concept of “multiplicities” (usage is independent of any specific object-oriented approach) to deal with certain technical restrictions in using collections. It illustrates users’ cognitive gaps that lead to certain maintenance problems (with some associated costs in terms of effort) when the multiplicity of relationships changes.

These problems are illustrated with an example to showcase errors, including maintenance/error-proneness, subtyping constraints and problems, call semantics problems, unwrapping to access individual objects, aliasing problems, and so on. The author argues that collections give fine-grained control to the programmers, and these may be better addressed if left to multiplicities to express them at a higher abstraction, while still using collections in the background to implement them, thereby not changing the programmer’s perspective of the usage.

Using multiplicities, the author showcases letting expressions evaluate to any number of objects (instead of 0 or 1). Other multiplicity options ([0, 1] and [0, *]) are introduced to move collections from primary implementation of relationships, thereby showing how all the initially identified problems could be solved.

The costs of this approach with respect to performance (one more level of abstraction), effort (for the programmers), and performance tuning for any real-time problems (with respect to taking away more fine-grained control) remain to be seen.