Liutauras Vilda

Exemplary! Congratulations!

@OP

You seems do not understand what the hashcode is and why is it for. Your last posts do not make sense to me.

Please explain why you override hashcode and equals?

I wouldn't start thinking about the serialization and in particular persisting results to database yet. You want to store to database correct data.

I'd at least start testing your code first. Code in general isn't readable to me, so that is the biggest worry as of now in order to understand it, lots of parts do not make sense, i.e. you have Bicicleteria type variable defined, then you cast Bicicleteria type veriable to Bicicleteria (same one), then do some other weird things, on quite a few cases I'm unsure whether the code even compiles.

So I'd really advice you to stop considering writting extra code and start cleaning up this one and writing tests to verify it works. Your classes have code ranging from 150 - 250 lines of code, in my opinion they are too big and do too many things which likely are unrelated, hence could be extracted to classes where they supposed to be.

Not sure about your time constraints and how much time you got for that, but that would be a lot of work to re-do things. On the other hand, moving forward with what you have, you may end up nowhere at all. I think former approach is more promising.

Please show us the code, so we have something more concrete to discuss about.

@OP

Junilu has much more experience than I do, so don't take my ideas as granted, I just putted on a table few other ideas just to show how many ways are to implement this. Give a try what he suggested. After all, that's your journey. All programmers are different, in fact, they think differently. So what really makes more sense to me, might won't make that much sense to you or others. When you work in a team, you need to find compromises.

And I'd agree what Junilu mentioned, that it is fairly easy to over engineer and over complicate problem. But I guess it becomes more apparent when you try out various approaches. Perhaps with time one has to attempt less times in order to come up with a decent choice.

Now, you may appeal and say that you really need to store the rolled dice result and now you got robbed of this ability.

Give a try going even more further, create some class which records results.
int rollDice(Dice dice, ResultRegister register) {    int result = dice.roll();    register.record(result);    return result; }
Now, this is on a worried side. Method became more complex, and instead of rolling the dice it started doing something else! So roll back, try other way.

How about:
class Game {    ...    void play() {        ResultRegister register = new ResultRegister();        ...        Player player1 = new Player(...);        int result = player.rollDice(dice);        register.register(player1, result);        System.out.println(register.resultOf(Player.ONE));    }    ... }
Can you see how many posibilities out there? You really start feel of engineering when you try out different ideas.
       
       
   

If you noticed, my thoughts shifted slightly from Junilu's maybe here, and might some parts clashed, but that really isn't a problem. You need to try those ideas and see for yourself how well code reads, whether it is easy to understand. Even better, show to your friend, course mate, does he/she/they understand your code?

Once you are happy, stick to one or another approach. The good part of trying various approaches is, that you will know several ways to implementing this. Once you face different (and at the same time similar) problem in a future, you'll have better ideas in your head which approach you may go first with or which looks most promising from the information you are given.

Now, have a look at your Player class.
public class Player {    private String name;    ...    public int rollDice(Dice dice) {        return dice.roll();    } }
Does it make sense if you say to Player: "Roll dice", and the player answers you: "Give me the dice and I will".

Look once again to implementation? Does the code communicate such idea well? Yeah! Personally for me it does! Is there a better way to do that? Maybe, maybe... Is it better than was before? I think yes - so that is a step forward.

Put all pieces into the Player class, and you'll see that your Player class has now as a field only name, then one method for getting name, and another to roll the dice. Now it is a small class, easy to understand. Doesn't contain and do the stuff it shouldn't.
   

Denis, have a cow for taking feedback positively. How else could it be, such a great stuff for learning!

Few comments from me based on your latest code.

1. Why Player class has field rollDice? Do you need to store that number? Do you need it in this class at all?
2. Why method is called setRollDice()? That doesn't even read fluently in english, does it?

How about if you'd go even further? Don't be scared to over-engineer experimenting. What if you'd create Dice class and would pass it to rollDice() method?
i.e.
public int rollDice(Dice dice) {    return dice.roll(); }
How the Dice class may look? Well, it could be as simple as the content of current setRollDice() method's content.
i.e.
final class Dice {    private Dice() {        // intentionally, to avoid instantiation    }    static int roll() {        Random rand = new Random();        return rand.nextInt(6) + 1;    } }
Can you notice how responsibilities get separated?

Now imagine somebody said, you know, from now on the dice will be a pyramid having 5 sides (crazy, isn't? requirements...), and where you'd need to go to change the implementation in your current code? In Player class, this just doesn't sound right, get it now?

I'd expect to go to change to Dice class, really where you'd expect it such implementation to be.  

Have a thumb up. I see you went ahead of me and done some good job already. There are things to improve though. Will pitch in later.

Denis, read carefully Junilu's posts. I remember when I read similar ones by him few years back, it clicked me at some point how picking names very carefully leads you towards the code along with the problem which are easier to understand and solve.

public class Game {    ...    public Game(String playerName) {        this.playerName = playerName;    }    public String getPlayerName() {        return playerName;    }

Have a look at this one. Does really the game supposed to worry about player's name? I'm doubted. I'd naturally think it supposed to be in Computer class, but by now you figured that Player, what Junilu suggested most likely is the best name to give to this class. I called it an Opponent initially. Do you see how an opponent is much poorer name than Player? Opponent means that there is a player who plays against, which is true in most cases, but what is not, what if two players play together towards some common goal, so that gives an ability to re-think your strategy whether you really want to go that route? Have you ever heard saying that Team consists of 11 opponents? No! They say team consists of 11 players who play against 11 players. As you see naming is really fundamental thing, so when you look at your code it makes sense, you need to get it right - to name things what they actually mean, represent.

So try to clean up your current code by renaming things and putting information in the right places. I guess your design will read way nicer, it is not about the beauty though, it is about doing "things right". Whether it be your personal little project or school assignment.

Welcome to the Ranch, Denis!

Before I go lunch, first food for your brains:

public class Computer extends Game

When you extending something, in spoken language you'd say that Computer IS-A Game. Now is that really the case? Obviously not. What you may could do, is to play the game with computer (physical thing). Did you notice (I just did now myself), that computer has 2 meanings: [1] A physical thing, set of hardware; [2] An opponent, programmed to be controlled by computer. And the latter is really what you mean.

So when you think carefully about that, something is off here, right? I don't give a concrete suggestion for now, but try to think, what you could do about in this situation? Some random ideas: "you could consider renaming this class", "you could consider implementing Game interface with this class, or class with more descriptive name".

At the beginning it may look it doesn't help to solve our problem at hand in anyway, but hang on with such predictions. Give a try, it may open your eyes for some other design decisions which may or may not will have an impact on solving your current problem at hand.

The question was how do you perform, not on what it depends.