Using Constructors To Provide Initial Object State
In the case of the EngineMonitor instantiation, however, the intent was not to initialize the properties of the EngineMonitor, but rather to provide state for it. The engine object and engineMonitor object are really two different types of objects. The engineMonitor object is a service class whereas the engine object is a JavaBean object - specifically a session bean. And in general, service classes tend not to have raw data type instance properties that depend on external setting anyway.
These types of objects - by strict definition of the Object Model - must have both properties and service methods, and they must communicate via messaging with other objects in the system ensuring high encapsulation and loose coupling. Both the EngineMonitor and Engine objects satisfy these requirements, however, they go about it with different purposes.
The EngineMonitor object provides services for the Engine object that the Engine object should not need to know about. For example, the engine should know how to process the fuel that it is given but it should not have to know the level of its fuel tank - that would be the job of the EngineMonitor class. However, the Engine class's aggregate object FuelTank is neither a service class nor is it a session bean. FuelTank is an entity bean, i.e. a bean that could be either serialized or persisted to a data store. To initialize it's properties, the use of accessors over constructors keeps the overall api of objects in the system consistent.
The DTO Issue
This would be true as well for another type of object similar to an entity bean: the DTO or Data Transfer Object. These objects generally contain the properties of many objects. They are populated from a screen form submission or a complex database query, for example. They characteristically do not have any service methods on them; they are used only as a temporary store of dissimilar data which other service objects extract (usually directly as public properties vs. accessors) and distribute to a graph of other objects (both service and session beans) used in the system. In fact, some current thought in regard to DTO type objects is to make all properties public and not have accessors at all; the object is short lived anyway so what is the purpose of data hiding?
Thus, depending on the type of object and how it is to be used in the system determines whether use of the constructor as an initializer of object properties might be appropriate. In general, initializing object properties via the constructor is not recommended. However, using the constructor to initialize some type of object state may be very appropriate. This type of initialization tends to be done with one or at most two objects and will not change even as the object mutates through time.
Avoiding Problems With Object Instance Properties
In a related matter to constructor initialization of class instance properties are the property definitions themselves. All class property definitions should include an initial value and definitions of the following format should be avoided: