Avoiding verbosity and annoyance in Java

Gullible Jones · 2010-10-18 18:46:54

Let's say I'm working on a Java program, say a simple RPG. I have the classes Party, PlayerCharacter, and the Item, and Spell.

Now let's say I want to have a character use an item that casts a spell.

If I want to do this the sane way, apparently I should have:

- A cast() method in Spell that makes the spell happen
- A use() method in Item that invokes the Spell the Item contains
- A useItem(Item) method in PlayerCharacter that invokes the use() method on that Item
- A useItem(PlayerCharacter, Item) method that invokes the PlayerCharacter's useItem method

I think this is way better for maintainability than

party.getPlayerCharacter(sam).getItem(wandOfFireballs).getSpell().cast();

However it looks to me like all these methods would make the code very verbose and lengthy. Is there a better way of doing this stuff, or is OOP just like this?

drm00 · 2010-10-18 20:07:15

I'm really not an expert, but my code looks like yours

urist · 2010-10-18 23:21:58

Could spells be items or could both be a subclass of something? Both items and spells (presumably) produce some change. What's the difference between, say, a healing potion that heals 20HP and a heal spell that heals 20HP other than its name?

Mind, I'm coming from a background of roguelikes where lots of people think everything (players, monsters, items, etc) should inherit from the same base class.

Gullible Jones · 2010-10-18 23:50:26

Hmm that's an interesting idea. Not sure.

I was thinking in much more general terms when I asked the question, but I am on-and-off working on a long term Java project, and it is an RPG - a rewrite of Blades of Exile of Spiderweb fame.

In the long term, FWIW, I'd ideally like to make PCs, NPCs, and items editable from the command line; and to eventually allow scenarios to be written just using Java, instead of the annoying point-and-click editor that BoE comes with.

(And yeah, I'm aware this could take a LONG time, and I may get bored with it and not finish. The original code is absolute spaghetti as well, so I can't really look at it for reference much. But hey, if I learn a bit more about coding in the process...)

Last edited by Gullible Jones (2010-10-18 23:50:57)

Anikom15 · 2010-10-19 02:39:29

party.getPlayerCharacter(sam).getItem(wandOfFireballs).getSpell().cast();

Now, children, this is our finest programming paradigm!

Gullible Jones · 2010-10-19 14:39:31

Well in Java's defense that's not the correct way of doing things, the correct way just happens to be damn verbose.

Basically what I'm looking for is a way to directly access objects within objects within objects within objects, without invoking layers of methods. Sorry if that's kind of vague.

drcouzelis · 2010-10-19 14:47:11

Gullible Jones wrote:

- A cast() method in Spell that makes the spell happen
- A use() method in Item that invokes the Spell the Item contains
- A useItem(Item) method in PlayerCharacter that invokes the use() method on that Item
- A useItem(PlayerCharacter, Item) method that invokes the PlayerCharacter's useItem method
I think this is way better for maintainability than
party.getPlayerCharacter(sam).getItem(wandOfFireballs).getSpell().cast();

First, of course there are so many different ways to program the same thing, so either way will work fine I'm sure.

Second, no matter which way you write it, try to remember that one of the main goals in programming is to have no code duplication. If you ever find yourself copy-and-pasting sections of code, you have a pretty good hint that you should try a different design.

Third, this example looks strange to me:

party.getPlayerCharacter(sam).getItem(wandOfFireballs).getSpell().cast();

You are missing something important in your example: who calls this? I can't imagine something as high-up as "whatever holds the 'party' variable" would be calling it. Instead, maybe "party.update()" would call "player.update()" on every player, including on "sam".

Wait, now that I look at it more, why in the world does the "player" even need to know that there is a "cast" method? Why doesn't the player just use an "item.use()" method?

Finally, the two ways you described (and everything I described) look to me like very naive or simple OOP. There is a higher level of OOP that you may be interested in. I've studied it in one graduate level course so far, but don't feel like I could describe it very well. It has a lot to do with design patterns. The book we used was Design Patterns Explained, which was pretty good, but I'm sure there's a better source for learning hardcore OOP. Maybe someone else can recommend something.

Anikom15 wrote:

Now, children, this is our finest programming paradigm!

I (think) I agree with you. OOP is way over taught. For fun, I'm making the game I'm working on now NOT in OOP.

DISCLAIMER: I have the flu right now and am not thinking so clearly.

drcouzelis · 2010-10-19 14:48:21

Gullible Jones wrote:

Basically what I'm looking for is a way to directly access objects within objects within objects within objects, without invoking layers of methods. Sorry if that's kind of vague.

