Java, Maven: Models and Utils Circular Dependency, Combined Naming Convension - java

We have a project that has several war files that reference one-another. I've recently realized that there is a circular-dependency between two, in particular, the utils and the models. Other services use both of these, and the utils was created for operations that would be performed on the models by other services. I was just curious what is best-practice here. Utils and models sound like they are companions to the main project, but I've never heard of a war file being called 'utils and models'... just seems strange.
Additional Info (not necessarily needed to answer the question):
To be more specific, the model uses the utils for it's type adapters, which allows MyBatis to convert timestamps to joda time. The utils uses the models, which I think is more acceptable, to do common operations on model objects.
Should I just combine both into the models war? What are some other options I would have. If I should combine them, is there some sort of design pattern that combines utilities and models together? What's the appropriate naming convention for a service that supplies both model and utility classes?


There are a lots of post on how you can remove cyclic dependencies like maven cyclic dependencies
But regarding utils a general advice is that utilities can be of two types in the sense that they are general or project specific i.e. if you are writing general utilities then those should not depend on any of your modules(they just perform general tasks) so should always come first in your reactor build order.
Secondly, for project specific utilities you can always do 'xxx.modals.utils' as in your scenario and these can easily consume your beans.
One more reason that general utilities(independent of your beans) should be kept in a different module is that they can be easily reused in other projects too. Hence you don't have to reinvent the wheel time and again!


I believe that the solution to your question would based on the view and experience and not a technical problem as such. I would suggest the following:
Go with Utils in same module if : Your Model classes' are not going to be reusable in other modules. In other words, if your Util classes is in relationship with Model classes only. It wouldn't make sense to split it as a module if your util classes are just designed for the specific model classes only.
Go with Utils in different module if : Your util classes are going to be generic. For example, your Utils classes are designed to convert the Model/Entity to Business Objects using some DataMapper like Dojo/Orika etc. That's coz, these util classes would not be tightly coupled to the Model classes as they would have the implementation to convert any type of Model to Business/Value Objects and vise versa.
This is actually been addressed by micro-services where you concentrate on loosely coupling the services which can survive independent of each other(like a plugin component).

Related

Where to put my framework classes using package-by-feature convention?

I've been reading a lot about package-by-feature naming convention. So I've decided to give it a try in a new project. However, I'm not sure how it should be named my packages that will be used by most of my classes, since I'm using a huge framework, such as Spring and Hibernate, for example.
This is how handle our Spring contexts classes:
And our database access class, the one that manages connections and so on.
I've a draft about this: using a common package for these frameworks, like:
com.company.project.common.spring
com.company.project.common.database
But I'm afraid that this still looks like package-by-layer a bit. :)
How the packages that will be accessed by my feature classes should be created ?

The common recommendation is "package by feature, not layer". What I often do is "package by feature, then layer". I also think that top-level packages should be "feature"-based (functional components, whatever). But I also like to have my layers separated into sub-packages.
From my point of view, framework-related code does not per se constitute "features" (as in "important, high-level aspects of the problem domain"), therefore package-by-feature is does not make much sense here. But still, this is important code and you need an approach to structure it.
I am normally use two approaches:
If I need to extend or augment libraries I'm using, I structure packages parallel to the package structure of the library. For instance if I'd need to implement some new number formatter for Spring, I'll probably name the package com.acme.foo.springframework.format.number, parallel to org.springframework.format.number.
However if I need to implement common base classes for layers of features, this would be probably something like com.acme.foo.common.<layer>. For instance if we have com.acme.foo.<feature>.dataaccess packages for data access layer of some feature, com.acme.foo.common.dataaccess could hold base classes for data access layers of all features.
Both approaches are used in parallel. You just have to decide whether some class is a framework or library extension (can you imagine using it outside this project?) or is it closer to the layers of your project.

Classes wrapping

I am new to OOP and java world and trying to understand the concepts.
There are three separate feature projects, each having their own abstract classes and interfaces. I am facing difficulty in wrapping these projects in my test automation solution. I am thinking of using Abstract factory pattern to create features abstract classes and interface in my test automation project. How can i wrap the classes in my project without direct referencing the feature classes.
Thank you in advance for your help.

Sounds like you maybe taking an over complex route..... The solution might be simpler:
Each project should be (at least) in its own package.
Packaging allows java to group classes together under certain namespaces so that their features do not intrude into other classes.
"A package provides a unique namespace for the types it contains.
Classes in the same package can access each other's package-access members."
http://en.wikipedia.org/wiki/Java_package

Interface usage in Java and PHP in case of GUI calling a module

