Como praticar a programação orientada a objetos? [fechadas]

Sempre programei em linguagens processuais e atualmente estou me movendo em direção à orientação a objetos. O principal problema que enfrentei é que não vejo uma maneira de praticar a orientação a objetos de maneira eficaz. Eu vou explicar o meu ponto. Quando aprendi PHP e C, foi muito fácil praticar: era apenas uma questão de escolher algo e pensar em um algoritmo para isso.

No PHP, por exemplo, era importante sentar e pensar: "bem, apenas para praticar, deixe-me criar um aplicativo com uma área de administração onde as pessoas possam adicionar produtos". Isso foi bastante fácil, era questão de pensar em um algoritmo para registrar algum usuário, fazer login no usuário e adicionar os produtos. Combinando esses recursos com o PHP, foi uma boa maneira de praticar.

Agora, na orientação a objetos, temos muitas coisas adicionais. Não se trata apenas de pensar em um algoritmo, mas de analisar os requisitos mais profundamente, escrever casos de uso, descobrir diagramas de classes, propriedades e métodos, configurar injeção de dependência e muitas outras coisas.

O ponto principal é que, na maneira como aprendi a orientação a objetos, parece que um bom design é crucial, enquanto nas linguagens processuais uma idéia vaga era suficiente. Eu estou não dizer que em linguagens procedurais podemos escrever bom software sem projeto, só que por causa da prática é viável, enquanto em orientação a objetos não parece viável para ir sem um bom design, até mesmo para a prática.

Isso parece ser um problema, porque, a cada vez que vou praticar, preciso descobrir vários requisitos, casos de uso e assim por diante, parece não ser uma boa maneira de melhorar a orientação a objetos, porque isso exige para que eu tenha uma idéia inteira de um aplicativo toda vez que vou praticar.

Por isso, qual é uma boa maneira de praticar a orientação a objetos?

Agora, na orientação a objetos, temos muitas coisas adicionais.

Não, você não ...

Não se trata apenas de pensar em um algoritmo, mas de analisar os requisitos mais profundamente, escrever casos de uso, descobrir diagramas de classes, propriedades e métodos, configurar injeção de dependência e muitas outras coisas.

Nenhuma dessas coisas é necessária para praticar a programação orientada a objetos.

Isso foi bastante fácil, era questão de pensar em um algoritmo para registrar algum usuário, fazer login no usuário e adicionar os produtos.

Toda a programação orientada a objetos é, em vez de pensar nos algoritmos para executar essas etapas, você pensa sobre quais objetos são necessários para executar essas etapas - qual funcionalidade você deseja, qual estado é necessário para fazer isso e que tipo de interface você deseja expor. para o usuário. Assim como você tem que fazer na programação procedural.

A única diferença é que, em vez de se concentrar nas funções necessárias e como elas funcionam, você se concentra em como a funcionalidade e o estado são agrupados em responsabilidades e como essas responsabilidades interagem.

Como praticar? Da mesma maneira que você pratica a programação procedural: escolha um problema e resolva-o usando pacotes de classes. Descubra como isso foi péssimo, repita com as lições aprendidas.

Boa pergunta. Obviamente, o que você está dizendo é que praticar OOP significa praticar todas essas coisas (análise de requisitos, casos de uso, padrões de design etc.), o que é verdade e pode parecer assustador no começo.

Meu conselho seria iniciar suas sessões de prática mantendo duas coisas em mente: desenvolvimento orientado a testes e o princípio de responsabilidade única .

Então comece como você fez com o PHP / C: tenha uma idéia, pense no que você precisa para isso e implemente essas coisas uma após a outra. No entanto, lembre-se de que você precisa iniciar a partir dos testes (o que obriga a definir interfaces adequadas, caso contrário a testabilidade sofre imediatamente) e que o TDD implica um ciclo de refator vermelho-verde. Em outras palavras, você tem um pouquinho de funcionalidade e, uma vez que está funcionando, refatora para obter um design OO adequado, se você não o fez desde o início (o que você não fará).

