I think you misunderstood my design/approach I was aiming for.
MasterHUD is given a GameState object which happens to implement IGameClock.
MasterHUD creates a new GameClockHUD widget.
GameClockHUD asks for an IGameClock (on spawn) so it can call the GetMonthAsText() method (as well as the other date time helper methods that return Text objects).
MasterHUD says “I have an IGameClock, let me cast BP_GameState to IGameClock because it implements it”. MasterHUD hands the IGameClock to the GameClockHUD widget.
GameClockHUD received the IGameClock so it calls the IGameClock public methods that return Text objects. This way GameClockHUD is not doing any calculations, it can decide how it wants to display the date time in which every style/layout it wants.
MasterHUD is not doing any game clock calculations either. It just grabs the implementation of IGameClock (BP_GameState) from global namespace. I did not want GameClockHUD to reach into global namespace because that’s programmer hell.
The purpose for an IGameClock interface that BP_GameState implements? I doubt I’m going to leave the GameClock processing in the GameState. My game is in early stages and I know I will find a better place to migrate the game clock calculations. Therefore I don’t want to refactor occurrences of BP_GameState to be IGameClock (or what ever the game clock class name would be).
I’m following S.O.L.I.D principles so I use interfaces to reduce the amount of regression bugs caused by refactoring/changes.
I hope all this made sense 