Classes Should Know Their Objects Pattern

Work in progress.

PROBLEM: It is 3am in the morning who knows where your objects are?

CONTEXT: Outside of some simple software an identifier is used, but inside we need to pass the object arround. What should be responsible for knowing what objects exist and help us find one?

FORCES:

• We need to convert IdentifiersToObjects? in many transactions/usecases.
• We can not use the object to lookup the identifier because we haven't found an object yet.
• We need to be able to add new objects, retrieve old objects, and remove old ones.

SOLUTION: Make the class responsible. Have static/classwide/metaclass data listing the objects by identifier and a static/classwide/metaclass function that finds them. Constructors and destructors add/remove objects from the list of existing objects.

VARIATION: If there is a Factory that constructs/deletes objects then make it responsible for managing identities.

RESULTING CONTEXT: We can send the class itself a request to find an object and from then on use the object it returns.

EXAMPLEs:

• The ubiquitous Login use case.

Login provides an id and a password for a Person (say). Send the id to the Person class and get a Person back (or NULL). If not null, send the password to the object to be authenticated and get the Person back or a NULL...

• You company makes Widgets. Assign serial numbers to widgets and output barcoded labels. Employees scan the barcodes and the id is input. Ask the Widget class to find the right Widget.
• An administrator wants to remove a Person for a system given their id.... first send Person a request for the object and if it exists, remove it!
• An administrator wants to add a User to a system given their id and password.... first send class User a request for the object and if it doesn't exist, then create it!

CONTRAINDICATIONS: No polymorphic static methods. May not have remote invocation of static methods. What about the security implications of a metaclass knowing identifiers and objects? --SamuelFalvo?

ALTERNATIVES:

• Use a language or system dependent naming service -- for example CORBA. --SamuelFalvo?
• Invent a new object whose purpose is to track the objects in the class of interest. It'll have to be either global or a singleton.
• Allocate the tracking of objects to the Controller for the session/scenario.
• Whichever class creates an object could be responsible for finding it again.... Factories should keep a list of the objects they create, for example. This may be called the CreatorsKnowTheirChildrenPattern?.

RELATED PATTERNS AlwaysEncryptPasswordsPattern?, IdentifersToObjectsPattern?.

Author: RichardBotting, March 7th 2008. Revized June 18th 2009.

---

Discussion

Recognizing that this is a WorkInProgress, I couldn't help but make some observations. Not sure where else I may post this.

CORBA uses a dedicated naming service to locate objects. I prefer the naming service approach because the factory (or other agent) publishes only those objects which anyone can access. I am not a fan of ClassesShouldKnowTheirObjectsPattern because of its security implications, and it appears to break the goal of separation of concerns. If your code lacks a proper reference to an object, the probability that said code has been authorized to hold that reference approaches, or even equals, zero.

I would like to see a bit on the security implications of this pattern.

Also, there is the (smaller) issue of CodeReuse; is this pattern best provided by the language, a library of some sort, or will this tend to be custom-grown on a per-class, or at least per-3rd-party-package, basis? --SamuelFalvo?

Thanks for caring... I've rolled some of your comments into the pattern spec. Note -- I posted this here because I am in doubt about the idea and want to see it run the gauntlet of intelligent review -- RichardBotting