I've been discussing with a friend about how to avoid using instanceof.The most obvious answer is to have a proper design in the first place.However the previous argument on these forums over instanceof was about why Java needs it and not how to overcome the issue through proper design.

I've pretty much tried to come up with a paper solution on how to remove dependency on instanceof, one of the assumptions is that both classes (Board and MagicUser) absolutely must know the class type of the BoardPiece.

SImple. Im goign t odo this in java5 cause ist cleanest but simairlt echniques work for earleir kidsn of Java

Boardpiece, which i assume is an Interface (but coudl also be an abstract class) defines the following:

enum PIECE_TYPE {PAWN, KNIGHT, MAGIC_KNIGHT}

public PIECE_TYPE getPieceType();

Each peice type then over-rides getPieceType to return the apporpriate enum.

If BoardPiece is an abstract class then getPieceType() is defined as an abstract method.

If you arent udner Java 5, you use int and public static final int constants ( or Josh Bloch's "secure enumeration" pattern) instead of the enum.

JK

Edit: Its shoudl be noted that this really doenst solve the REAL problem. The user is still likely going to start doing switches on the returned peice type which is almost always wrong. It usually indicates incorrect object design.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Design has always been an issue. I would like to know when Java will incorporate a fully functional OO design so that things like instanceof are deprecated.I've avoided using instanceof for a long time now however it still must be used when overriding the equals method.

Design has always been an issue. I would like to know when Java will incorporate a fully functional OO design so that things like instanceof are deprecated.I've avoided using instanceof for a long time now however it still must be used when overriding the equals method.

I don't understand why you think inststanceof is so bad. What do you mean by 'fully functional OO design'?

The instanceof operator is useful in several 'OO' design scenarios. I use it extensively in an action validation system I implemented in my current project. I use it there because it makes sense. I'm not using it in any other systems in my project. Does that mean my project, or at least that particular system, is poorly designed? Does that mean my project is not 'full OO' (whatever that means)? Not even.

I've heard people say that using instanceof is indicative of a bad design, but that's rubbish. It's like the goto argument in C. Abusing the instanceof operator is bad design. And by abuse I mean designing your code around it, or using it when where it doesn't make sense to. In those cases where it does make sense it is an elegant solution. I'll be happy to give you an example of what I mean.

For me the only part of the program where I should not use instanceof is in tight-loops, because it quite a heavy operations. Everywhere else may be perfectly justified to use instanceof and should not be discarded as non-OO or not-fully-functional-OO (whatever that means...!). It's just one of the tools that Java allows you to use, one should not avoid it just for the sake of it.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

surely one preferes compile time checking over runtime checking, however deprecating instanceof is a whole other step. sure you can stuff and should stuff instanceof as low/early in your code as possible I can't see going without it.

"instanceof" is a tool like the rest of java. Use it where it makes sense. Deprecating would be a mistake. Implementing the equals() method would be very annoying without it

However, surely the real solution is not to check the type of the object externally at all. Wherever you decide you need to check the type externally and perform some type specific functionality, put that functionality where it actually belongs - in the class in question (i.e. type specific functionality for maintainability should be kept with the specific type )

Poor example:

Interface Fruit. Two implementations Apple and Orange. Using instanceof (or any other external type check) you might have done:

For me the only part of the program where I should not use instanceof is in tight-loops, because it quite a heavy operations

When I was doing my entity framework and some AI stuff, i was worried about instanceof stuff, and changed to using getType() stuff, and I noticed that in a very crap microbenchmark, instanceof was 2 - 3 times FASTER than a method call...

When I was doing my entity framework and some AI stuff, i was worried about instanceof stuff, and changed to using getType() stuff, and I noticed that in a very crap microbenchmark, instanceof was 2 - 3 times FASTER than a method call...

I used to be under the impression that instanceof was slow. Then I saw the source for <a href="http://sourceforge.net/projects/seda">SEDA</a> a few years ago (a high performance, non-blocking, networking library - pre NIO stuff). Somewhere in the codebase there was an even handling mechanism which used instanceof to route events. I was surprised to see it at first. Now I know it's not so bad.

Design has always been an issue. I would like to know when Java will incorporate a fully functional OO design so that things like instanceof are deprecated.I've avoided using instanceof for a long time now however it still must be used when overriding the equals method.

instanceof will never be remnoved because it has legitimate uses. You can do the same things with reflection ops but instnceof is easier and produces cleaner lookign code for the msot commonc ases such information is necessary.

Those uses, btw, are typically in very special cases involving run-time loaded code where the class hirearchy is not known apriori.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

switch is the issue. 98% of the time when you see a swtich statement it means a crew up in the OO design as all such code-switchign decisions aught to be handled by your inegritance structure.

There are expections ther too, though. Packet handling woudl be *seriously* annoying without switch. Similarly some other linds of data parsing are really adied by it (like writing recursive descent parsers.)

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

switch is the issue. 98% of the time when you see a swtich statement it means a crew up in the OO design as all such code-switchign decisions aught to be handled by your inegritance structure.

Unfortunately, telling bad programmers that will only result in them doing the same thing with an else if ladder instead, then spending the rest of their careers fearing the "horrible switch statement".

What really NEEDS to be removed, however, is the do {...} while statement. It's almost as evil as come from.

I know what it's good for, but the syntax is just horrible.All other blocks have their flow control defined at the top. When reading code with a do {...} while block, you have to look down (or even worse, SCROLL down) to know what the block is about.

1 2 3 4 5

do{banana();}while (!isDone());

vs

1 2 3 4 5 6

booleandone = false;while (!done){banana();done = isDone();}

Sure, it's slightly more verbose, and it requires an extra variable, but at least it reads right.

I know what it's good for, but the syntax is just horrible.All other blocks have their flow control defined at the top. When reading code with a do {...} while block, you have to look down (or even worse, SCROLL down) to know what the block is about.

It makes sense though... the flow control is checked only after executing the body of the block, so the code is "where it should be" in that sense.

You have to scroll down to see what it is going to do AFTER running the body, not so you can see "what the block is about".

Maybe we should just get rid of while, do, and for, and use if and goto exclusively

One of my favourite additions that Java has that C/C++ is missing is the labelled break and labelled continue. I find they make the code much cleaner than introducing extra variables and logic in inner loops.

So I guess I prefer do..while to introducing that extra variable, and that "special case" init code outside the loop to "set things up so it works right for the first pass"... to me do..while is the cleaner solution. Though I do get where you are coming from with respect to the consitency of having all of the loop logic at the beginning loop statement. It's all about personal preference really... there is nothing scientifically right or wrong about either approach.

I think we have all heard lots of warnings about these things. instanceof, break, continue, multiple return statements, and so on. But these all have (few) legitimate uses, where they simplify matters a lot. The one syntactical feature of java which I cannot say this about, is the following:

1 2

int[] a; //An int-array called aintb[]; //An int called b, or, well, make that, like, a whole array of them now that we're at it, because now the caret is all the way over to the right of the identifier and I can't be bothered to use my left arrow key to go back and change it.

But I assume this was left in so the transition for C programmers would be easier

1

intb[];

I agree, it is lame.

I think you hit it on the head. To most of us, and to the Java designers, int[] makes eminently mreo sense but if you tink back to the beginnign of Java one of the reasons Java succeeded where any other simialr new languages failed is that transiton from C or C++ was realtively easy. Im sure this was to head of resistance to the chnage of syntax on arrays,

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org