Taking Classes Literally

[predator78]

Ok I have known how to build classes for quite a long time now, and I understand attributes and methods. But from a design point of view how literally should I take these? For example I have a class Player and a class Table.

class Player:
attributes:
name
id
methods:
setname
takechair ??

or since

class Table:
attributes:
chairs array
methods:
takechair ??

Should the table take care of the takechair method since I'm not creating a class chair and decided to put the chairs array in Table? Or should the player have a takechair method because in real life the player would sit in the chair thus taking it?

[jwenting]

Such decisions only you can make. Which is appropriate for the situation depends on the rest of the logic you're employing.

Personally, I'd not have that method at all. Rather I'd have a user request a place at the Table, and be added to the Table as a reference in a List (I'd not use an array, rather a List and initiate the Table with the maximum number of entries allowed for that List, that way the supported number of Players per Table could be adjusted at runtime if needed by increasing that number). No chairs needed, they don't exist in the context you're describing, the Players might as well be standing rather than sitting, the program doesn't seem to care.

[jon.kiparsky]

You're defining functionality. What is it that needs to happen? High-level, it looks like you want a player to take a chair at a table. Okay, is that something that a player does, or something that a player does? I think it's something a player does, so it's in player. What needs to happen for a player to take a chair? Well, there has to be a chair, and the player has to be allowed to take a chair, and maybe the player has to be capable of taking a chair. I don't know what's going on in the model you're creating, but perhaps there's a rule that player has to be of a certain rank to take a chair at the table - you'd have to check that, that's going to require checking a field of Player. Perhaps that's dynamic, depending on who's already sitting, or who's waiting to sit - that means you might have to check the Table or some other object. Is there a chair? Well, you should ask the table. And so forth.

The high-level action belongs to the object that takes the action. You then pass messages around until the right thing happens.

As jwenting says, it all depends on what you're modelling. It might be that the player does a "takeChair" and the method determines whether that's allowed, or it might be that you call it "requestChair" and the same thing happens.

[predator78]

Great suggestions this is how I have always done it as you are describing was just curious if there was a better or more appropriate way. And yes jwenting I was thinking that the user or "player" will request a seat at the table, when that method is called it should then check with the table class and ensure that the seat is not already taken. Not sure what diffrence of a list or an array you are talking about though as I have considered them to be the same thing. Right now my array is like so.

chairarray = {1,2,3,4,5,6,7,8}
//now if a user requests a chair at say element 1 in the array it updates it like so
chairarray now holds {1,0,3,4,5,6,7,8}
So then all I check is if there is a zero in my array I know the seat had been taken.

[Rashakil Fol]

The real purpose of classes is to allow for polymorphism using virtual methods. Classes in C++ also provide the mechanism for hiding implementation details.

If polymorphism is not in play, it doesn't matter whether you say player.SitDown(table) or table.OfferSeat(player) or Sit(player, table) . Or something analogous that involves Chairs.

You'll want to make it as difficult as possible to misuse the objects involved and minimize the public interface of each class. This follows the goal of making the code as easy to use as possible. You should consider which decision makes your code easier to write and modify.

[jon.kiparsky]

If polymorphism is not in play, it doesn't matter whether you say player.SitDown(table) or table.OfferSeat(player) or Sit(player, table) . Or something analogous that involves Chairs.

In terms of the way the code runs, no, of course not. But in terms of design, it makes a big difference. If your code doesn't line up with the semantics of what you're describing, you make a much harder job for anyone, including yourself, who wants to understand it. We want to "carve nature at its joints".

You'll want to make it as difficult as possible to misuse the objects involved and minimize the public interface of each class. This follows the goal of making the code as easy to use as possible.

Yes, exactly. I think we're all in agreement on this...

[predator78]

Thanks yeah I just started classes a few days ago in c++ although I had a good grasp on them in python c++ seems more in depth on quite a few of the concepts im familiar with.