domingo, 15 de junho de 2008

Variações Protegidas

Blog referente a aula do dia 09/06/2008
Variação Protegida
Solução das variações
Problema
Como que se consegue projetos de maneira que , o que você tenha implementado nesses elementos não prejudiquem a '"boa" execução dos outros?
Uma boa solução seria identificar os pontos de variação, atribuir responsabilidades a estes pontos criando uma interface que atue estavelmente entre eles.
  1. O princípio básico da VP é manter a flexibilidade e proteção nas aplicações dos sistemas. Ela atua contra essas variações.

    Posso dizer como desenvolvedor “verde” ainda que para se obter uma boa VP no começo segue-se alguns princípios como encapsular dados, interfaces e um bom uso do polimorfismo, só que com o tempo e amadurecimento , se aprendem novos mecanismos para proteção contra variações:

    Segue abaixo alguns mecanismos de VP

    Projetos dirigidos por dados (data-driven designs)

    Este projetos englobam técnicas de inserção em código , leitura de valores , inspeção de caminhos de classe , eles são usados para mudar o comportamento do sistema ou talvez impondo padrões em tempo de execução. Ex – XML e WEB-XML.

    Pesquisa de Serviço: Ex:(SOA) – Analise Orientada a Serviços

    Inclui técnicas como o uso de serviços de atribuição de nomes, um bom exemplo disso é o SOA (Analise Orientada a Serviços).

    Proporciona ao cliente uma proteção contras as variações que possam ocorrer na localização dos serviços.

    Projetos dirigidos por interpretador:

    Um bom exemplo é a JVM, são projetos baseados em regras de uma fonte externa, ou seja é uma máquina virtual onde coloca-se regras dentro dela e ela toma decisões em cima daquelas regras.

    Projetos reflexivos:

    Ao meu entender funciona da seguinte maneira, funciona como uma substituição de métodos, ou seja , o fato de se apagar um método de uma aplicação não trava o sistema, pois ele é substituído por um método existente.

    Acesso Uniforme:

    Existente somente em algumas linguagens.

    Como posso explicar isso !!!, bom ao meu entender ele valida as denominações dos tipos no código de qualquer maneira , ou seja , vejamos o exemplo abaixo para uma melhor explicação.

    Ex: avião.decolar;

    “Decolar” no caso acima é aceito de duas formas , tanto como método quanto atributo e é aí que entra o entendimento do acesso uniforme, ele aceita as duas formas.

    O C# é um bom exemplo de acesso uniforme , pois ele aceita essa forma de definição.

    Princípio da substituição de LISKOV

    Introduzido por Bárbara Liskov é resumida da seguinte forma:

    Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.

    Essa visão de subtipo é baseada na noção de substituição, ou seja , se B é um subtipo de A, então os objetos do tipo A, em um programa, podem ser substituídos pelos objetos de tipo B sem que seja necessário alterar as propriedades deste programa.
Uma ótima semana a todos e boa sorte na prova de segunda !!!!!
Bibliografia
Livro: UTILIZANDO UML E PADRÕES - Craig Larman

Nenhum comentário: