0

So I am developing a web text-based game and whatever business requirement shows up it adds a new method to the Player class. If you have developed a game in OOP way you possible know what I am talking about.

On my daily job I am developing a game server project and again, it has a HUGE Player class. The way they made that class to not be even bigger is making something like "managers": PlayerAttributeManager, PlayerFoodManager and those are just examples. So you would not call Player.getFood, Player.getTastyFood and so on, but those would be in PlayerFoodManager for example.

A friend was making a game for android and again most if his logic was in the Player class. However a huge Player class does not break the design patterns I think, because in those games a Player can do so much things and everything is related to the player.

Please give me any advice on how to have a smaller class when creating a game.

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
Martin Angelov
  • 3
  • 1
  • I do not understand your question. If, as you say, you think "a huge Player class does not break the design patterns", then why do you want to "have a smaller class"? – O. R. Mapper Oct 25 '14 at 08:55
  • Well I guess having most of your logic in one single file and class makes development harder and clashes with the idea of OOP. When looking for something it will be hard finding it. Also, here is an example: https://github.com/TrinityCore/TrinityCore/blob/6.x/src/server/game/Entities/Player/Player.cpp but that is C++ and they have the option to split the class in separate files. If writing in Java every single class is in exactly one file and the file is too huge and you can't do that. – Martin Angelov Oct 25 '14 at 09:06
  • So, apparently, you do think that a huge class *does* break design patterns, as opposed to what you wrote in your question? – O. R. Mapper Oct 25 '14 at 09:24
  • Well there is a list of design patterns that I know of and I can't see which design pattern it breaks exactly, so right now I think its a bad think but may still not break any design patterns. – Martin Angelov Oct 25 '14 at 10:51
  • 1
    Related question: http://stackoverflow.com/questions/14870377/how-do-you-refactor-a-god-class – Fuhrmanator Oct 28 '14 at 13:26
  • Sounds like the Managers are facades, re https://en.wikipedia.org/wiki/Facade_pattern – Fuhrmanator Oct 28 '14 at 13:28

1 Answers1

0

A way to keep your Player class small(er) is to take the OOP pattern further. Let's assume that your player does, at the moment, know about food, knows how to eat, etc. Why not factor out those things and take a different point of view: Your player has, for want of a better word, a digestion - or, in OOP, an attribute of type "Digestion", which is in itself a class covering hunger, eating, etc. A similar principle can be applied to other aspects of your player. At the end, your player would have fields of type Digestion, Health, Armory, ..., and these aspects would be self-contained classes, keeping the player class small. Of course, health would have some interaction with digestion presumably - this can be managed by using interfaces.

Lying Dog
  • 1,484
  • 2
  • 12
  • 19
  • yes that is kind of like the "Manager" stuff I mentioned, except skipping the word "Manager", good idea actually. – Martin Angelov Oct 25 '14 at 10:28
  • It's a bit different actually. A 'Manager' is typically an object that administrates other objects and their states - i.e. the amount of energy, health, food etc. would still be held in the Player class, but the Manager makes changes. What I propose is to move the state (current health etc.) into classes like Digestion, Health etc., which makes them self-contained classes, not just managers of other entities. – Lying Dog Oct 25 '14 at 11:38