aspose file tools*
The moose likes Beginning Java and the fly likes Advice for a greenhorn attempting to make a program with multiple components (classes, methods, etc) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Advice for a greenhorn attempting to make a program with multiple components (classes, methods, etc)" Watch "Advice for a greenhorn attempting to make a program with multiple components (classes, methods, etc)" New topic
Author

Advice for a greenhorn attempting to make a program with multiple components (classes, methods, etc)

Hans Hovan
Greenhorn

Joined: Mar 03, 2013
Posts: 29
For fun I'm trying to make a simple dungeon-crawler/rpg type game.

(Also mentioned in this thread: https://www.coderanch.com/t/608836/java/java/Displaying-map-grid-simple-game )

How do those of you who have Java skills go about making a program that has multiple components (ie. a player (and that player's hit points, attack damage, etc), moving the player from space to space, displaying a map of the spaces, etc.)? Do you draw it out on paper first? Just start coding and adapt as you go? What I'm struggling with is trying to figure out how many different classes I should use, what methods they should have, do I actually need that to be a class or should it be in the main method, etc -- basically how to break up the project into doable chunks. Just curious as to what approach is typically recommended.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Hans Hovan wrote:Do you draw it out on paper first?


Yes. Use cases, notes, "stories", diagrams, etc.

Just start coding


Absolutely not.

and adapt as you go?


Yes. You need a decent understanding of requirements whatnot before you start coding, but you don't have to have every little detail planned out. And as you start coding, you may change your mind about some things, or find out that certain parts of your design don't translate well to code, so you go back and revisit them.

What I'm struggling with is trying to figure out how many different classes I should use, what methods they should have. do I actually need that to be a class or should it be in the main method,


Lots of classes. Short methods. Main should do nothing but create an Application object (Game, Calculator, Simulator, whatever it is you're making), maybe a bit of initial configuration, and start it running. There should be no business logic in main.

Each class should represent one concept or abstraction in your domain. Each method should have one well-defined responsibility. Expect lots of classes and lots of methods. It's impossible to predict the number of classes you'll need, and of course there's no one right way to do it, but even for the most trivial game of this sort I can imagine, I came up with 10 must-have classes off the top of my head with no effort, which suggests it will probably have at least 20 or 30. And if you make it "simple" instead of "ridiculously trivial," that number will easily climb to 50 or 100 or more. And that's not counting all the core API classes you'll use.

Hans Hovan
Greenhorn

Joined: Mar 03, 2013
Posts: 29
Thanks for the suggestions and comments.

OK, I think I was thinking a little big too ambitiously for my current skill level. I'm going to focus on something smaller first, like having the 'player' just exist.

Now, you suggested that I should break things up quite a bit into classes and methods. So, for example let us say that the 'player' will have a name, a life (HP) value, and an attack value. Would you, in your experience, suggest that each of those three things have their own class? Then I'd create a separate object of class player name, HP, and attack value to use throughout my program. And then in class HP, for example, I'd have a HP constructor, setter, getter, and whatever else I might need that has to deal with HP.

I'm just sort of trying to conceptually wrap my head around this to figure out the best approach. Because when I think of a 'player' I think of it as that player is an object, but really that player is made up of several different objects that all work together in various ways.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Hans Hovan wrote:
Now, you suggested that I should break things up quite a bit into classes and methods. So, for example let us say that the 'player' will have a name, a life (HP) value, and an attack value. Would you, in your experience, suggest that each of those three things have their own class?


Possibly. Name, for instance, could just be a String, and in a lot of cases, that's what it will be. But there are those that advocate defining a Name class, even if all it does is wrap a single String variable. One advantage of doing that as general approach is that you won't accidentally provide a Name when you were supposed to provide, say, a PhoneNumber, and vice versa, since each would have its own class. Another advantage is that later if you want to add behavior to a Name beyond what a String can do--something special about "names" is your domain--then you can do that more easily.

On the other hand, using a separate class just for a name might be overkill.

Your call how you want to handle it.

Similarly for HP and attack value. In your domain model--that is, what these things mean in your game world--are they just numbers, or do they carry extra information or have extra behavior?


Then I'd create a separate object of class player name, HP, and attack value to use throughout my program. And then in class HP, for example, I'd have a HP constructor, setter, getter, and whatever else I might need that has to deal with HP.

I'm just sort of trying to conceptually wrap my head around this to figure out the best approach. Because when I think of a 'player' I think of it as that player is an object, but really that player is made up of several different objects that all work together in various ways.


You're definitely on the right track. For a player, a map, a turn, whatever--any object or concept or abstraction in your domain--you think about what properties it has, which generally translate to member variables, and what behaviors or actions it can perform, which generally translate to methods. I say generally because it's not usually a complete one-to-one across the board, but those mappings are a good starting place.

And for any of those properties or behaviors, each one could in turn be composed of other properties or smaller, more detailed behaviors. One of the key tenets of software development is that you always have to be willing to break something down into smaller, more manageable pieces, so it's good that you're already thinking along those lines.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Advice for a greenhorn attempting to make a program with multiple components (classes, methods, etc)