Author Topic: Static GameCore  (Read 1798 times)

Dechcaudron

  • Jr. Member
  • **
  • Posts: 51
    • View Profile
Static GameCore
« on: July 07, 2014, 09:48:40 AM »
Hello again my friends,

I really know there is a war out there against people who tend to use static classes and members, but do we really need the GameCore class to be an instance class? I've read over there that static classes generally have better performance when calling their methods since the CLR does not have to solve the instance function, and since Update is called pretty often, I don't know why that couldn't be optimized.

Also, if the answer is negative, would it be ok if I kept a static GameCore member inside GameCore so that my other classes could reference it without keeping a reference to it each? I need it because some of them need to call the ExecuteDbCommand sometimes.

Sincerely yours,
Dechcaudron

AMarinov

  • Global Moderator
  • Newbie
  • *****
  • Posts: 17
    • View Profile
Re: Static GameCore
« Reply #1 on: July 07, 2014, 11:55:50 AM »
Hi Dechcaudron,

The GameCore implementation must inherit from an abstract base class, so static is not appropriate, besides, we may want to run several instances of a single game core at some stage, which also goes against the static approach.
As for the static reference pointing to the current GameCore instance, yes, you could do that.

Regards,
Atanas

Dechcaudron

  • Jr. Member
  • **
  • Posts: 51
    • View Profile
Re: Static GameCore
« Reply #2 on: July 07, 2014, 12:01:20 PM »
Hi Atanas,

thanks for the information. Still, if you do not discard the possibility of running different GameCore instances, a static reference would be only a temporary solution. I'll consider avoiding static members then.

Best regards,
Dechcaudron