StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>In your case, using enums is not a good idea. Enums are inherently immutable things, a fixed set where no new elements may be invented and no existing elements may be destroyed. Weekdays, months of the year and cards suits are a good example of enums, the existed set is fixed and immutable, no new element will never be created and no existing element will ever be destroyed. Animal types, music genres, tilesets, etc, does not follows these rules.</p> <p>The better is the most obvious: Define an interface or abstract class Animal. And defines all the types of animals as a subtyping.</p> <p>Switches are as evil as goto, they are simple, are easy to use, looks innocent, but in the end transforms your code in a spaghetti jungle. Instead of using the switches that you want, use polymorphism. I.E:</p> <pre><code>// Don't: public class SomeClass { public void myMethod() { switch (animal.id) { case TYPE_CAT: doSomethingThatCatDoes(); doSomethingElse(); anotherThing(); break; case TYPE_DOG: bark(); doSomethingThatDogDoes(); otherThing(); break; } } } </code></pre> <pre><code>// Do: public interface Animal { public void myMethodAction(); // Other methods. } public class Cat implements Animal { @Override public void myMethodAction() { doSomethingThatCatDoes(); doSomethingElse(); anotherThing(); } } public class Dog implements Animal { @Override public void myMethodAction() { bark(); doSomethingThatDogDoes(); otherThing(); } } public class SomeClass { public void myMethod() { animal.myMethodAction(); } } </code></pre> <p>The code tends to become larger when you do this, but this does not means more complex. Instead, it became better organized, because the SomeClass does not needs to know the exact animal type anymore, The logic particular for each animal type is all in one only place, and if you need to change the behaviour of an animal, you won't need to search and change a lot of very distant places. Further, it becomes much easier to add new animal types. As you should see, your project becames more flexible for future changes (i.e, easier to change, harder to break).</p> <p>You should note that I did not used explicit ids. Avoid ids, because they are vicious and you already have them implicity. Each object has a unique memory address, and that memory address is the id. So, your <code>public int mType;</code> field would become a <code>public Class<? extends Animal> mType;</code>. If you really need these ids, make them as short-lived as possible and the less used as possible. The reason for this is to use OO beter (I will explain this below).</p> <p>More, your TypeInfo is just a bunch of public attributes. Please, never-never-never think about of doing this. In OO, public attributes are as hateful as gotos and switches, and THEY SURELY WILL WITH 100% OF PROBABILITY undermine your project. Instead, whatever you do that needs to handle the fields, put in the TypeInfo class and make the fields private. This does not means replacing public attributes by brain-dead getters and setters, instead, put your business logic there.</p> <p>I strongly recommend that you study some OO deeper. Specifically true encapsulation (some people says that adding a bunch of brain-dead getters and setters is ok, but it isn´t, this is not true encapsulation). Study polymorphism, not just what it is and how it works, but how you can use it and why. And the most important, study cohesion and coupling, to make classes that makes sense, fairly independent, reusable and flexible.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload