Single Job Classes

[clivetortoise]

Purely for conversation (as I appreciate this course is pitched between Beginner and Intermediate), is it better practice to separate out economy management and UI updating?

In this case, I mean a class that sits on the UI object and handles setting the UI text, alongside the economy manager which keeps a track of the gold. When I was a decent level beginner, my UI then checked the economy manager every update for the currentGold value and set the text appropriately. Now that I’m a learning Intermediate, I’m using a delegate Action to tell the UI that the gold value is changed.

No functional difference from the course, of course, but makes the classes more complicated to set up (for me anyway) but easier to read later.

PS - Does Ben know you use the word “Manager”. It seems the sort of thing that would make him grumpy (er).

[Yitzchak_Cohen]

I too am a fan of using a seperate class to Update the UI and using delegates to determine when they should be updated. I found it has really saved me when changing scenes or spawning players dynamically and the UI maintains functionality without having to change anything.
In the scope of the course the economy manager is pretty small, so no real harm done there.

I was thinking recently about using the word “manager” in my class names. I often use the word manager or controller and realized this might not be the best practice. However, I think if you use a word consistently within the program and have a concrete idea of it’s meaning it’s okay. It’s a noun, which is good for class naming and if all the manager’s do the same thing, I think it makes sense. Being consistent with your naming so you can go back later and understand what everything means is probably the most important thing with naming your classes.

[Brian_Trotter]

Even though I’ve been known to use Manager, I’m in the “despise the term” camp, because it inevitably leads to mission creep in the class, breaking the number one rule in SOLID, Single Responsibility Principle.
Manager is vague enough that while you may have intended for one purpose, mentally it’s easy to add other things for the class to Manage. For example, let’s suppose we’re making a multi unit game where each unit gets a turn based on it’s speed and when it took it’s last turn… so for that, we need something to remember whose turn it is

public class UnitManager //determines whose turn it is next

And it might start with a simple function

public Unit GetNextTurn()

which scans the list of units and determines the next Unit to take a turn.

Down the road, we might wonder… Hmmm is there a good way to tell how many units are left on each team? Oh, I know, I’ll put that in UnitManager.

public (int, int) GetUnitCount() //1st int is player, 2nd int is AI

You know what, since UnitManager knows so much already, it can tell us when a victory condition is reached

public bool? TestVictoryCondition() //true if player won, false if enemy won, null if not finished

Mission creep.
But… if that UnitManager started out being a UnitTurnBroker

public class UnitTurnBroker

Then the initial method makes sense, and the other methods, which are far from the scope of a turn broker don’t make as much sense…

public class UnitCensus 
{
    publilc (int, int) GetUnitCount()
}

public class VictoryChecker
{
    public bool? TestVictoryCondition()
}

The advantage to more precise class naming is that six months from now, or a year, or when another person joins your team, they’ll know from the class name precisely what the purpose of the class is… and when you say "hmmm… I need to tweak the VictoryConditions, you won’t wonder what it’s doing in UnitManager.