Como ir de mal a bom design OOP?

https://stackoverflow.com/questions/440554

22-07-2019
|

Pergunta

Estou lendo muito sobre boas e más práticas em design de OOP. É bom saber que seu projeto é ruim, ou bom. Mas como fazê-lo de mal a bom design? Eu dividir a interface (XAML) e CodeBehind da principal classe BusinessLogic. Essa última classe está crescendo grande. Eu tentei dividindo-se em classes menores, mas eu estou preso agora. Todas as ideias sobre como dividir grandes aulas? A classe principal tem uma lista de dados de diferentes tipos. Estou fazendo cálculos sobre o total, mas também sobre os tipos individuais. Eu tenho métodos para realizar estes cálculos que são chamados de eventos tratados no codebehind. Alguma idéia para onde ir a partir daqui?

Informações adicionais:

Já são cerca de 6 meses para este projeto. Eu já trabalhei com laguages ??orientadas a objeto durante anos (primeira c ++, java e agora c #), mas nunca em um projeto grande como este. Eu acredito que fizemos algumas voltas erradas no início e eu acho que nós precisamos corrigir isso. Eu não posso especificar quaisquer detalhes sobre este projeto no momento. Eu estou indo para encomendar um ou dois livros sobre design. Se eu separar todas as classes, como faço para colocá-los juntos novamente? Talvez seja ainda melhor para continuar este caminho para o primeiro lançamento e reconstruiu partes depois disso, para uma segunda versão?

Solução

A classe principal tem uma lista de dados de tipos diferentes. estou fazendo cálculos no total, mas também sobre os tipos individuais. Eu tenho métodos para realizar esses cálculos que são chamados de eventos tratados no Código por trás. Alguma idéia onde ir a partir aqui?

Se houver um monte de cálculos com base no conteúdo da lista você já pensou em operações de mover-se em uma classe lista personalizada? O mesmo vale para as operações sobre os tipos específicos, talvez eles poderiam viver dentro dos tipos?

Em termos de realização de operações semelhantes ainda diferentes em diferentes tipos de considerar o uso do estado padrão ( ver isso como um substituto para declarações switch) que permite tratar as entidades de uma maneira uniforme.

Um monte de OOP é sobre jogando fora um "down top" abordagem / microgestão e considerando um "up bottom" abordagem / auto-suficiente. Vale a pena lembrar que nem abordagem é "correta" de forma isolada. Criando código sustentável é sobre encontrar um equilíbrio sensível que requer um monte de pensamento e geralmente se desenvolve através da experiência.

Outras dicas

Prática e leitura. Repita :)

Alguns livros recomendados:

Clean Code por Robert C Martin
GoF Design Patterns
Refactoring por Martin Fowler

Pessoalmente, eu também gostava de Head First Design Patterns, mas o estilo pode não ser para todos. Há um livro similar chamado C # 3.0 Design Patterns (veja ora.com). Ele tem muito do mesmo material, mas de uma forma mais tradicional.

Eu recomendo pegar Code Complete . É um grande livro que oferece toneladas de bons conselhos sobre questões como a sua.

Para lhe dar uma resposta rápida à sua pergunta sobre como dividir classes grandes, aqui está uma boa regra de ouro: fazer a sua classe responsável por uma coisa, e apenas uma coisa. Quando você começar a pensar assim, você pode rapidamente identificar código que não pertence. Se algo não pertence, fator-lo em uma nova classe, e usá-lo a partir de sua classe original.

Edit: Tome esse pensamento até o nível de "método", também - fazer seus métodos responsável por uma coisa, e apenas uma coisa. Ajuda a quebrar (> 50 linha) métodos grandes para baixo muito rapidamente em pedaços reutilizáveis ??de código.

mudar a maneira de pensar sobre objetos. Cada objeto deve ter um responsabilidade muito específica. Se você tem uma classe chamada algo genérico, como "MainBusinessLogic" provavelmente você está fazendo algo errado.

