The Role Object Pattern

Abstract

ficult to understand and hard to maintain. Unanticipated changes cannot be handled gracefully and will trigger lots of recompilation. Changes to a client-specific part of the class interface are likely to affect clients in other subsystems or applications as well. A simple solution might be to extend the Customer class by adding new Borrower and Investor subclasses which capture the borrower-specific and investor-specific aspects respectively. From an object identity point of view, subclassing implies that two objects of different subclasses are not identical. Thus, a customer acting both as an investor and as a borrower is represented by two different objects with distinct identities. Identity can only be simulated by an additional mechanism. If two objects are meant to be identical, their inherited attributes must constantly be checked for consistency. However, we will inevitably run into problems in case of polymorphic searches, for example when we want to make up the list of all c

Cite this work

No public copy is stored for this record, so only the metadata is cited.

Stored only when both papers are in the corpus — 91 citations exist upstream.

Papers that cite the same references — the relational fallback while embeddings are still backfilling.