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.
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 have written front-end of my application in SWT/JFace. It working well but problem is that all of the front-end goes in a few classes and some classes grow more than 10000 lines of code. Tell me is it normal to have classes in Java with more than thousands of lines of code or how can I reduce it?
It is definitely not good practice to have such huge classes and a signal to better refactor your code. See http://clean-code-developer.com for a clean code guideline.
You can't judge a java class on lines number. No standard can tell you about the preferable number of code lines.
The important thing to keep in mind is that classes should be designed according to proper OOP design using: encapsulation, polymorphism ...etc and java best practices.
But a Class with >1000 lines of code it's probably unreadable and have a bad loosely coupled approach.
If your number of code line start to increase quickly try to optimize your code and use dedicated design pattern like Strategy pattern and many others one.
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 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.