Qual é o processo de pensamento orientado a objetos? [fechadas]

Venho estudando OOP em conjunto com a implementação MVC do Zend nos últimos meses. Eu sou bastante iniciante em programação, geralmente, mas sinto fortemente que devo aprender as coisas da maneira 'certa', o que para mim significa ter certeza de que entendo por que as coisas são feitas da maneira que são. Ou seja, eu descobri que, ao aprender a fazer alguma coisa (qualquer coisa, digamos, música), a melhor maneira de aprender a fazer alguma coisa é saber por que isso foi feito dessa maneira.

Enfim, tenho lutado muito para entender como desenvolver meus próprios modelos de negócios (ou seja, o M do MVC), e decidi que não é porque não entendo OOP em geral, porque o estudei por vários anos. meses e não acho que os conceitos sejam muito difíceis de entender. Acho os exemplos que estudei muito intuitivos, na verdade. Penso que o problema para mim reside no processo de traduzir meus próprios problemas em soluções orientadas a objetos. Os exemplos nos livros (que eu li até agora) são muito óbvios; portanto, o processo de traduzir o problema em objetos não é muito difícil. O que acho que posso estar perdendo é um processo abstrato de alto nível. Algum tipo de lista de etapas ou perguntas que toda solução orientada a objetos deve responder no nível mais alto.

Se você tivesse que descrever esse processo em não mais que cinco etapas, quais seriam e por quê? Qual é o processo mais eficaz para traduzir qualquer problema em uma solução orientada a objetos?

Encontrar um modelo adequado nem sempre é simples. É uma dessas coisas que requer mais experiência do que simples conhecimento. No entanto, a seguinte receita simples pode ajudá-lo a superar um bloqueio mental inicial.

Foi originalmente descrito neste trabalho por Abbott e é freqüentemente chamado de "análise textual de Abbott".

1. Escreva uma especificação de texto simples.
2. Identifique classes: os substantivos são bons candidatos.
3. Encontre os atributos: Adjetivos / advérbios são bons candidatos.
4. Encontre as operações: Os verbos são bons candidatos.
5. Encontre as associações entre classes.
6. Refinar.

Exemplo:

Substantivos , verbos e adjectivessão marcados.

A biblioteca contém livros e revistas . Pode ter várias cópias de um determinado livro . Alguns dos livros são apenas para short-term empréstimos . Todos os outros livros podem ser emprestados por qualquer membro da biblioteca por três semanas. Os membros da biblioteca normalmente podem emprestar até seis itens por vez, mas os membros da equipe podem emprestar até 12 itens por vez. Somente membros da equipe podem emprestar diários .

Uma primeira iteração de análise renderia:

Aulas:

• Biblioteca
• Livro, Diário
• cópia de
• Empréstimo
• Membro da biblioteca
• Item
• Membro da equipe

A partir daqui, você pode pensar sobre qual classe precisa de quais atributos e métodos para implementar o comportamento e refinar esse modelo cada vez mais.

Na minha opinião, adotar a abordagem TDD é natural e eficiente:

1. Anote requisitos específicos (Fornecido, Quando e Depois)
2. Traduza cada requisito (o mais importante primeiro) em um teste de unidade.
3. Escreva a menor quantidade de código para passar no teste escrito em # 2.
4. Depois de passar no teste, refatorar seu código de acordo com os princípios de design do SOLIDD.
5. Após o nº 4, verifique se o seu código ainda passa em todos os testes escritos.
6. Repita 2-5.

Com esse processo, você pode produzir gradualmente código testável com design de som. Você pode pensar primeiro que o teste de escrita é desnecessário, mas essa atividade realmente ajuda a construir uma arquitetura de som.

Aqui estão as etapas que eu uso no código c ++:

1. decidir o nome da classe
2. decidir os parâmetros do construtor e os membros dos dados.
3. decidir nomes e protótipos de função de membro
4. torná-lo independente de outras classes
5. O design está pronto e tudo o mais é apenas a implementação.

O motivo para (1) é que ele define o escopo de qual funcionalidade pertence à classe. A razão para (2) é que ela define como a classe se comunica com o mundo exterior. A razão para (3) é que ele define como escolher qual funcionalidade da classe é necessária em cada situação. A razão para (4) é que ela permite que a classe seja usada em muitas situações diferentes. A razão para (5) é que ele define a fronteira entre design e implementação.