Architecture of the C++ API
The C++ API architecture is based on a conceptual containment model, where the containment model defines an object's scope. A container always creates objects it contains. For example, an LNNotesSession object creates LNDatabase objects, and an LNDatabase object creates LNDocument objects.
The following figure shows a combined inheritance and containment hierarchy for commonly-used classes in the C++ API:
Closing a container object automatically closes all contained objects. For example, if you create a database object, use a member function to create a document, and then close the database, the document also closes. Consequently, you should be careful to save changes to contained objects before closing the object that contains them.
Note If you don't close a container object (for example, LNViewFolder, LNDatabase, LNNote, LNDocument, or LNAgent) before it goes out of scope, it closes automatically at some point. However, for efficiency, you should close resources as soon as you are finished with them. That way, you can be sure that memory associated with objects is freed immediately.
The following table shows the complete inheritance hierarchy of the C++ API, with derived classes indented under their parent class. Each class name is a link to the Reference Guide description of the class. Note that most classes inherit from one of two abstract base classes, and that the C++ API does not use multiple inheritance.
As you would expect, parent classes in the C++ API represent generic Notes objects, while derived classes represent increasingly specialized objects. Your applications will be easier to write if you use derived classes wherever possible, since they provide access to API functions specifically designed to deal with Notes objects of particular types. For example, LNRichText::GetText returns a string representing the text of a rich text item in a note. If you used LNItem (the parent of LNRichText) to represent the item instead, you would have to work harder to get that string.
In general, use generic classes, such as LNItem or LNNote, when you don't care about the type of the actual object you're processing, or when you are manipulating an object of a type currently unsupported by the API.
You cannot directly use LNNotesClass or LNSmartPtr, since they are abstract classes.