Sometimes when you create a class you can add there several properties (new data members) that you are not certain if you want to do or not. For example, I have a casino slots game. I have tiles and tiles are spinning on different reels. So once 3 tiles come on the same line then player wins 3$, 4 tiles - 4$ and 5 tiles - 5$ for tile A and for tile B player wins 5$, 10$, 20$ accordingly. Should, for example, each tile store the data of its reward or there should be a reward manager for checking how many tiles are consecutive next to each other to give the reward to the player?

Please note that I don't want to have such a situation. But I find me many times thinking "Should I add this data, and consequently, corresponding logic the my class or not?". I worry about single responsibility principle when I want to have different managers for such things, but on the other hand I came to a situation to create several singletons or singleton-like classes.

  • 1
    A single tile does not carry any award by its own, so the only reward value that you could store in there is $0,00. The reward comes from a collection of tiles, so it would make sense to have a class other than tile to calculate the reward. RewardCalculator might even be a good class name for it. – Bart van Ingen Schenau Aug 10 '15 at 19:23
  • possible duplicate of What is the real responsibility of a class? – gnat Aug 10 '15 at 19:24

In general, when you are doing object oriented programming, you want your data and behavior to be together (in one class).

You also want to achieve high cohesion with your classes. This means that most/all of your methods use most/all of the attributes in your class. This will help you achieve the single responsibility principle. Low cohesion means that part of your data is not being used when certain actions are taken (meaning it is not related to the action, meaning it probably should not be in the same class). Following these principles will create many small but focused classes.

In general you should always be able to state what your class does in a single sentence without using the word 'and'. If you cannot do this, your class is probably doing too much.

  • High cohesion sounds nice. But then I will create tons of managers! :) – Narek Aug 10 '15 at 18:06

Classes are often used for concepts, to hold together all the attributes of the concept and the interactions that are possible.

When deciding what to do however, it's purely a matter of what works best, and what design is the best. When you are deciding what to do I'd go about it this way: If the calculation is part of the (to be) object, make a class for it. If not, don't. Of course there will be unclear decisions (player.paint() or paint(player)), but it works as a general guideline. Also take into account the clutter you can create by keeping things unorganized.

For example: Let's say we have a car. This car has wheels, a driver, passengers, and cargo. What we want to do is associate the wheels, driver, passengers and cargo with the car, so we make the car into a class with all those things, possibly just pointers to the actual objects.

Now let's say we have a world of which there is only one in the entire program. Distances will be measured without reference to a World class or object. This is because the world, at least in this case, is not really a collection of attributes. Even if is had a maximum size, we would not necessarily define it as a class, because there is not much use for it, there would be more clutter because of it, and it isn't really useful for anything.

There are of course also examples where it's hard to decide. If we have a lot of trees we could store tuples of x and y coordinates in a collection called trees. However, we could also make a Tree class and store our info in there. Whether you should do that or not comes down to the following:

  • Will you be giving them extra methods like paint, update, grow and so forth?

  • Will they be objects with a lot of extra attributes that you want to keep together? Like size, age, shape, and so forth?

  • I don't understand your guidline. Please elaborate more. And what about projecting your guidline on my example? – Narek Aug 10 '15 at 18:03

Should, for example, each tile store the data of its reward or there should be a reward manager for checking how many tiles are consecutive next to each other to give the reward to the player?

How I would do it

You have a Reel object that can be spun randomly

You have a number of Reward objects that have a threshold required to win, and a prize amount to give out (you can make the threshold and prize objects in of themselves)

The Reward objects register with the Reel objects to listen to results from spins (standard pub/sub)

When the Player spins each Reel object messages the result of its spin to the Reward object, which starts checking thresholds.

A Reward tracks the result as reels report in and if a threshold is matched (eg 3 cherry tiles, but no more) then the reward messages the Player object to increase the value of the players balance by the prize amount.

No need for a reward manager, each reward is an object itself. Managers are generally a sign your objects are not talking to each other properly. In this case the Reel should talk directly to the Reward.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.