Aluno #167

[Edworldinho]

Membros não encapsulados:
As variáveis das classes Cliente e Encomenda estão declaradas como públicas nos seus arquivos .hpp quando poderiam ser privadas ou protegidas. Logo, eu alterei a acessibilidade public para a apropriada.
Padronização de linguagem:
Não é adequado misturar linguagens em um código (ex: Inglês e português). Sendo assim, eu padronizei as variáveis e métodos para nomes em português.
Variáveis sem uso:
A variável T não tem função alguma no código e ainda produz um erro de saída ao ser colocada no lugar da variável x. Apesar de ter sido dito que não podemos alterar a saída, esse caso é uma exceção, como falado na discussão disponível em: https://virtual.ufmg.br/20202/mod/forum/discuss.php?d=47385. Sendo assim, eu a removi do código. As variáveis remetente e dest da classe Encomenda se tornaram inúteis (ver tópico: “Método removido de uma classe e adaptado parcialmente para outra”), logo as exclui também.
Nomes de variáveis:
A variável x tem um nome muito genérico. Por isso eu substitui por custoTotalEntrega, que representa melhor o que ela é. A variável CUSTOkg não segue nenhuma formatação aparente e tem nome estranho. Logo, adotei a formatação de variável com letras minúsculas caso seja uma só palavra, e com as palavras consecutivas juntas e começando com maiúsculas. O novo nome de CUSTOkg é custoPorQuilograma.
Nomes de variáveis escritos como se fossem de constantes:
As variáveis NOME, CIDADE, ESTADO e PESO estão escritas com sintaxe de constantes. Mudei para a sintaxe de variável, ou seja, tudo minúsculo.
Fusão de escopos(using namespace):
Como discutido em aula o using namespace x funde o escopo corrente com o escopo do namespace x em questão. Isso pode gerar conflitos de nomes de variáveis ou de funções. Logo removi todos os using namespace e passei a declarar explicitamente o namespace em questão ao usá-lo.
Nomes de métodos que estavam muito genéricos:
Nomes como print e calcula são nomes muito genéricos. Sendo assim os substitui por métodos na forma imprimeX e calculaX, respectivamente. O X nesse caso é uma palavra ou expressão que deixa explícito o que o método imprime ou calcula.
Falta de construtores:
Adicionei um construtor default e um construtor que define objetos de classe nas classes EncomendaNormal, EncomendaRelampago e Cliente.
Métodos sem parâmetro:
Todos os métodos estavam sem parâmetro, muito em função da inexistência de construtores nas classes Encomenda e Clientes. Após criar os construtores, pude passar os parâmetros mais corretos para cada método.
Métodos default (vazio) na superclasse:
Os antigos métodos calcula e print podem ser definidos como métodos vazios na superclasse Encomenda e sobrescritos nas classes derivadas (EncomendaNormal e EncomendaRelampago).
Método removido de uma classe e adaptado parcialmente para outra:
O antigo método print de Encomenda não faz sentido. Ele só adiciona uma linha (a linha [Remetente]/[Destinatário]) e chama de novo o antigo print de Cliente. Ora, é mais pertinente em termos de organização e modularidade excluir isso, criar dois métodos (o Remetente e o Destinatário) que imprimem essas frases e colocá-los na classe Cliente. Ai bastará chamá-los no main quando necessário e chamar o método de impressão de dados do cliente da classe Cliente em seguida.
Mudanças no arquivo main
Alterei os nomes do formato cliN° para o formato cliente_N°, e os nomes encN° para encomenda_N°. Com as mudanças feitas pude definir essas variáveis em uma linha cada e sem acessar variáveis private diretamente, de acordo com os princípios do encapsulamento. A forma de chamar as funções também mudou e eu coloquei comentários dividindo o main em partes.
*Eu não sei se isso aparece, mas tive que adicionar alguns arquivos manualmente, pois me pareceu que os perdi nas refatorações 2 e 3. Não sei se foi realmente o caso, mas fiquei preocupado e pensei que é melhor prevenir que remediar.