Ótimo lugar para começar:. Leia David West Objeto Pensamento

Este é apenas um adendo a algumas sugestões belo livro aqui.

A melhor tenho em OO, mais eu parecem reduzir o tamanho do objeto. Não é como se eu estivesse indo para o tamanho do objeto pequeno ou qualquer coisa, mas parece estar a acontecer.

Mantê-los pequenos, a responsabilidade única e simples de usar e entender - todos críticos. Cada objeto deve ser o mais próximo possível à prova de balas possível, verificar os seus parâmetros e nunca permitir que o objeto em um estado inválido. Definir todos os estados válidos claramente na documentação.

Toda vez que você criar uma classe, criar um teste para essa classe. Ele não só testa seu código, mas obriga a consumir o seu próprio design. Sempre pense em sua classe de que "view Outside". Certifique-se que você não está pedindo muito da pessoa usar a sua classe e qualquer coisa que você está pedindo a ele deve ser documentado na interface. Muitas vezes eu jogo apenas uma rápida principal em uma classe, se não houver framework de testes disponível -. Ele coloca um exemplo de como usar o código ali no mesmo arquivo

Na codificação, quase todo o meu tempo é gasto tentando descobrir o que alguém fez. Se eu fosse capaz de simplesmente colocar para fora o código usando APIs documentadas conhecidos ou bem, meu trabalho seria trivial e horários significativamente menor.

Design-primeiro pode ser difícil. Considerar a capacidade de codificação como semelhante a capacidade de esportes. A maioria de nós jogar em nossas calçadas, alguns jogo de equipes esportivas locais. Para fazer o bem up-front design em um projeto complicado é a tarefa de um jogador da liga nacional, eles são um em um milhão. Aceite isso e planejar para a mudança - iterações são seu amigo. (By the way, a maioria de nós acha que nós estamos no nível estadual facilmente. Nós não somos).

Além de recomendação de Brian de Clean Code por Robert C Martin , você pode querer ler sobre "Tio Bob" sólidos princípios de Object Oriented design .

Você pode ouvi-lo falar sobre os princípios sólidos em Hanselminutes Podcast 145 e limpo código em .NET rochas! Show # 388 . Há também mais com ele é sobre .NET rochas! Show # 410 , mas o que ele fala sobre não está realmente relacionado à sua pergunta, eu só incluiu em caso você gostou dos dois primeiros.

Dos três podcasts eu preferia as Hanselminutes.

Refactoring por Martin Fowler é um excelente livro sobre como alterar o design do seu software sem quebrá-lo.

Design Patterns funciona de forma semelhante ao algorithims mas diz-lhe como combinar objetos para executar várias tarefas úteis.

Finalmente Martin Fowler tem uma variedade de padrão de design útil para aplicações. Por exemplo Passive View

de Michael Feathers "trabalhar efetivamente com Legacy Code" é suposto ser muito bom, mas vou confessar que eu não li isso sozinho.

O mesmo vale para " refatoração para Padrões. "

Descobri que trabalhar em um 'atribuição' complexo sem ajuda e depois ver como alguém fez isso foi uma experiência de aprendizagem grande para mim.

Uma atribuição em particular foi a criação de um banco como o programa onde tínhamos que monitorar transações e ser capaz de calcular os juros auferidos e coisas assim. Foi realmente o meu primeiro programa de OOP e realmente um grande um por causa de sua complexidade. Ele fica muito confuso (para um iniciante) para fazê-lo em um estilo linear, sem cometer erros.

Eu só posso dizer o que funciona para mim, e eu realmente não encontrei qualquer um que funciona da mesma maneira, por isso não tenho certeza se ele vai ajudá-lo muito.

Basicamente, a minha abordagem é ter o menor número de aulas quanto possível, mas não menos.

