With the Bridge, classes are used in three scenarios:

• Modeling of data structures
• Modeling of classes in a classical sense having properties (attributes) and behavior (operations)
• Modeling of persistent state classes (business state objects)

Modeling of Data Structures

We recommend defining attributes and associations of complex data structures as public members. Encapsulating them as private members and accessing them via getter and setter operations would be an overkill for real life data structures, such as SAP IDocs. In the C++ domain, this is also the reason why C++ Structs have public members by default and C++ classes private ones.

Modeling of Classes in a Classical Sense

Classes in a classical sense having properties (attributes) and behavior (operations) are candidates for introducing getter and setter operations. They provide a mechanism to control the access to attributes and provide further interception points, for example in order to execute validation rules. Those classes should not have a great many of attributes. If they are to hold complex data structures, they should be linked via associations. This will ensure that the number of getters and setters is kept small, thus keeping the class maintainable.

Modeling of Persistent State Classes

Objects of persistent state classes can only change their state via asynchronous signals. This means, attributes and associations of these classes may only be changed via their member operations. In fact, attributes of persistent state classes are always private.
See also Persistent States and Signals.