jonka Rodrigo Pysklyvicz 5 vuotta sitten
404
Lisää tämän kaltaisia
luonut Fátima Regina
luonut pedro marchetti
luonut ana clara
luonut ALINE CECILIA ZIMMERMANN
Estamos vivendo uma fase intermediária onde não havia preocupação em aplicar os padrões - com o tempo e treinamento a tendência é que todos passemos a aplicar
Porém devemos lembrar que sempre iniciamos código novo, e nesse caso podemos aplicar os conceitos que aprendemos
Para código existente isso realmente é um fato - se a empresa autorizar podemos iniciar refatorações
Ao reduzirmos o acoplamento conseguimos aumentar consideravelmente o reaproveitamento de código
Ao separarmos melhor as coisas por conceitos como model e visual facilitamos a manutenção
Ao separar as rotinas que se atualizam frequentemente das outras que se lidam muito pouco - diminuímos o risco de futuras alterações implicarem negativamente no sistema
Num primeiro momento é realmente mais fácil, porém trabalhando com as boas práticas ganhamos esses 3 super benefícios:
Essa questão depende diretamente da cultura atual da empresa
Prever tempo destinado a reuniões, aulas, etc
Agendar refatorações futuras
Teste - retorno - o ponto de execução pode depender de condições específicas
Refatorações ou desenvolvimento de recursos - tipo: simples, médio, complexo
Compreender e planejar micro situações em correspondência com as macros
Definir escopo: criação de recursos, novas rotinas ou refatorações
Veja "Para Novas Soluções"
Equipe de desenvolvimento
Todas as equipes
Clientes
Outras empresas
Especialistas
Comunidades
Usar o bom senso na hora de aplicar esse conceito, pois trabalhar 100% orientado a interfaces demanda muita energia e tempo
Quando é evitada... A herança de implementação; A instanciação direta de um objeto dentro de uma outra classe; A injeção de dependência por meio de classes e não de interfaces
2) Ter classes feitas exclusivamente para manipular as interfaces
1) Criar o contrato (interface) Exemplo: TGeraArquivo = interface procecure Execute()
Depender de interfaces torna possível usar qualquer implementação, aumentando assim o reaproveitamento de código e tornando mais simples o entendimento da ligação entre as classes
Caso a classe não possua propriedades auxiliares como _Descricao ou _Quantidade
Ao invés de criar por exemplo o campo IdProduto e DescricaoProduto na classe TItemVenda, usar o objeto Produto direto
Usar o objeto inteiro é melhor porque ele já possui todas as informações do domínio em questão - evitando assim também o copy/cola de algumas de suas propriedades para outro objeto
Quando a Classse pai possui zero implementação
É praticamente impossível na maioria dos casos escrever algo na filha sem saber o que está na pai
Por conta do forte acoplamento com a implementação que está na classe pai
Quando não há herança de implementação (somente de estrutura)
O cliente não pode ter nenhum tipo de trabalho com a estrutura
A estrutura não pode ter nenhum tipo de implementação
3) E por último classes que implementam a estrutura citada - esse trabalho é feito por quem chamamos de cliente
2) Ter classes feitas exclusivamente para manipular essas estruturas
1) Usando interfaces ou classes abstratas sem nenhuma implementação - prefira o primeiro. Exemplo: TGeraArquivo = interface procecure Execute()
Separar a programação estrutural da programação da implementação
Evite herança, prefira composição
Programe voltado a interface e não à implementação
O método ter no máximo 20 linhas
A classe ter no máximo 12 métodos - mais do que isso procurar quebrar em classes menores
Caso a classe não misture códigos de diferentes domínios como Model, View, DAO, etc
Caso a classe não possua mais de um motivo para existir
Dividir um problema em domínios menores e criar uma classe para cada um desses domínios
Passar a criar classes e métodos especialistas no que fazem - classes assim são mais fáceis de compreender e dar manutenção
Quando os únicos Typecasts encontrados são de tipos primários ou de solução de terceiros como VCL, RTTI e outros.
Usar o Padrão Façade quando há a necessidade de um retorno comum para objetos diferentes entre si.
Evitar o uso de por exemplo: var LPai: TPai; LPai := TFilho.Create(); TFilho(LPai).AlgumMetodo; ...e trabalhar diretamente com o tipo TFilho desde o começo.
Quando a solução é de terceiro como VCL ou RTTI o Typecast se faz necessário, uma vez que somos obrigados a seguir as regras deles
O Typecast usado em soluções criadas por nós prejudica a legibilidade natural do código assim como ocorre com ifs, pois de uma hora para outra o objeto que era uma coisa se transforma em outra
Caso a classe não use tipos enumerados ou records nem dentro nem fora dela
Exemplo: Ao invés de TTipoPrescricao = (prExame, prMedicamento, prInternacao)... Vem as classes TTipoPrescricaoExame, TTipoPrescricaoMedicamento, TTipoPrescricaoInternacao
Cada tipo enumerado se transforma em uma classe correspondente.
Os tipos básicos também nos obrigam a criar condições (ifs) que acabam comprometendo a legibilidade do código.
Uma boa centralização ocorre somente com o uso de classes
Os tipos mais básicos fazem com que a codificação da regra fique de certa forma espalhada
