What is the point of dividing a project into two separate projects?

Question

Many times I see how people divide a project into two separate projects, as in this screenshot:

What is the point of separating Ingot and IngotAPI instead of putting them in the same project, because they compile anyway?

Answer 1

Several occasions.

The need or desire to have an API separate from (one of) its implementation. With Java SPI (Service Provider Interface), you provide only the interface for which the client application is. The java SPI then provides a search for using one of the possible implementations. Used for XML parser. Similarly for JDBC. Decoupling the API means that the client does not need to be recompiled if the API remains unchanged, but the implementation has been changed.

In general, the presence of several projects allows us to consider each project module , a unit that imports the specified list of other modules and forms a multi-level hierarchy. This can give the software system much higher quality without importing and vice versa. The next generation of Java will receive modules.

Answer 2

One reason for this is that the implementation can be interchangeable.

Imagine a situation where you have two clients that use your application. Both of them have different requirements on how to do this (for example, the algorithm is different), but the type of result is the same. In this case, the client code should work directly only with the API and is not dependent on any implementation. During build, you can specify which implementation should be used.

With this solution:

• When a new client arrives, you can easily create an implementation for the new requirement without changing the API or client code. This makes your old code more reusable.
• you don’t need to rebuild the API or the client if the changes were made only to the implementation. This saves developers time while working.
• during tests, you can provide mock implementation for some parts of the business logic

Answer 3

First To make the code more reusable. By packing into different project functionality, it’s easier to find the functionality that you want to transfer to another project (in this case, you could export the entire IngotAPI to a new project). The second is for testing. It is much easier to save the test result when each project has its own unit test, rather than a test that checks the integration between the two projects.

For example, if IngotAPI is well developed, it should not have any dependencies on the Ingot project. This means that if you make any changes to the Ingot project, you do not need to test IngotAPI yourself, since it will not be affected (high cohesion), you just need to check the ingots, but in the place where the ingot uses IngotAPI.

Answer 4

IngotAPI seems to be something that should be easily connected to other projects. Perhaps it will be used in a future elsewhere.

In the end, it doesn't really matter, since you can simply copy your classes from other projects to a recent one.

Answer 5

The main reason is that when you implement the API you want to distribute it to potential customers. By separating two (or more) projects, you can only distribute interfaces and business objects and save the implementation yourself.

This way you do not need to redistribute any changes in the implementation.