Em primeiro lugar, a única vez que você precisa para guardar informações é se você recebê-lo em tempo de A e precisar dele em um momento B. posterior Se você obtê-lo e trabalhar nele ao mesmo tempo, pode ser que não há necessidade para armazená-lo.

Em segundo lugar, o que você faz com ele? Se você estiver indo para ser iteração através de certas formas simplificadas, você pode pensar nisso como um conjunto de instruções, eo programa que atua sobre ele como intérprete de um conjunto de instruções. Nesse caso, você pode querer realmente projetar um conjunto de instruções byte-code, com um intérprete, e codificar suas informações em que o conjunto de instruções.

Em terceiro lugar, como muitas vezes faz a mudança de informação? Se algumas das mudanças da informação somente muito raramente, você pode ser capaz de usar a avaliação parcial (ou seja, a geração de código). Ou seja, você levar a informação raramente mudando e usá-lo para gerar um programa ad-hoc que faz o que seu programa geral faria com essa informação, mas muito mais rápido. O gerador de código é fácil escrever porque ele lida apenas com parte da informação de entrada, a parte que muda lentamente.

A maior parte da estrutura de dados que vejo nos dias de hoje existe para apoiar UI. Isso claramente não está segurando objetos que os cuidados de usuários sobre e, idealmente, você não deve ter cuidado tanto. Então eu construí uma DSL para UIs que esconde tudo o que hoo-haw.

Fique longe de eventos e notificações se você possivelmente pode, porque eles acontecem em pontos no tempo e, portanto, representam mudanças incrementais no estado. Você vai ter que ser fortemente preocupados com a sua, possivelmente, ser descartado, duplicado ou misordered. Muitas vezes eles são utilizados na teoria de que um estilo de votação simples seria "menos eficientes", quando na verdade, muitas vezes acontece o contrário.

Então, quando eu ver as pessoas recebendo tudo embrulhado na tecnologia de aulas e assim por diante, geralmente é porque eles estão fazendo um negócio muito grande de estrutura de dados.

Apenas meu downvote-isca ...

Eu recomendo do Feather trabalhar efetivamente com Legacy Code , disponíveis e pesquisáveis ??no Safari , sobre Refactoring . É cheia de capítulos úteis e empatia como Eu não tenho muito tempo e eu tenho que mudar isso e Meu aplicativo não tem estrutura.

Perspectives a considerar:

Automatizando a qualidade do projeto de teste -. Olhar para obter ferramentas que fornecem métricas na qualidade do design, como uma verificação cruzada para suas decisões de design
Código Testability - fazer qualquer um dos seus refatorações ajuda ou desenvolvimento orientado a testes impedir, escrever testes de unidade ou escrever testes funcionais? Quão difícil será para testar grandes peças de arquitetura, uma vez integrado?
Justificação - como você defender essas decisões, tanto do CYA cínica de gestão e, mais importante, para que sua equipe acreditam na re-design. você pode facilmente e de forma consistente explicar por a alteração foi feita e essa explicação ser fácil de encontrar em 6 meses?

As preferências pessoais de design, especialmente refatoração:

Classes para Concepts -. Em caso de dúvida, se houver um único conceito claro, ele deve ser envolto em uma classe em vez de implícita como um comportamento em um ou métodos
Lotes de comunicação pequenas coisas com responsabilidades são mais fáceis de pensar e de auditoria. Quando estiver em dúvida sobre como um projeto mapeia para o mundo real, voltar para o velho Responsabilidade-Driven- projetar abordagem de escrever as responsabilidades de cada classe. Se você achar difícil, seus conceitos do que cada classe não pode ser confusa ou que estão fazendo muito.
Não se assuste com as coisas que são grande se eles são regulares. Às vezes, por exemplo:. Lotes de manipuladores de eventos sobre GUIs, você vai legitimamente têm aulas com muito mais métodos ou propriedades de métricas recomendam

Tente escrever código mais testável, isto só me obrigou a pesquisar e implementar melhores práticas OOP / conceitos de design.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow