How do I refactor a Data Class to not be one?

by Thunderforge   Last Updated January 12, 2018 22:05 PM

We recently upgrade to PMD 6.0.0 and are getting several classes flagged as "Data Classes"? It argues that it breaks encapsulation and makes for brittle design (I understand that this site has a different opinion).

Let's say that our team decides to go ahead and refactor the data class, instead of ignoring the PMD rule. Unfortunately, PMD's documentation for the rule is unclear to me.

Refactoring a Data Class should focus on restoring a good data-behaviour proximity. In most cases, that means moving the operations defined on the data back into the class. In some other cases it may make sense to remove entirely the class and move the data into the former client classes.

I don't understand what "good data-behaviour proximity" is, or what "the former client classes" are. For instance, we have something along the lines of this:

public class Person {
    private String name;
    private List<String> formerNames;
    private List<Food> favoriteFoods;

    //getters and setters
}

How would I go about refactoring this Data Class, as PMD recommends?

I'd like to focus on what sort of refactoring would look like, rather than discussing whether the rule is a good one or not. At this time, we don't know if we want to allow this rule or exclude it.



Related Questions



Is there any reason to use "plain old data" classes?

Updated December 16, 2017 10:05 AM

Are init() methods a code smell?

Updated November 03, 2016 09:02 AM

Prevent old code from compiling reached a deadline

Updated March 08, 2018 09:05 AM