Many people who have read J2EE Core Design Patterns are using value objects with shitloads of getters and setters, making it impossible to provide any guarantees about the sanity of the object..
Just consider that every field may be zero and that an object may be changed by almost anyone at any time. Also, many of the big value objects in a typical system actually carry process information which is gathered over time, so many of the fields are null initially and are set as the process progresses. Even worse, many value objects actually represent multiple types of real objects (concepts). This is because inheritance is not really supported by entity beans and value objects typically represent rows in a database table. For example, if a Package has a quantity > 1, then it represents a group of packages and if it is 1 then it represents a single package. In the latter case only, the package may have a unique label by which it can be scanned. In other words, there is a distinction between a package group and a single package.
As a result, writing simple functionality can become incredibly complex because:
- fields may be null depending on some conditions. As a result, knowledge of which fields are null in which circumstances is duplicated throughout the system.
- depending on the value of one field, the value object all of a sudden represents a different concept requiring a different treatment. This leads typically to many similar if statements throughout the code.
- behavior is located in (big) services separate from the value objects