Design standard

Asked

Viewed 98 times

-1

An analyst told me that I need to create classes that calculate contract installments, but I realized that this calculation always has the same steps, but depending on the type of contract, some steps are done in different ways. The steps I could identify are: CalcValorPrincipal, CalcTaxaAdministrativa and Calcvalorseguro, after the execution of the same algorithm sums everything and returns the total value of the contract. I would like to know what is the recommended design standard to solve this problem and why is it the most recommended? I’ve been doing some research and it seemed to me template, but I would like some help from those who "know" more of this area.

I would like a UML diagram of this problem using the recommended pattern so it can be a little clearer for me.

uml
  • 3

    From what you described, it doesn’t look like a template. And none of these patterns are known. But I could be wrong because the question doesn’t have enough information. But think about this: solve the problem, improve it, then you decide if a pattern can fit into it. Patterns are great when applied at appropriate times by those who have complete mastery of them. Design patterns even look like, but they’re not cake recipes. Design Pattern is a powerful tool that requires great responsibility in its use. Cake recipe is copying what someone has done without understanding what is happening.

  • 3

    Hello, Jeferson. Welcome to [pt.so]! Your question is very interesting, but without details of how the implementation is difficult to help. From my experience in the financial field, where I have worked a lot with Principal and Present Value calculation, I say that there is no design pattern (in the classical sense) suitable for financial calculations, but you can apply some general good practices. One is to avoid including domain objects in the middle of calculations. Create routines in a generic way with explicit and well defined parameters. If you have the routines and can post, I can help more.

1 answer

2

I don’t know much about UML, but I would use the Strategy standard which, as the name says, seeks a unique strategy for each type of situation, in the case of Contracts. Interfaces are generated that keeps everything "tied".

An interface that basically only forces those who implement it to calculate something.

public interface Calculavel {
    public Double calcula();
}

Examples of implementation:

public class CalculoSeguroTipoX implements Calculavel{
    @Override
    public Double calcula() {
        //Aqui está a forma de calculo...
        return null;
    }
}
public class CalculoTaxaAdministrativaTipoB implements Calculavel{
    @Override
    public Double calcula() {
        //Aqui está a forma de calculo...
        return null;
    }
}
public class CalculoValorPrincipalTipoY implements Calculavel {
    @Override
    public Double calcula() {
        //Aqui está a forma de calculo...
        return null;
    }
}

We also have the Contract interface that requires every contract to have several types of implementations that are calculatable.

public interface Contrato {
    public Calculavel getCalcTaxaAdministrativa();
    public Calculavel getCalcValorPrincipal();
    public Calculavel getCalcValorSeguro();
}

And finally an implementation of a contract:

public class ContratoPessoaFisica implements Contrato{

    @Override
    public Calculavel getCalcTaxaAdministrativa() {
        return new CalculoTaxaAdministrativaTipoB();
    }

    @Override
    public Calculavel getCalcValorPrincipal() {
        return new CalculoValorPrincipalTipoY();
    }

    @Override
    public Calculavel getCalcValorSeguro() {
        return new CalculoSeguroTipoX();
    }
}

I hope I helped.

Browser other questions tagged uml

You are not signed in. Login or sign up in order to post.