I'm trying to refactor a 2.5KLOC god-class (with about 68 data members and 62 member functions) that performs a wide variety of text formatting and layout operations. After a careful analysis based on:

  1. Which member function reference which data members and,
  2. The logical formatting sub-tasks

I've partitioned the data members and members functions into 9 classes. The problem now is that most of these smaller classes are repeatedly reaching for data held by other classes (classic feature envy). What sort of refactoring would be advisable in this situation?

It probably doesn't matter bit if it does, I'm programming in C++.

closed as too broad by Euphoric, gnat, Andy, 17 of 26, stijn Oct 24 '17 at 14:35

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    We can't really help you with such generic problem. Maybe your initial refactoring was wrong? – Euphoric Oct 24 '17 at 10:11
  • Probably. Maybe a god-class is the lesser or two evils. – Olumide Oct 24 '17 at 10:14
  • 3
    I wouldn't say that. Maybe there is different design that is not a god class and that doesn't have feature envy. But we can't tell you what design that is, as we have zero information about the code you are working with. – Euphoric Oct 24 '17 at 10:16
  • 5
    Is it possible the key problem in your refactory is that classes have to reach for data instead of the (usually, hard to tell without eeing actual code) more sane been told to do something with data, i.e. a possible violation of the 'tell don't ask' principle? Imo just splitting up one class into 9 others but without changing much about the control flow won't be much better in the end. – stijn Oct 24 '17 at 11:55
  • 1
    Your problem is too vague to write a proper answer, but I can tell you that you should evaluate each method (yes one by one) and determine what direct dependencies they have. Look for very common groupings, like 50 of 60 methods require classes A, B, and C. In that case, you're probably looking at a good candidate for a class that acts like a facade for A, B, and C for the things you need for it to do. Still, I don't envy you. God classes don't become that way because they're easy to refactor. – Neil Oct 24 '17 at 12:10

There are a few things that could be going on that have different solutions depending on the data that's being cross referenced and how its used in each class.

  1. You need a better Data object to pass to each new object that does contain all the information, if these are primitive values that other objects don't need to manipulate to be usable.
  2. You need a common object to inherit from that handles common values, this would also be good only for read only references.
  3. You have a poor abstraction and classes need to be modeled differently so all the needed data is in the same object.
  4. You have business logic or objects that aren't being properly isolated.

Not the answer you're looking for? Browse other questions tagged or ask your own question.