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 8 years ago.
Improve this question
My package is in:
com.user687111.mygame
From there; is there any guidance on how I should be structuring my program? I have subdirectories for maps, entity, gameobjects, camera, controller, etc. This is fine; but as the game grows there is going to be a ton of subpackages.
Is there a "best practices" or a common convention used? Even if it's not official, if I ever take another programmer on, I don't want him to go "wtf is this?"
Maybe you want to look into patterns like MVC (Model View Controller) to structure your application.
Also, Domain-Driven Design can be of help. You probably have something like a domain.
I'd also expect that you have services that operate on domain objects and controllers that handle interactions with users/requests.
"camera" seems to be an infrastructure element. I would not create a top-level package for this, but maybe i misunderstand your naming in this case.
Related
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 2 years ago.
Improve this question
I've learned the UML recently and I am trying to build a MonsterDuel system. However, there are a lot of classes in this project, and I am confused about the abstract class and its usage. Now, I have created:
Abstract class Players, and its inherited class Player.
Abstract class Field
The multiple card classes associated with each other.
Apart from the getter and the setter, is this structure clean and specific enough to proceed on java coding?
And, if it's not, what can I improve?
Any opinion or suggestion is highly appreciated. Thank you for your time and patience.
I would start with what you have there.
You can generate the Class stubs and then stat filling them with the logic.
In general I would do increments. Between implementing and updating the Diagram. UML is a good tool for helping you visualizing where your code is going and find out if something is moving into the wrong way.
I never had an project where the UML was super detailed and the code was in the end representing it.
So as a short answer: Yes this is good enough, but do iterations and revisit and adapt.
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 7 years ago.
Improve this question
I'm trying to improve the clarity of my communication with other developers.
There has been times I've found when I'm describing to other developers to use the # symbol in code and found that I hesitate then say its name three different ways. I say pound, hashtag and octothorpe (but it doesn't stop there, as it's sometimes sharp in the case of music and C#).
Some examples of its use are in C++ for includes, used in SQL for comments, and used in Java's EL as #{}
I like things to be done simply and consistently. I am curious if there is a standard way (or more universal way) of referencing the symbol by name, and if so what it is. Or is there a different standard for referencing it by different languages, or even SQL?
It's not pound, that's £
It's not hashtag, that's Twitter.
It is "hash" though. And in the case of the language "sharp".
It's all based on what you choose to call it where other developers will understand. It's up to the user to decide what you choose to call it and if you are working with others it's up to you guys to have good enough chemistry to know what each other is talking about.
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 8 years ago.
Improve this question
I'm trying to make a small crud application using swing, with Authentication features and GUI.
Can you give me the right organization and naming of my packages ??
There's no hard and fast rule, but the rule of thumb is to start with your company's domain name in reverse:
com.mycompany
Then add on the project:
com.mycompany.project
This ensures you're unlikely to have clashes between your classes and those from the libraries you depend on.
Then personally I try break things down by their functional groups, for example
com.mycompany.project.domain // contains the business domain classes
com.mycompany.project.io // contains the classes that deal with network or file-system
com.mycompany.project.persistence // contains the classes that handle persistence of the business domain classes
com.mycompany.project.ui // contains the user interface related classes
Within those packages, I might have further group but that would be very specific to the project.
The important thing is to be consistent across your project.
Short answer: One package per module/feature, possibly with sub-packages. Put closely related things together in the same package. Avoid circular dependencies between packages.
Long answer: I agree with most of this article
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 8 years ago.
Improve this question
A Java developer (with lots of experience in sophisticated, high-performance environments) very recently commented that "composition is not used much anymore." I was surprised by this comment. Is this true?
On the one hand, other answers on this forum indicate that difference between composition and aggregation can be ambiguous (can the whole exist without the part; does the part exist throughout the life of the containing object?). But perhaps in all of these cases the question stands--how to add behavior to an existing class or class hierarchy.
The context of his comment was a discussion of possible alternatives to inheritance. If this developer is correct, what has replaced composition in working practice? Mix-ins through added interfaces?
Any perspectives are welcome!
If anything, it's probably used now more than ever thanks to dependency injection frameworks like Spring. The model that all of the Java developers I know use is to build classes that relate to one another in functionality more by interface and purpose and to use Spring to inject them according to a particular configuration (ex the ability to replace entire security frameworks just by changing a spring configuration file and adding a few new JAR files).
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
My question is fairly simple, I haven't found a direct answer to it.
Is redundant code between two or more packages to achieve package independence considered as a good or bad practice, for instance I have two packages one does a download-and-cache , the other is for readfromserver-and-cache. while cached data and mechanism are completely different but have some common classes/methods.
Shall I create a third package which holds commons, and break package in-dependency?
Or shall I continue with two packages and will result in redundant code?
Lastly, to go deep in design and dependency, I'd appreciate it if you suggest me good material to read.
*Please note : I write in java , common code is not that much
I think that you go for creating an interface for the Cache. If the cache is not the same for both packages then common code can be in a abstract class and the individual packages can implement the rest.
Of course if the code is identical, then strip it out to its own jar.