• Post Reply Bookmark Topic Watch Topic
  • New Topic

Creating complicated objects  RSS feed

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to create complex Character objects. Each object has a name, and for each object with the same name, they share some of the same initial data. However, there are also some bits of data that are given to the object when it's created. For example, an "Elephant" always starts out having a weight of 500, but its position is determined when it's created. Any of these values may later be changed during runtime.

I'm thinking of tackling this problem by having a bunch of code like that shown below:



Is there a better way to solve this problem? Also, is there anything that might be confusing about the way I named everything? For example, whether I should try to use words other than 'static' and 'dynamic', or a nicer word than 'parameters'?
 
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul McAllen wrote:I'm trying to create complex Character objects.

Well, first off: I wouldn't use the name "Character", because you'll get it confused with Java's Character class, which has nothing to do with "characters" in a game (which is what I presume you're trying to define).

How about "Entity" or "Animal" instead?

Each object has a name, and for each object with the same name, they share some of the same initial data. However, there are also some bits of data that are given to the object when it's created. For example, an "Elephant" always starts out having a weight of 500, but its position is determined when it's created. Any of these values may later be changed during runtime.

Any of them? Or just the "dynamic" ones? As a general rule, you shouldn't make objects any more "mutable" than they need to be, and you should never use any mutable object as a key in a Java collection.

Is there a better way to solve this problem?

I suspect so. For starters, I reckon that a Position class would probably be a good idea; not quite so sure about "Velocity" though - what is it supposed to represent?

Also, is there anything that might be confusing about the way I named everything? For example, whether I should try to use words other than 'static' and 'dynamic', or a nicer word than 'parameters'?

Well, I've given you one above.

Again, I think you need to describe what these things mean - does "static" refer to stuff that never changes, or can they be changed too? Are they always the same for every "character" you create; or can some have some "extra" attributes?

I think you need to get a handle on WHAT these things are supposed to be. Right now you seem to be writing an implementation and then trying to fit your names (or your design) around it; and that's not usually a good way to go.

[Edit] I would say that you could do with shortening those names a bit. I've actually broken up some of your lines because they're far too long, and it's largely because your names are so verbose. Please read the link before you post any more code.

Oh, and welcome to JavaRanch, Paul!

HIH

Winston
 
Paul McAllen
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the answer. Here are my responses:

'Entity' might work, but another library I'm using for my program contains an Entity class already, and 'Animal' is unfortunately too specific (there could be robots or plants that are also considered Characters). Maybe CharacterEntity might be a good name?

I think it's possible for at least some of the "dynamic" values to be changed later, although I'm not 100% sure whether some will or won't change ahead of time. But once I'm further into the code, couldn't I just put 'final' to everything that I don't want changed and leave it at that? I thought that Strings in Java are immutable, and they're the only things used as keys?

By "Velocity", I mean in the physical sense, as in the change of position over time. I'm not too concerned about the actual fields themselves and will probably use a 2-dimensional vector class instead of primitive floats in the final design, but I'm concerned about whether the way I've organized my classes and functions to do this task makes sense, or if there is a more standard, neat approach to solving this problem, like putting all of the data values inside Character's constructor (although I've also heard that this is a bad idea for lots of values).

"Static" refers to stuff that's loaded at the start of the program, but not in the exact sense of the word 'static' used by Java. When the program starts and before anything significant is done, the StaticParameters class's Maps will be populated with all of the possible CharacterStaticParameters objects and their corresponding names as one of many initialization processes. Once the Maps are populated with the data, they aren't modified and are functionally read-only, for all intents and purposes. However, once a "character" is built with them, the "character"'s values are then subject to change, although changing the "character"'s values shouldn't produce any change in the CharacterStaticParameters used to create them. Essentially, I want to be able to tell the program to build me an "Elephant" while supplying some additional parameters it can't or shouldn't know ahead of time (ie. position), and have the program create that object.

Another reason why I'm wondering if my choice of names was poor was also due to their length. I've noticed that my names tend to get pretty long. But I've thought of different substitutes ("Arguments" and "Data" vs "Parameters", "Preloaded" vs "Static"), but they all seem to be at least just as long and/or less descriptive than what I already have to me.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul McAllen wrote:'Entity' might work, but another library I'm using for my program contains an Entity class already, and 'Animal' is unfortunately too specific (there could be robots or plants that are also considered Characters). Maybe CharacterEntity might be a good name?

Possibly, but what about "Piece" or "Actor" or "Sprite"? The latter is a bit old-fashioned, and I suspect you'll want to use "Player" for something else; but I'd try to keep the size down as much as possible, while still keeping it descriptive. You could try looking up the word "character" in a Thesaurus and see if anything leaps out at you.

By "Velocity", I mean in the physical sense, as in the change of position over time. I'm not too concerned about the actual fields themselves and will probably use a 2-dimensional vector class instead of primitive floats in the final design

Right, but is this value final? ie: does it represent what a particular "entity" CAN move, or its current velocity? You may even find you need two "velocities": 'max' and 'current' - I simply don't know.

but I'm concerned about whether the way I've organized my classes and functions to do this task makes sense, or if there is a more standard, neat approach to solving this problem, like putting all of the data values inside Character's constructor (although I've also heard that this is a bad idea for lots of values).

Well there is a technique called the Builder pattern which might be useful, but you appear to be trying to "reflectionize" all this stuff, rather than using Java types (or subclasses) to build objects by definition.

For example, if I was doing this, I think I'd probably be trying to break down the different types of "character" structurally or by behaviour. So I might have a Sprite interface that defines the behaviour (ie, methods) common to ALL "characters", and then an AbstractSprite superclass that implements Sprite and contains the attributes common to all characters (eg, 'name', and maybe 'position'). Then my Elephant would be a class that subtypes AbstractSprite.

But you seem to be going for a more "reflective" style where the name determines behaviour. Now there's nothing particularly wrong with this (almost nothing is "wrong" in programming), but I fear you'll be missing out on all the compile-time type checking that Java provides by doing so. I suspect you'll also end up with a lot of introspective "dispatch" logic to get characters to work the way you want, ie:and so on. It may work, but it's not really "objective"...and Java is an Object-Oriented language.

Another reason why I'm wondering if my choice of names was poor was also due to their length. I've noticed that my names tend to get pretty long. But I've thought of different substitutes ("Arguments" and "Data" vs "Parameters", "Preloaded" vs "Static"), but they all seem to be at least just as long and/or less descriptive than what I already have to me.

Well, "parameter" means something very specific in Java, and it's NOT how you're using it. Methods (and constructors) have "parameters"; objects don't. A much closer noun would probably be "Attribute(s)" or "Field(s)".

But I have to admit to being a bit leery about what you're trying to do here. I think I understand why - you want to "automate" the procedure and save yourself some typing - but it feels like a "procedural" solution written in an OO language.

However, feel free to correct me if you think I'm wrong.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!