0

I have written some code that contains the class Game and the class Draft. Inside of Game I have a private member, instance of Draft draft. When a user requests through the UI, a game must return some calculation of data held in draft. Should I have a method for this in both Game and Draft, such as when needed the UI calls game.ProcessData(); whose job is only to call draft.ProcessData(); which does all the work, or should I not have draft.ProcessData() defined at all, and just have game.ProcessData() do all the work directly on the instance of draft that is in game?

Basically my question is one of efficiency versus compartmentalization (not sure that is the correct word). My example cotains only 2 classes, but what if there were 3 or 4 or x. It seems weird to me to have x ProcessData methods, x-1 of which don't do anything of note, except call other ProcessData methods.

RobbyG
  • 101
  • 1
  • 6
  • I think one problem that is not addressed in the linked answer is your names: If you call everything `ProcessData`, these methods calling each other will of course feel silly. Maybe you can find a more descriptive name? What kind of data does `draft.ProcessData` process? Or more to the point: What does it return or what does it change? For `Game`, `ProcessData` *might* be fine but maybe there’s a better name, too. – Eike Schulte Nov 21 '22 at 07:53
  • This is one of the downsides to standard OOP. As you say, if you need a function that operates on several models, there's often no super obvious spot to place the function. One approach is to have a dedicated class PER OPERATION. That is to say, you don't have a function called "ProcessData" on the Game object, rather you have a class called DataProcessor which is constructed with Game/Draft/etc as parameters and that new class is the one that has the ProcessData method. OOP models do not have to match 1-to-1 to real world objects/concepts. – Graham Nov 21 '22 at 18:54
  • @EikeSchulte The linked post did not answer my question completely, indeed, however, it did send me down a rabbit hole that got me to the conclusion that the solution depends on the specific case and as long as you are not too egregious in either extreme of the Demeter law it is fine. As for the names, I do have a number of methods that do something specific, I was just trying to generalize the question by using a generic name like ProcessData; in hindsight I could have done a better job asking the question – RobbyG Nov 22 '22 at 12:26
  • @Graham That is an interesting point and the way I understand it is similar to the concept of interfaces, but I don't think it refers to my use case. I only have `ProcessData` in my Draft class that does anything, the `ProcessData` in my Game class looks like this: `public List ProcessData() { return draft.ProcessData(); }` And if I had other classes above Draft, they would all just be returning the `ProcessData()` of the class below them, with the exception of the one in Draft, which would actually do the calculation. – RobbyG Nov 22 '22 at 12:32

0 Answers0