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:
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
se( timeDifferential < 0 ) {
}se não {
}
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).
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.
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.
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.
Este princípio diz que uma classe não deve implementar interfaces ou métodos que não serão utilizados.
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.