Ao executar esta etapa de refatoração, lembre-se sempre do SRP. Se você adicionou uma segunda responsabilidade ao seu objeto, é hora de criar algo novo.

Quando você desenvolve dessa forma, precisa estar ciente de que sua solução final será muito diferente da que você começou. Sua curva de aprendizado também será bastante acentuada. Por exemplo, você não aprenderá o que é um padrão Factory, mas reconhecerá a necessidade de algo que crie instâncias da sua classe de maneiras diferentes. Portanto, se você nunca ouviu falar de padrões de design orientados a objetos, é bom ler um pouco sobre os paralelos.

Se você está apenas começando no OOP, pode se divertir e "praticar" offline, analisando praticamente qualquer sistema do mundo real e considerando quais são os objetos e qual a relação entre eles e quais métodos / interfaces eles podem suportar e como você os representaria em uma hierarquia de classes e como uma coleção de objetos instanciados e quais seriam as relações de propriedade do objeto e assim por diante (nota: não mencionei a palavra "algoritmos" acima). Desenhe vários diagramas (aprenda um pouco de UML ou similar) antes de pensar em codificar qualquer coisa.

Isso o ajudará a desenvolver um senso muito melhor das relações IS-A e HAS-A , que provavelmente é a classificação mais importante em qualquer projeto de OOP (e, apesar disso, ainda parece ser algo com o qual muitos programadores de idiomas experientes de OOP lutam. ) Se você domina IS-A / HAS-A, também há IS-IMPLEMENTED-IN-TERMMS-OF (que eu também vi descrito como IS-KIND-OF-A: ^)

Sério, na próxima ida ao supermercado, imagine que alguém lhe deu o trabalho de escrever uma simulação OOP do local ...

O que eu lembro dos meus tempos C (já no passado), costumávamos separar funções e procedimentos em arquivos diferentes com base em suas responsabilidades. Não estou afirmando que seja perfeito ou algo assim, mas foi um bom ponto de partida para quando comecei a programar em linguagens orientadas a objetos. Então talvez você possa começar com a conversão de arquivos em objetos.

No que diz respeito à POO, trata-se realmente de prática e busca de melhorias. Raramente alguém entende desde o início. Assim, as iterações ocorrem durante o ciclo de vida do projeto.

Vamos adicionar alguma terminologia, análise orientada a objetos e design orientado a objetos , como Peter Coad fez nos anos 90.

Juntos, eles formam uma disciplina OOAD de engenharia de software que pode (corretamente) dar suporte ao programador no momento de escrever e testar o código. A programação orientada a objetos pode ter seu nível adequado de granularidade, o uso hábil dos recursos da linguagem de programação para atender aos objetivos funcionais e aos requisitos de design especificados no nível do projeto.

Às vezes, é um projeto de uma pessoa, e então você deve usar todos os chapéus (mas não necessariamente todos ao mesmo tempo). Sou um grande fã do desenvolvimento orientado a testes para meus próprios projetos pessoais (consulte a recomendação de Frank), mas não se refere apenas ao desenvolvimento de software orientado a objetos.

Em um projeto de equipe, ter uma boa divisão de responsabilidades é a chave para uma implementação bem-sucedida. O uso hábil de padrões de design orientados a objetos ajuda o entendimento da equipe, limitando as interfaces visíveis necessárias para análise, feeds de dados e lógica de negócios para compartilhar uma estrutura utilizável.

"bem, apenas para praticar, deixe-me criar um aplicativo com uma área de administração onde as pessoas possam adicionar produtos". Isso foi bastante fácil, era questão de pensar em um algoritmo para registrar algum usuário, fazer login no usuário e adicionar os produtos.

Por que não fazer a mesma coisa apenas desta vez com objetos de usuário e objetos de produto? Além disso, se você estiver usando uma linguagem que ofereça suporte a procedimentos e OO, poderá tentar implementar objetos com base na biblioteca padrão de procedimentos, como um objeto de arquivo.