pabloflps / provatecnica-processo-seletivo2021.1

Projeto "forked" do GitHub da Commit Jr. para realização do processo seletivo 2021.1, possibilitar e concluir a "viagem no tempo".

Introdução

No último processo seletivo, os nobres guerreiros da Commit Jr sofreram um revés ao ajudarem Emiyepfsi e Qoissi e perderam-se no espaço-tempo e estão presos na pré-história. Porém, estão cercados de criaturas muito estranhas e hostis, que querem devorá-los. Por sorte, um dos membros havia baixado um repositório do GitHub que se tratava de uma tentativa de construção de uma máquina do tempo.

Todavia, o código está longe de ficar pronto e está com um problema no cálculo do endereço cósmico da Terra. Sua tarefa é completar o código utilizando os princípios do SOLID para evitar uma catástrofe maior. Para isso considere as fórmulas abaixo para o cálculo do endereço cósmico da Terra:

Dica

Todos os metodos que devem ser alterados tem o comentario com palavra CALC.

• Dentro da pasta helpers tem 4 arquivos, todos tem 1 função que deve ser alterada
• Dentro da paste service tem a pasta implementations, dentro dela tem uma classe com 3 métodos para serem preenchidos

TimeBalance:

Formulas importantes para implementação:

SolarSystemPosition:

se( timeDifferential < 0 ) {

}se não {

}

GalaxyPosition:

UniversePosition:

O que é o SOLID?

O SOLID é um acrônimo para 5 princípios utilizados na programação orientada a objetos apresentado inicialmente pelo Robert “Uncle Bob” Martin em um artigo publicado no ano 2000. Dito isso, segue abaixo a lista dos princípios:

• Single-responsibility principle (Princípio de única responsabilidade);
• Open–closed principle (Princípio de aberto/fechado);
• Liskov substitution principle (Princípio da substituição de Liskov);
• Interface segregation principle (Princípio da segregação de Interface);
• Dependency inversion principle (Princípio da inversão de dependência).

Single-responsibility principle (Princípio de única responsabilidade)

Basicamente, esse princípio diz que uma classe, componente, entidade ou funções devem ter uma única responsabilidade no código. A violação deste princípio aumenta a possibilidade de bugs por que mudar uma das responsabilidades pode afetar o todo.

Open–closed principle (Princípio de aberto/fechado)

Este princípio é um pouquinho mais polêmico que o anterior pois se mal interpretado pode parecer contradizê-lo. O princípio aberto/fechado diz que, uma classe, entidade, componente ou função deve estar aberta para extensões, porém fechadas para modificações.

Liskov substitution principle (Princípio da substituição de Liskov)

Trata-se de um princípio introduzido por Barbara Liskov que diz que: se tivermos uma classe e se dela criarmos uma subclasse por herança, o objeto desta subclasse deve ser capaz de substituir a classe pai.

Este princípio sugere, basicamente, que não se deve fazer subclasses que gerem uma exceção na medida em que, um método definido na parte superior da árvore de herança deve ser funcional numa classe mais abaixo.

Interface segregation principle (Princípio da segregação de Interface)

Este princípio diz que uma classe não deve implementar interfaces ou métodos que não serão utilizados.

Dependency inversion principle (Princípio da inversão de dependência)

Este princípio diz que uma classe não deve ser presa com a “ferramenta” que ela usa. Ao invés disso, ela deve usar uma interface que permita conectar a ferramenta à classe.

Referências:

• Medium
• Filipe Deschamps
• Código Fonte TV