Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Hello i'm new to slick (and lwjgl) and was wondering if its best to stick to one class or multiple when I used straight java I used multiple classes but wasn't shoure about slick
Please do use multiple classes. Classes keep things organized, and it is easier to document. Also, you can use an ArrayList to have a lot of class instantiated and use them later on. The most important thing about multiple classes is that it is organized. It is hard to use only one class for a game, because there will be a lot of code, and you need to try to pack together everything. Use multiple classes!
Java is an object-oriented language for a reason, and classes are there to help you. Using multiple classes will allow you to break down the game logic and view it as the interactions between objects of different classes, limiting complexity and making the game easier to understand. I'm not sure what kind of game you're writing, but for example, you could have a Player class, of which the active player is a member, tracking things such as health or lives, position on screen, et cetera. The player object could then interact with objects of class Monster, Wall, Door, Chest, so on and so forth.
Using classes allows you to reuse code and avoid repeating yourself, manage the complexity of the project, and encapsulate logic. When you're working in Java, an object-oriented language, it'd be wise to try and write code that follows an object-oriented paradigm.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Recently I am working on an applications (in Java and C#, but I think the problem is not closed to those languages) where I use a few container classes (which responsibilities are storing data in a proper order) and services being method packages, operating on data stored in container classes. All of the classes mentioned above should have only one copy existing in memory, and all of them are expected to be in the memory for the whole time the application is running.
I used to think that a singleton is a good idea here, as I am sure there is only one instance of each class, so it meets my expectations. However, I learned that the Singleton pattern is deprecated, as it hides dependencies and so on. Then I heard that for such usage (always available container class or method package) static classes may be a good idea. On the other hand I recently looked at a few projects where people refused to use any static stuff, as if it was an awful practice to do so.
My question is simple (at least in its formula): are static classes a good idea for creating always available, easy to hanlde containers and method packages? If not, what should I use instead (if not singletons)?
You don't really say where the data comes from. If the data is static, then a static class is a fine solution. For example, I could envision a static class to represent the 50 US states.
In contrast, for a class that represents a list of authorized users, I would use a singleton pattern. Although there is only 1 list, that list could change while the app is running.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm have to use 50 different custom datatypes(/classes) which are defined in a document(xml/json), they have only fields and no methods and maybe strong validations.
My question is should i go ahead and create(/generate) 50 classes or use some generic data structure (like HashMap<String,Object>)?
Update: My fear is if i go with class geneartion, then my codebase might increased by very much
and if go with schema-less way, my data integrity might be compromised, so which one is lesser evil.
Unless it is just ridiculous, more code is more forgivable, in general. There are a few different reasons:
If you give them base classes at the right points, you can have it both ways, as your handling code can hold the base classes, and may have anchor points for extracting, validating or cleaning information stored in the different formats. Surely some of the processing can be shared.
If absolutely everything really falls to the base class, you can refactor the sub-classes out of existence without pain. On the other hand, if you start the amorphous way, gathering the special cases back into separate classes is more likely to go wrong.
Excessively large code is only bad if the extra volume does not clarify the logic for readers. I would have the classes, if they constitute units in which people think.
Also, actual functionality is more important than format or even readability. So if the risk is to data integrity vs code bloat, protect the content, not the form.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
This question is relatively easy to answer but i don't really know the answer as i have no real experience with java or libgdx.
Question: I would like to know the most effiecent way to orginize code in java, i have a strong background in php and in my php projects i would use several different php files (think of it as a class) and just reference it in my main page using either "include 'filename'; or require 'filename'; " . I would keep my header.php, content.php and footer.php completely separate and just reference it. This was a very nice method for me as it really kept my code organized.
What i want to know is if there is an easy way to do this in java/libgdx? i am currently making an android application and as you may know there are life cycles such as create(); render(); resize(); etc.
What i had in mind was to put each cycle e.g. create(); into a class of its own and use extends in my main class. Will this even work?
Thanks for any help in advance guys, its really bugging me to have so much of my code in one main class.
The question is very abstract, and you can read lots of books or articles about OOP, design patterns and code styling, so I will just give few practical tips:
You can use MVC pattern. Create three packages yourpackage.view, yourpackage.model, yourpackage.controller and split your classes by this model.
You can create package yourpackage.utiles and put there all classes with only static methods, which are used in all your app.
Don't put too much code into one class, Java is very objected oriented. Very simple example: you have game with 4 screens. You should create parent Screen class, 4 classes which will be extended from Screen for every screen and class ScreenManager which will change screens.
In game dev Singleton is very useful pattern. You can use it for GraphicMangaer, charcter progress holding, dpad controller, etc.
About your question, there is no reason to put create() method into your classes, constructor is enough. What you can do is to create draw() method in every class which draws something and put there all logic of drawing. Then you can just call draw() methods of your classes in your screen render() method.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Suppose I am writing an application for simulating vehicles of all types. Should I now organize packages based on the different type of vehicles e.g.,
com.example.vehiclesimulation.car
com.example.vehiclesimulation.truck
com.example.vehiclesimulation.bus
com.example.vehiclesimulation.motorcycle
or should they be organized in a structure based on the functionality e.g.,
com.example.vehiclesimulation.transmission
com.example.vehiclesimulation.interior
com.example.vehiclesimulation.steering
com.example.vehiclesimulation.electronics
Often package structures get complex as we move deeper into the structure one is clueless whether to form a subpackage or a sibling. In the above case, we could have the ontological packages as parents and then have all the functional ones as their children, and vice versa. So which one is more appropriate and why?
EDIT: It may be noted that this distinction becomes more complicated when there are deeper levels and at each level one has to choose betwen the two axes. Fo instance, should the class XYZHeadlight go under c.e.vehiclesimulation.car.XYZ.electronics or c.e.vehiclesimulation.electronics.car.XYZ or c.e.vehiclesimulation.car.electronics.XYZ?
I think it really depends on the type of package. Your example in not really a good one. I would advice structuring based on functionality, but rewrite the example as follows:
com.example.vehicles.car
com.example.vehicles.truck
com.example.vehicles.bus
com.example.vehicles.motorcycle
but the following "things" are not vehicles - they are parts that can be used in vehicles:
com.example.vehicleparts.transmission
com.example.vehicleparts.interior
com.example.vehicleparts.steering
com.example.vehicleparts.electronics
and now in your car you can use com.example.vehicleparts.transmission.
However sometimes you might want to use package private fields and method, in that case you could put them all in one package to deal with it.
I would structure them based on their functionality. The only reason I got for this is to be able to "share" components between different vehicle types, e.g. a transmission of a truck that is also used on a bus could be better placed in the second (functionality-ontological) structure, I guess. Nevertheless, it feels to me like it's just a matter of taste.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been hunting for tips on good Java coding practices, by looking at the code of accomplished programs. My first target was Minecraft, since I'd tried my hand at modding it, and I started to question my choice. Here was code from an accomplished game, and it was giving me two very different ways to go about things.
For those who don't know, Minecraft instantiates its items once and subsequently references that single instance and its methods for any operations it needs to carry out, using information from other sources for the method parameters. Its entities, on the other hand, are instantiated once for every individual entity in the world and are responsible for their own information.
So, the crux of the issue is: Which method is more efficient? Is there a particular reason to favor one over the other? Is it situational? Is it more efficient to do it one way or the other?
The answer is, in most cases, it depends.
What you describe is the singleton pattern, which there's one and only one instance of an object. This is beneficial if having more than one instance is either expensive (such as multiple instances of a DAO), or doesn't make much sense (such as multiple instances of a DAO).
Individual instances of objects is necessary if you hold two separate, distinct instances of the same class - for instance, say you're holding two diamond pickaxes. I wouldn't imagine that a singleton would make sense in that context, since you can interact with each pickaxe individually.
Use the pattern most suited for the situation. There is (and won't ever be) any one-size-fits-all way of solving problems like this.