CoreMedia Content Application Developer Manual, Version 7.5.45-10
4.1.1. Generate Content Beans from the Content Type model | 4.1.1.1. Patterns For Content Beans

Construction

Content beans are both used to denote content and references (links) to content. A content bean used as a link must be cheap to construct. Thus, at construction time, a content bean should only set the information required to identify itself: its contentBeanFactory and content object (and maybe other required services like a DAO or a JDBC data source). No content should be retrieved. The source code generator fulfills this requirement by generating a default constructor and the two getters defined in the CoreMedia CMS interface.

	Note
	When extending, you should not modify the default constructor in the generated beans.

Identity, equality

Two content beans originating from the same factory for the same content object must be equal. They identify the same business identity. Generated content beans fulfill this requirement by inheriting #equals and #hashCode from AbstractContentBean which is defined in terms of the corresponding content methods.

	Note
	When extending, you should not override equals or hashCode.

Mutable state

A content bean must not store mutable information. Caching of mutable state is performed in other layers. All methods of a content bean should always modify the content object directly. This way, a content bean can never be invalid when the repository contents change.

	Note
	When extending, you should not declare any fields in a content bean except for read-only, immutable service references.

Mutable values

The results of getter methods of a content bean must not be modified by application code. Modification would lead to race conditions and break the data view framework. Getter methods of content beans should return immutable objects in order to prevent errors caused by illegal modification. In particular, they should not return arrays but immutable collections.