Data classes are “dumb” data holders without complex functionality. Other classes strongly rely on them. Related data and behavior is not kept in one place, which is a violation of OO design principles and shows lacking encapsulation.

Impact

  • Data classes violate data-operation proximity by isolating data from associated functionality
  • Low encapsulation and loss of data hiding.
  • Other classes usually depend heavily on Data classes.
  • Data vulnerability: They allow other classes and interfaces to manipulate and thus control their data.
  • Reduces maintainability, understandability, and testability of the system.

Characteristics

  • A Data class tends to hold only data and provide no functionality.
  • Public interfaces provide access to data (accessor methods) rather than useful functionality.
  • Class can be exposing a few useful services and functionality but their complexity is very low and number of data members is disproportionately higher than number of useful services.

Example(s)

The following can be inferred from the diagram:

A. Initialization layer:
Class has only one initializer (a constructor)
B. Public Interface and Attributes layers: Out of all public members methods:
Only 2 are functional methods.
All remaining attributes are public attributes.
C. Internal Implementation and Accessor layers:
There are no private methods.
No accessor methods are provided direct access to “public” attributes.
Additionally: Non-encapsulated methods are mostly used from the outside (invoked by God classes and other classes).

Guidelines

  • Design a class in such a way that it contains both data and methods and interfaces that operate on that data.
  • Keep data “private” as much as possible, make only methods that provide functionality “public”.
  • The services offered by the class should make use of the data internally, rather than allowing external classes and clients to access data via accessor methods.
  • Try to initialize all the data via constructors wherever possible rather than providing separate public methods to set that data.
  • If the data needs to be accessed only by derived classes, the accessor methods that get and set that data should be implemented as “protected”.
  • If a class has only data and has only a few clients accessing that data examine the possibility of removing the data class completely and shifting the data into the client classes. If that’s not possible, try to make such data classes accessible only to those clients that are using them. Do not expose them to clients who don’t need to know about them.