I have a module1 (GUI) and a module2 (Ordering).
From module1 I need to access the OrderingService found in module2.
I can of course create an OrderingService interface and an OrderingServiceImpl as a concrete implementation. This is a good practice in relation to Dependency Inversion Principle (DIP).
From my knowledge in Java I can benefit from module decoupling (I can change OrderingServiceImpl but module1 will not be affected and RECOMPILED) and I can use dependency injection in Spring to automatically use the right implementation. Regarding TDD I don't think you really need to create a OrderingServiceMockImpl because you can use a Mocking framework to mock the concrete class OrderingServiceImpl.
When we only have a single concrete implementation is module decoupling the only real benefit? I see in practice a lot of developers that always create an interface but don't really use more then one concrete implementation and I'm trying to figure out if there is something more to it or not.
I can't just accept the concept create interfaces "hoping" you will benefit from them later on. Isn't more pragmatic to change the code to an interface when you really have two different implementations?
Also I would also like to understand this from a PHP point of view, because code compilation is not an issue in dynamicly typed languages.

The benefit of using interfaces is to let you work on smaller pieces of your system independently, in terms of testing, of course, but also in terms of the amount of details you need to concentrate on to write the code and to understand it when you look at months later. In some languages there are code management benefits too but this is not the primary motivation for using interfaces.

Let's change your example a little bit, because I would never start with the UI. Assume I am building the OrderingService which need a repository for storing and retrieving orders.
I would always create an interface for that repository, even if it is totally unlikely that I will ever have two implementations for it. The reason for creating it, that I do not need or want real data access at this stage of the development. What I do is "programming by wishful thinking". I imagine there would be this magic contraption that makes it possible to store and retrieve my orders. I specify how I imagine this as an interface. In my tests I mock the interface and can build the OrderingService without even touching anything DB related yet.
I do the same with other dependencies that are adapters to the "outside world" (repositories, clients for calling other services, event publishers, etc).

Java calling methods from restricted layer

I'm not even sure if this is doable but I want to ask the community for their general opinion.
I have to solve a following problem:
My Project has 2 Layers, a Core layer and a Business layer.
This Core layer is providing the Business layer. At this moment Business classes can import Core classes and do whatever they want. Core classes can only import core classes and use their methods, the access to Business classes and their respective methods is forbidden.
I want to add a specific feature:
I don't want to give Core any normal access to the Business layer, but I want to create something like an interface or anything similar (I don't know how to express myself here cause I have no idea if its possible), that provides the Core classes some specific methods from Business classes to use.
Can anyone help me out, or at least give me some guidelines what to read, or where to search.
Thanks in advance for any support.
Edit:
I use Spring Framework with Seam and JBoss

What you are probably facing is the design of module dependency and circular dependency. In short, the Business methods that Core needs may have to be re-factored into a 'utils' module or a 'Business-Core' module that is then accessible by both. I am only guessing here.
In addition to automating builds, a build tool like Maven also encourages such modularization and dependency. It is not unusual for a project that started off as one module to be split into 3-4 modules by the time it is done.

This can be achieved by using AspectJ. You can write rules in AspectJ-syntax which will give build-time-errors if not enforced. See the article Archtectual Enforcement with Aid of AspectJ for an example.

How should I structure a Java application, where do I put my classes?

First of all, I know how to build a Java application. But I have always been puzzled about where to put my classes. There are proponents for organizing the packages in a strictly domain oriented fashion, others separate by tier.
I myself have always had problems with
naming,
placing
So,
Where do you put your domain specific constants (and what is the best name for such a class)?
Where do you put classes for stuff which is both infrastructural and domain specific (for instance I have a FileStorageStrategy class, which stores the files either in the database, or alternatively in database)?
Where to put Exceptions?
Are there any standards to which I can refer?

I've really come to like Maven's Standard Directory Layout.
One of the key ideas for me is to have two source roots - one for production code and one for test code like so:
MyProject/src/main/java/com/acme/Widget.java
MyProject/src/test/java/com/acme/WidgetTest.java
(here, both src/main/java and src/test/java are source roots).
Advantages:
Your tests have package (or "default") level access to your classes under test.
You can easily package only your production sources into a JAR by dropping src/test/java as a source root.
One rule of thumb about class placement and packages:
Generally speaking, well structured projects will be free of circular dependencies. Learn when they are bad (and when they are not), and consider a tool like JDepend or SonarJ that will help you eliminate them.

I'm a huge fan of organized sources, so I always create the following directory structure:
/src - for your packages & classes
/test - for unit tests
/docs - for documentation, generated and manually edited
/lib - 3rd party libraries
/etc - unrelated stuff
/bin (or /classes) - compiled classes, output of your compile
/dist - for distribution packages, hopefully auto generated by a build system
In /src I'm using the default Java patterns: Package names starting with your domain (org.yourdomain.yourprojectname) and class names reflecting the OOP aspect you're creating with the class (see the other commenters). Common package names like util, model, view, events are useful, too.
I tend to put constants for a specific topic in an own class, like SessionConstants or ServiceConstants in the same package of the domain classes.

