This maze has multiple entry points, and quite obviously multiple exits. The entry or exit is not provided at input. Of the multiple sources and destinations, any single path from any source to any destination should be returned. The path need not be the optimal or shortest path.

The enum Direction is so called nested. I mean not a separate Java file but internal to the Maze class and it is also static. Is this the right way to do for enum? I have followed the prototype of Node class in Sun's linkedlist.java.

2 Answers
2

Here are a few comments about the style. You'll find comments about the algorithm itself at the end.

Naming

The 3 at the end of the class names is a bit awkward.

The same kind of things are sometimes called x, dx or row.

(Coordinate and Direction look pretty similar too but trying to merge them showed me they were actually different in the spirit.)

Getters

In Coordinate and Direction, the members are constant (either explicitly with final or just because no method changes them). Though, you don't need to bother defining getters, just make them public and that will be it. (I am quite aware that this is not the way most Java developpers see things but at least you get a different point of view).

It's a bit weird to compare the content of the maze to 1 every time. It would probably be easier to define the type of the content as a boolean.
As a drawback, it does make the definition of mazes more tedious.

The method you've defined that takes x and y as parameters should/could take coordinates.

Let's work on the following example to see what you've done and what you could do.

Assuming I've understood everything, you basically bruteforce by trying to go down then right if you cannot go down then up if you cannot go right and left if you cannot go up.

What you could do is a slightly smarter algorithm which would actually tell you not only how to go to an exit but also the best way to do so. On can find a few examples on Wikipedia. The Sample Algorithm is pretty close to what are are trying to achieve.

I cannot tell whether it would be more efficient than yours but it would have a few advantages such as :

having the same solution no matter how your maze is oriented (at the moment, a problem can be easily solved but the same maze turned or reversed could be much harder)

knowing that the algorithm won't "get stuck" in some "useless" parts of the maze (it is quite easy to design an problem that would make your solution go pretty crazy)

I cannot a proper analysis right now but I'd be willing to very that the worst case is much worse than what you have found. It probably correspond to the number of path in a n*m angle and this is likely to be a lot.
–
JosayFeb 8 '14 at 9:32

Josay's answer is perfect for improving your logic and coding style. But you are also looking for best-practice. Now in your code you override the hashcode method as

return row + col;

This is very bad cause for two CoOrdinates like (2,3) and (3,2) will return same hash. This is pure evil if you use your Coordinate class in Map. Now if you are using any modern IDE like Eclipse/NetBeans you can auto-generate the hashcode method.

I'm not supplying a single reference here:Objects.hash(this.row, this.col); though, am I? Also a class containing a single field need not have the same hash code as the hash code of the field. Also see the example right above the warning, and compare with my edit.
–
abuzittin gillifircaFeb 10 '14 at 13:04