You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Utilizando estudos de design patterns e padrões de orientação à objetos, procura-se melhorar a manutenibilidade de código, com as seguintes ações:
Atualizar o diagrama de classes #116 Atualizar o diagrama de classes para verificar a viabilidade das mudanças, tentando limitar a hierarquização para até 5 níveis
Utilizar padrões builders para melhor gerenciar a criação de objetos com muitos argumentos (programs, tests)
Criar uma classe trystroop, tryexperiment, etc para melhor abstrair estes conceitos dentro de testes e diminuir a quantidade de argumentos de cada tentativa
(DOING) Utilizar fabricação pura (trazendo pra ela os dados da classe global) e um singleton para manipulação de arquivos e seus devidos caminhos! APENAS AS CLASSES MODELS PODERÃO ACESSAR ESSA NOVA "CAMADA", e ela também se comportará como uma fachada, concentrando métodos do system.io e outras manipulações de arquivos
Existem as classes StroopTest, ExperimentTest, ReactionTest, MatchingTest, elas não tem nenhum relacionamento entre si, embora sejam muito parecidas, dava pra criar uma classe abstrata e forçar a implementação de métodos
The text was updated successfully, but these errors were encountered:
fabiolamfleury
changed the title
Criar abstração pras classes de "Tests" de forma hierarquica
Refatoração das models para melhorar manutenibilidade de código
May 24, 2018
Observação* : propriedades auto implementadas são utilizadas em novas versões do C#, não disponível para visual studio 2015, apenas pro 2017, questionamento em relação às técnicas de programação.
Utilizando estudos de design patterns e padrões de orientação à objetos, procura-se melhorar a manutenibilidade de código, com as seguintes ações:
Atualizar o diagrama de classes #116 Atualizar o diagrama de classes para verificar a viabilidade das mudanças, tentando limitar a hierarquização para até 5 níveis
Utilizar padrões builders para melhor gerenciar a criação de objetos com muitos argumentos (programs, tests)
Criar uma classe trystroop, tryexperiment, etc para melhor abstrair estes conceitos dentro de testes e diminuir a quantidade de argumentos de cada tentativa
(DOING) Utilizar fabricação pura (trazendo pra ela os dados da classe global) e um singleton para manipulação de arquivos e seus devidos caminhos! APENAS AS CLASSES MODELS PODERÃO ACESSAR ESSA NOVA "CAMADA", e ela também se comportará como uma fachada, concentrando métodos do system.io e outras manipulações de arquivos
Existem as classes StroopTest, ExperimentTest, ReactionTest, MatchingTest, elas não tem nenhum relacionamento entre si, embora sejam muito parecidas, dava pra criar uma classe abstrata e forçar a implementação de métodos
The text was updated successfully, but these errors were encountered: