Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy. This forum is not for asking programming related questions.
I'm still new to the OOP side of the field and I'm attempting to build a simple class diagram with UML. I'm having some problems figuring out how the relationships work though.
Let's say I have a player object/class and that player has a name, unique id and skills. Skills are seperate object/class containing name and id (for simplicity sake). There are many players in the game (multiplayer) and many skills may be assigned to each player. What is the relationship between them? 1..M? M..M? And what the heck do those little arrows mean? The ones that are filled and the ones that are not?
i could be wrong but here is what i beleive is right:
The relationship of the skills to player is 1...M as you said. This means that every player has multiple skills. Although you may have many players, the UML diagram doesnt show that
Full arrow is Directional Association
Arrow sith Triagular head is implements
dotted arrow is Dependency
Arrow with diamond head is Composition
Player - This is where you add/delete/update/etc players.
Skill - This is where you add/delete/update/etc all the possible skills.
Relation_Player_Skill - This is what joins the skills with the players
The relationships would be this.
Player <-- 1..M --> Relation_Player_Skill <-- M..1 --> Skill
Player - This is where you add/delete/update/etc players.
Skill - This is where you add/delete/update/etc all the possible skills.
Relation_Player_Skill - This is what joins the skills with the players
The relationships would be this.
Player <-- 1..M --> Relation_Player_Skill <-- M..1 --> Skill
Why is the Releation_Player_Skill an object? Where do you get that from?
The relationship between Players and Skills is a many to many relationship. In a relational structure, a middle man has to link the two together because any player can have any number of skills associated with them.
Player - This is where you add/delete/update/etc players.
Skill - This is where you add/delete/update/etc all the possible skills.
Relation_Player_Skill - This is what joins the skills with the players
The relationships would be this.
Player <-- 1..M --> Relation_Player_Skill <-- M..1 --> Skill
Why is the Releation_Player_Skill an object? Where do you get that from?
It is an object because it has methods and attributes. One of the methods in this object is associating players to skills. As this method deals with both Player and Skills you can't put this method in either object (Player and Skill) so you need to create a new object. The object is small, but very vital. And if you were to create just two objects (Player/Skill) then you would be forced to throw the above mentioned method randomly into one of your 2 classes creating an inconsistency.
I thought that would be more of just a relationship line. I didn't think it actually would have methods inside either. You said it connects the two through a relationship, but doesn't calling the skill just do that? I read up a little bit more and my understanding is something more like:
Player 1 --------> 0...M Skills
id ============== id
name =========== name
skills
Moocat wrote:I thought that would be more of just a relationship line. I didn't think it actually would have methods inside either. You said it connects the two through a relationship, but doesn't calling the skill just do that? I read up a little bit more and my understanding is something more like:
Player 1 --------> 0...M Skills
id ============== id
name =========== name
skills
(the = are just seperation)
What are the attributes of your Skill object? If it is just one attribute what you have could work. However, if you have multiple attributes it is probably better to normalize.
For example. Your Skill entity has the following attributes....
Player Attributes:
Player_Id (PK)
Player_Name
Player_Position
Everytime you added a skill to a player you would put it only in relationship_skill_player. You would then link this entity to the Skill entity to find out the Name, Description, and so on.
And this is more about database design and relationships then it is OOP. Though in OOP your class structure would be very similar to the database structure.
alvin's got it right I think... Your objects would closely resemble your database structure. Traditional games head in that direction most often since its more intuitive. But yeah, it's an M=>M relation without an intermediary.
UML is a method of graphically representing an OOP structure, i.e. boxes containing details of individual classes and arrows connecting the boxes which represent the relationships between objects. It makes everything more easily explainable than using plain text.
I may have failed to mention it, (ok I did :p) but I was looking more toward a Class Diagram than a database diagram. I believe I wouldn't need the relationship object in that type of model correct? That's more for a Database-entity relationship diagram from what I've been told (at work).
Moocat wrote:I may have failed to mention it, (ok I did :p) but I was looking more toward a Class Diagram than a database diagram. I believe I wouldn't need the relationship object in that type of model correct? That's more for a Database-entity relationship diagram from what I've been told (at work).
If your application is one where people search for players and then add skills to the player then 2 classes would be fine where the method to add a skill to a player would be in the player class. However, if your clients search by skills and then add players to each skill (which I doubt) then you would want the method to add players to skills in the skill class. Again, you have a method that deals with 2 objects so it is not always easy to know which object the method should be in which is why some create a third object (even though that object is quite small). Hopefully this all makes sense.
Ah yes, I understand where you are coming from now. You would create a third object in order to objectify the relation of the two because you didn't know how the relationship would be used in terms of gameplay. The object would allow for an even more flexible system if in the future I decided to really switch things up and do things that wouldn't normally be allowed with a static method inside of a class. Although it wouldn't be that hard to re-write the class, I would then have to change all the calls to that method to the new object.
Whichever promotes future flexibility with the least effort... Remember ease of maintenance is a big must-have. It's painful when all those small changes gang up on you and become a task that could consume days of effort and testing.