によって Rodrigo Pysklyvicz 5年前.
374
もっと見る
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
