Business Object Structure - Structural

Full text

Intent

Object-oriented programming has a number of powerful constructs for solving a problem. Using all these constructs to the fullest for business objects can cause design problems in other areas of the application. This solution puts limitations on the way in which business objects are designed so other valuable properties are preserved.

Motivation

Business objects are the core of every application so they are used by many subsystems of a software system. Each subsystem has its own requirements for the objects that it can handle. One of the most important subsystems is the storage subsystem. Although a lot of progress has been made here, not all object-oriented constructs can be stored efficiently in the common persistence solutions. Especially storing objects in a SQL database imposes a number of limitations.

Interface-based programming is a very powerful construct that should be applied as much as possible. It enables easier testing and allows proxies to be used. The design of business objects must also incorporate interface-based programming.

Business objects are not only used by clients but also by other business objects. Because different business objects can be in different packages, the methods needed by other business objects, implementation methods, must be public. The set of public methods of a business object consists of the set of methods for clients and the set of implementation methods. To prevent confusion for, and accidental invocation of an implementation method by developers, the set of methods for clients must be isolated from the set of implementation methods.

Implementations

No reusable implementations of this solution are available because each application needs its own set of unique business objects.