Como você conseguiu boas práticas para seus projetos de POO? [fechadas]

Percebi que tenho dificuldade em criar designs de OOP. Passei muito tempo decidindo se essa propriedade está configurada corretamente para a classe X.

Por exemplo, esta é uma postagem com alguns dias: /codereview/8041/how-to-improve-my-factory-design

Não estou convencido do meu código. Então, eu quero melhorar meus projetos, levar menos tempo para criá-los.

Como você aprendeu a criar bons designs? Alguns livros que você pode me recomendar?

Projetar sistemas é uma das coisas em que você só pode melhorar fazendo. Obviamente, ajuda um pouco a ler sobre um bom design - o livro de design geral orientado a objetos recomendado é o Design Patterns do Gang of Four : Elementos de software orientado a objetos reutilizáveis . Existem também outros livros sobre padrões e princípios de design para diferentes tipos de sistemas e em diferentes domínios.

Também é melhor envolver outras pessoas. Depois de criar um design, apresente os problemas que você está resolvendo e o design a outras pessoas para uma revisão crítica. Ouça os comentários deles e tenha um diálogo com eles, concentrando-se no motivo pelo qual você tomou as decisões que tomou. Ao implementar a solução, você perceberá outros problemas com seu design. Tome nota disso e aprenda com eles. Também pode ser uma boa ideia trabalhar com outras pessoas para revisar a implementação com relação ao design e aos requisitos e ter uma discussão crítica sobre os motivos pelos quais você fez o que fez.

Embora eu normalmente ache melhor me sentar pessoalmente com outras pessoas, perguntas específicas sobre o projeto podem ser feitas aqui em Programadores. Existem também sites do Stack Exchange para revisões de código e perguntas de implementação .

Pela aparência da pergunta de revisão de código que você fez, você está no estágio de exagerar. Eu acho que é um problema bastante comum entre as pessoas que descobrem a importância de um bom design.

Na verdade, é um passo natural e provavelmente até necessário com qualquer habilidade que você captar. Quando você começa a aprender algo, quanto mais você avança no conhecimento de uma habilidade e quanto mais a aplica, melhores seus resultados e parece que você estava indo direto ao domínio. O problema é que seu novo alvo não se torna a qualidade dos seus resultados, mas a quantidade de conhecimento que você acumulou em sua habilidade.

O verdadeiro domínio de uma habilidade envolve a compreensão de quando usá-la e quando não. O uso excessivo dessa habilidade é provavelmente a única maneira de desenvolver esse entendimento. Claro, você pode ler sobre isso, mas a leitura não substitui a experiência.

Por um lado, ler sobre padrões de design é um péssimo começo para IMHO. Ler sobre os princípios de design de OO, como SOLID e GRASP, é melhor. Depois de se familiarizar com eles, o estudo de padrões comuns de design é uma boa idéia, porque você verá como esses princípios podem ser aplicados para formar idiomas concretos.

Alega-se que, quando surgem padrões no uso de uma linguagem, a linguagem realmente não possui um recurso. Embora essa afirmação seja muito radical, há muita verdade nela. Portanto, eu sugiro que você olhe e brinque com outras linguagens para entender melhor os conceitos que está procurando empregar e também para aprender sobre novos conceitos. Uma lista restrita seria Squeak, Ruby e Lisp.
Quanto à Lista, minha recomendação pessoal é Estrutura e Interpretação de Programas de Computador , que me ensinaram muito sobre design, mostrando como é fácil criar soluções robustas para problemas complexos, com pouco mais que abstração clara e (des) composição em de maneira descendente.

Então, aqui está o que eu sugiro:

1. escreva código (e tente entender o que o torna ruim)
2. leia o código (e tente entender o que o torna bom)
3. trocar conhecimento com outras pessoas. coloque suas idéias à prova.

Como outros já mencionaram, você só ficará bom com prática e experiência. Não há realmente um atalho que você possa usar.

O fato de você olhar para as suas coisas e não gostar do que escreveu, já o coloca à frente da curva em comparação com muitas outras pessoas em nossa profissão. Enquanto você está tentando melhorar a si mesmo, o resto de nós trabalha com pessoas que escrevem uma função de 500 linhas com 20 parâmetros, todos passados ​​por referência e 15 deles sendo [in / out] e essas pessoas pensam que são a bomba porque eles fizeram essa bagunça trabalhar.

Quando se trata de design de software, não é preto e branco, é bom ou ruim. Não importa quanta experiência você tenha, você retornará a alguns dos seus códigos antigos e pensará: "o que eu estava fumando quando escrevi isso?" A chave é a avaliação constante das coisas e a frequência dos exercícios de pensamento para avaliar o que torna um bom código bom e ruim.

Finalmente, embora nada substitua a prática, é sempre uma boa idéia continuar sempre lendo blogs / livros / este site, porque outras pessoas apontarão perspectivas diferentes que você pode não ter considerado.

Para começar, eu recomendaria estes livros:

• Princípios, padrões e práticas ágeis em C # - eu mesmo sou 3/4 deste livro. Um dos principais pontos apontados pelo autor, e eu concordo 100% com isso, não comece a resolver um problema procurando um padrão de design a ser aplicado. Mantenha as coisas o mais simples possível e evolua o código para um padrão, se a alternativa começar a se tornar mais complicada do que isso.
• Padrões de design do Head First - Eu não li este livro e na IMO muitas séries do Head First são direcionadas especificamente para os novatos em campo. Portanto, eles tendem a ser do lado mais simples, mas ouvi / li muitas boas respostas de outras pessoas sobre esse livro

O design inicial nunca é tão bom quanto o design externo. Basta testar, codificar e refatorar. Quando as coisas estão feias e você não tem certeza de como limpá-las, verifique se algum padrão de design ajudará. Pratique isso por um tempo e em breve outros desenvolvedores perguntarão como você cria projetos tão limpos.