Develop Reference

Whats the right way to separate model and logic [closed]

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 6 years ago.
Improve this question
Hi I'm setting up a new project and was struggeling with Java Annotations.
Are they related to Logic / API or Model
In Detail:
I have a started a multi maven module for example:
project-parent
project-model
project-persist
project-logic1
I separated model from every other module simple POJOs with JPA.
To use them with different frontends or REST etc.
Now I wanna use annotations from project-logic1 in the model.
Now i'm confused with the seperation.
Should I make an own API module (project-API) for this and similar annotation / interfaces
Should I simply add the annotation in the project-model
Should I add the dependency of project-logic1 into the project-model POM
I think the first one is correctly but I'm not sure.

From what I understand, you shouldn't use your model objects (with the JPA annotations) as DTO in your project.
You should have your model within the logic project, so DB related items are un the same place, and you create and API project with only POJO, not related to your DB, so you can use this API for REST services' answers and keep your implementation hidden.

If you have common code, I would suggest to wrap it into a dedicated module, so I would agree with your "API"-Approach (although the label "API" might be too much here).
Do not cross-reference your modules, dependencies must always go one way. And: Never repeat yourself, so c/p-ing your annotations is fundamentally wrong ;)

In Java design is composition not used much anymore? [closed]

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).

Model classes and external libraries best practices [closed]

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
I am developing a MVC rich GUI application in Java and I have to use an external scientific library which already defines most of the classes that I will potentially use in my domain model. What are the best practices in this case? may I need to wrap all the classes defined in the library with interfaces?

Personally I would wrap 3rd party classes into implementation of my interface if:
the 3rd party library is still evolving (new changes are expected)
the 3rd party library is not solving all my issues
I don't want to stick with only one provider (of the scientific library)
my application is long term project
Otherwise I would us the 3rd party classes directly. Introducing unnecessary layers of abstraction at the beginning of the project is very often waste of time.

Design patterns package independence [closed]

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.

Code organisation and differentiation between tools and utils packages [closed]

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 6 years ago.
This post was edited and submitted for review 6 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
About code organisation in packages, i have seen both tools and util used for the same purpose, ie. to contain classes that help with trivial and frequent tasks.
Example:
+ foo.util
|-- StringManipulation.java
|-- MyLogger.java
+ foo.tools
|-- InputSanitization.java
|-- IdentifyOS.java
|-- Whatever.java
From your experience, is there anything that distinguishes tools from utils?
How should such reusable code be organised?
What is the generaly accepted responsibility (historically or semantically) of both and when should I use one over the other when organizing my code.
Conversely, where should I expect to find the more specialized or on the contrary more low level code in those.

Classes within the same package usually share the same or similar functionalities, or they together achieve a set of similar functionalities. In addition, classes within the same package can access all package-private variables (i.e., those variables defined without public, protected, and private) within their package.
As for naming, while Oracle has defined a convention for java naming packages, it is developer's responsibility to have a clear naming for each package. In your case, it is better to have some descriptions to describe the utilities and tools. Here are some examples:
foo.connection.tools
foo.string.utils
In this way, users can know the tools is for connections, utils is for string manipulations.

Both "tools" and "utils" are bad names for classes/packages. It is not object oriented. It is a way of saying, "I don't know what to name this thing so I'll just give it a generic name".
What you should do is figure out what these tools/utils are really doing and name them appropriately.