Where I'm working, we're using Maven 2 and we have a pretty nice archetype for our projects. The goal was to obtain a good separation of concerns, thus we defined a project structure using multiple modules (one for each application 'layer'):
- common: common code used by the other layers (e.g., i18n)
- entities: the domain entities
- repositories: this module contains the daos interfaces and implementations
- services-intf: interfaces for the services (e.g, UserService, ...)
- services-impl: implementations of the services (e.g, UserServiceImpl)
- web: everything regarding the web content (e.g., css, jsps, jsf pages, ...)
- ws: web services
Each module has its own dependencies (e.g., repositories could have jpa) and some are project wide (thus they belong in the common module). Dependencies between the different project modules clearly separate things (e.g., the web layer depends on the service layer but doesn't know about the repository layer).
Each module has its own base package, for example if the application package is "com.foo.bar", then we have:
com.foo.bar.common
com.foo.bar.entities
com.foo.bar.repositories
com.foo.bar.services
com.foo.bar.services.impl
...
Each module respects the standard maven project structure:
src\
..main\java
...\resources
..test\java
...\resources
Unit tests for a given layer easily find their place under \src\test... Everything that is domain specific has it's place in the entities module. Now something like a FileStorageStrategy should go into the repositories module, since we don't need to know exactly what the implementation is. In the services layer, we only know the repository interface, we do not care what the specific implementation is (separation of concerns).
There are multiple advantages to this approach:
clear separation of concerns
each module is packageable as a jar (or a war in the case of the web module) and thus allows for easier code reuse (e.g., we could install the module in the maven repository and reuse it in another project)
maximum independence of each part of the project
I know this doesn't answer all your questions, but I think this could put you on the right path and could prove useful to others.

Class names should always be descriptive and self-explanatory. If you have multiple domains of responsibility for your classes then they should probably be refactored.
Likewise for you packages. They should be grouped by domain of responsibility. Every domain has it's own exceptions.
Generally don't sweat it until you get to a point where it is becoming overwhelming and bloated. Then sit down and don't code, just refactor the classes out, compiling regularly to make sure everything works. Then continue as you did before.

Use packages to group related functionality together.
Usually the top of your package tree is your domain name reversed (com.domain.subdomain) to guarantee uniqueness, and then usually there will be a package for your application. Then subdivide that by related area, so your FileStorageStrategy might go in, say, com.domain.subdomain.myapp.storage, and then there might be specific implementations/subclasses/whatever in com.domain.subdomain.myapp.storage.file and com.domain.subdomain.myapp.storage.database. These names can get pretty long, but import keeps them all at the top of files and IDEs can help to manage that as well.
Exceptions usually go in the same package as the classes that throw them, so if you had, say, FileStorageException it would go in the same package as FileStorageStrategy. Likewise an interface defining constants would be in the same package.
There's not really any standard as such, just use common sense, and if it all gets too messy, refactor!

One thing that I found very helpful for unit tests was to have a myApp/src/ and also myApp/test_src/ directories. This way, I can place unit tests in the same packages as the classes they test, and yet I can easily exclude the test cases when I prepare my production installation.

Short answer: draw your system architecture in terms of modules, drawn side-by-side, with each module sliced vertically into layers (e.g. view, model, persistence). Then use a structure like com.mycompany.myapp.somemodule.somelayer, e.g. com.mycompany.myapp.client.view or com.mycompany.myapp.server.model.
Using the top level of packages for application modules, in the old-fashioned computer-science sense of modular programming, ought to be obvious. However, on most of the projects I have worked on we end up forgetting to do that, and end up with a mess of packages without that top-level structure. This anti-pattern usually shows itself as a package for something like 'listeners' or 'actions' that groups otherwise unrelated classes simply because they happen to implement the same interface.
Within a module, or in a small application, use packages for the application layers. Likely packages include things like the following, depending on the architecture:
com.mycompany.myapp.view
com.mycompany.myapp.model
com.mycompany.myapp.services
com.mycompany.myapp.rules
com.mycompany.myapp.persistence (or 'dao' for data access layer)
com.mycompany.myapp.util (beware of this being used as if it were 'misc')
Within each of these layers, it is natural to group classes by type if there are a lot. A common anti-pattern here is to unnecessarily introduce too many packages and levels of sub-package so that there are only a few classes in each package.

I think keep it simple and don't over think it. Don't over abstract and layer too much. Just keep it neat, and as it grows, refactoring it is trivial. One of the best features of IDEs is refactoring, so why not make use of it and save you brain power for solving problems that are related to your app, rather then meta issues like code organisation.

One thing I've done in the past - if I'm extending a class I'll try and follow their conventions. For example, when working with the Spring Framework, I'll have my MVC Controller classes in a package called com.mydomain.myapp.web.servlet.mvc
If I'm not extending something I just go with what is simplest. com.mydomain.domain for Domain Objects (although if you have a ton of domain objects this package could get a bit unwieldy).
For domain specific constants, I actually put them as public constants in the most related class. For example, if I have a "Member" class and have a maximum member name length constant, I put it in the Member class. Some shops make a separate Constants class but I don't see the value in lumping unrelated numbers and strings into a single class. I've seen some other shops try to solve this problem by creating SEPARATE Constants classes, but that just seems like a waste of time and the result is too confusing. Using this setup, a large project with multiple developers will be duplicating constants all over the place.

I like break my classes down into packages that are related to each other.
For example:
Model For database related calls
View Classes that deal with what you see
Control Core functionality classes
Util Any misc. classes that are used (typically static functions)
etc.

Categories