CODEWITHSUNDEEP
javaarchitecturepackage
user2689782
user2689782

Reputation: 757

Package-by-layer VS package-by-feature library naming?

I know this has several associated posts, but I have some specific questions which I am hoping I can get help with. Sorry if they are very basic..

Here is a sample problem - very simplified, but you get the picture - I have several objects, which have some common function e.g. departments in a pharmaceutical company - neurology, oncology, infection etc. They all need to parse patient document files, and upload data to the database. Of course the nature of the data is slightly different for each department. If I used package-by-feature, I would have

com.company.neurology
      Neurology.java
      NeurologyDocument.java
      NeurologyDAO.java

com.company.infection
      Infection.java
      InfectionDocument.java
      InfectionDAO.java

etc. The problem is that I need an abstract class that the Document classes need to extend e.g.

AbstractDocument.java
public class AbstractDocument
{
      public void validateDocument(){...}
      public void readDocumentHeader(){...}
      public void readDocumentFooter(){...}
       ...
}

Some data access files e.g.

DBConnection.java
    public class DBConnection
    {
        public void makeConnectionToDB() {... }
        public void createCache() {... }
        public void closeConnectionToDB() {... }
    }

some error classes

ParseError.java, PatientNotFoundException etc.

If packages are by feature, where do these common classes/interfaces go?

Upvotes: 6

Views: 1789

Answers (2)

Vladislav Rastrusny
Vladislav Rastrusny

Reputation: 29985

I do not think in your case you should create some common package. I guess something is wrong with the abstractions used.

You must find a way to unite classes with the same purpose into some package and place this package under com.company.shared.<feature_name>.

In your case it could be:

  • com.company.shared.database
  • com.company.shared.data_parsing

It is no problem for a package to contain only one or two classes. But it should unite only classes with the same purpose and have a clear speaking name.

Avoid such names for both packages and classes as common. A name should talk for itself.

Upvotes: 1

Morgen
Morgen

Reputation: 1038

I would recommend keeping things simple. Provided you don't get lazy about it, putting them into com.company is a reasonable solution.

The caveat here is that this requires the discipline to move these out into separate packages whenever you notice groups of organizational commonality.

In the case of your example, you've already started to make these connections - your post itself is segmented to suggest these additional packages:

com.company.dataaccess
com.company.error

AbstractDocument.java probably doesn't merit it's own package - yet. If you end up creating more related interfaces / classes, then move them into an appropriate package, but don't borrow trouble by worrying about it until it actually becomes an issue.

Upvotes: 0

Related Questions