Standard Java design for code reuse

Question

I am developing a simple program in Java Desktop using SqLite to store local data, I would like to know which design pattern I can use to reuse the codes Java to develop the same application for Android, in my project I am using the standard MVC.

This is the most appropriate for this situation?

I have an intermediary knowledge in Java for Android, Activitys Cycle, Views, Basedapter, Handlers, Asynctask, sqlite persistence and etc.

Answer 1

There is no pattern absolutely better than the others.

The MVC concept helps, but it’s only a start. Reuse of the code will depend on the coupling level of your code. It is possible to write MVC code so interdependent that it is not possible to reuse a single class, as well as not using any high-level standard and write highly reusable classes.

Reasoning in terms of cohesion and coupling. In short, cohesion is the level of clarity of the function of a class and coupling is the level of dependence of a class on the other.

You should encode aiming for high cohesion, that is, classes with well-defined responsibilities. It should also seek low coupling, that is, avoid that one class depends directly on many others.

There are several techniques and principles to achieve these goals. For example:

• Each method should perform only one significant action. If there are complex operations, they should be distributed to other methods. The "algorithm" of each method must be clear and perceptible.
• A class should only contain methods that make sense to it. Moreover, a class should have a single responsibility. It is common to implement classes that mix concepts, for example, a class that makes calculations with dates and is also responsible for formatting them. So when it is necessary to reuse the calculation part, you end up having to take the formatting together, which may not be desired. This is the principle of single responsibility.
• When creating reuse Apis, make your classes depend only on interfaces instead of concrete implementations, as this way it will be possible to replace one of the implementations whenever necessary.
• Use Inversion of Control and Dependency injection to avoid depending on other classes directly. If you have a class A using a class method B, don’t make a new B() directly within the class A. Make sure A receive an instance of B, for example, in the constructor. And also make it B is an interface. That way, when creating A, you can pass the proper implementation of B.

SOLID is a set of concepts of design of classes that can help even more. It starts with the One Responsibility Principle and includes four more important concepts. I won’t detail them all here, but it’s worth studying each.

Anyway, there are several techniques and principles to create reusable classes. Some are a little complicated to understand.

The truth is that no one has a definitive answer to this. Experience helps, but one must take into account that writing code for reuse is always harder.

Brooks writes in the book The Mythical Man-Month that the order of difficulty to make a "homemade" program (that runs only on a machine and does something specific) become something reusable is nine times. In practice, this means that you will have nearly ten times the work to create a library compared to creating specific routines for a project.

The question of whether the code should be implemented in a reusable way is whether it is important enough to do so.