Wait, are you trying to do structural programming in an object oriented language? If that is the case, may I ask why?

Gullible Jones · 2010-10-19 15:19:20

Re naive or simple OOP - yeah, I am a newbie, and the OOP course I'm in now is... pretty basic. I can write code, but I can't program very well at all, if you get my drift.

Re the way I'm calling it... Very good point. It wouldn't be called by the party would it? It would be called from the interface and sent directly to the item. So to that extent I was creating a problem through bad design.

Re structural programming... Umm... Not sure. Because it looked like it might be less work?

drcouzelis · 2010-10-19 16:18:44

Gullible Jones wrote:

Re structural programming... Umm... Not sure. Because it looked like it might be less work?

I think I used the wrong term. It looks like you are trying to do procedural programming in an object oriented language.

Anyway, it probably doesn't matter. In OOP, a simple goal to remember is to "make objects take care of themselves". How about "player.useItem(item)"? And where does "item" come from? How about an item menu? "itemMenu.show(player.getItems())" could allow a player to select which item to use. After they select one, use a method called "itemMenu.getSelectedItem()". Of course, there are many many other ways to do it.

I like your comment about how "it looked like it might be less work". I think you should totally do it whatever way you think is easiest and simplest, which may not even be with object oriented design or Java. If you get stuck at some point, then you can work on finding a new solution for the specific problem you are working on.

Gullible Jones · 2010-10-19 16:48:08

The reason I'm using Java is basically cross-platformness, and that I'm more familiar with it than any other language; and for a game, OOP seems sensible to me. Also the notion of using a different paradigm than the original code strikes me as nice, because the original code is fugly to the point that it would probably be better to just rewrite, than to port directly to another procedural language.

(And I'm less familiar with procedural programming than OOP, generally. I have some vague idea of how you might write a game with interacting objects and one main() method to run it; I have no clue at all how you'd write a game using subroutines. If I were porting the old code to say Python, I'd be doing it blindly, and if I were rewriting it in some other procedural language, I'd have no idea what I was doing.)

Also, the major Java IDEs have GUI designers. AFAIK there's nothing like that for Tk, which is a major disadvantage. I could use Qt or GTK or WxWidgets bindings for some other language, but those are huge fancy toolkits and this is a small simple game. Basically the same holds for Mono; running Visual C# in Wine for the Winforms designer would be inconvenient, and gtk-sharp would be way overkill for this. Also I don't want to use Microsoft's language for cross-platform stuff because I don't know if Mono might vanish beneath a pile of lawsuits.

(Yes, I know Microsoft made a legally binding promise. But Microsoft is a huge company with considerable legal and political influence. For them the law has enough flexibility that I don't trust their promise.)

Last edited by Gullible Jones (2010-10-19 17:09:30)

awkwood · 2010-10-19 19:37:07

To avoid the over-verboseness of Java I use JRuby.

It allows you to use the original Java libraries easily but without all the needless typing

tinhtruong · 2010-12-20 16:07:42

Or Groovy if you intend to invest in Grails in the future

ojw · 2010-12-22 13:24:49

Or Clojure if you want a lisp for the JVM! (And want to learn to program functionally.)

Arch Linux

#1 2010-10-18 18:46:54

Avoiding verbosity and annoyance in Java

#2 2010-10-18 20:07:15

Re: Avoiding verbosity and annoyance in Java

#3 2010-10-18 23:21:58

Re: Avoiding verbosity and annoyance in Java

#4 2010-10-18 23:50:26

Re: Avoiding verbosity and annoyance in Java

#5 2010-10-19 02:39:29

Re: Avoiding verbosity and annoyance in Java

#6 2010-10-19 14:39:31

Re: Avoiding verbosity and annoyance in Java

#7 2010-10-19 14:47:11

Re: Avoiding verbosity and annoyance in Java

#8 2010-10-19 14:48:21

Re: Avoiding verbosity and annoyance in Java

#9 2010-10-19 15:19:20

Re: Avoiding verbosity and annoyance in Java

#10 2010-10-19 16:18:44

Re: Avoiding verbosity and annoyance in Java

#11 2010-10-19 16:48:08

Re: Avoiding verbosity and annoyance in Java

#12 2010-10-19 19:37:07

Re: Avoiding verbosity and annoyance in Java

#13 2010-12-20 16:07:42

Re: Avoiding verbosity and annoyance in Java

#14 2010-12-22 13:24:49

Re: Avoiding verbosity and annoyance in Java

Board footer