This is very common among clients of current and former data classes, but you can see it for any class and its clients.
What to Do
Reduces duplication. Often improves communication (since code moves to where people would expect it to be). May expose further refactoring opportunities.
Sometimes behavior is intentionally put on the "wrong" class. For example, some design patterns, such as Strategy or Visitor, pull behavior to a separate class so it can be independently changed. If you Move Method to put it back, you can end up putting things together that should change separately.
It's not always easy to distinguish Feature Envy from Inappropriate Intimacy (later in this chapter). Joshua Kerievsky of Industrial Logic suggests, "Feature Envy is when a class does so little on its own that it needs to ask lots of other classes things in order to do anything on its own. Inappropriate Intimacy is when a class reaches deep inside another class to get access to stuff it shouldn't have access to."