Quando o OOP é mais adequado?[fechado]

Question

Desde que comecei a estudar programação orientada a objetos, leio frequentemente artigos/blogs dizendo que funções são melhores ou que nem todos os problemas devem ser modelados como objetos.Das suas aventuras pessoais de programação, quando você acha que um problema é melhor resolvido pela OOP?

Answer 1

Não existe uma regra rígida e rápida.Um problema é melhor resolvido com OOP quando você é melhor em resolver problemas e pensar em uma mentalidade OO.Orientação a Objetos é apenas mais uma ferramenta que surgiu na tentativa de tornar a computação uma ferramenta melhor para resolver problemas.

No entanto, pode permitir uma melhor reutilização de código e também levar a um código mais organizado.Mas muitas vezes essas qualidades altamente elogiadas têm, na verdade, pouco valor real.Aplicar técnicas OO a uma aplicação funcional existente pode realmente causar muitos problemas.A habilidade consiste em aprender muitas técnicas diferentes e aplicar a mais adequada ao problema em questão.

OO é frequentemente citado como uma solução semelhante ao Nirvana para o desenvolvimento de software, porém muitas vezes não é apropriado aplicá-lo ao problema em questão.Muitas vezes, pode levar à engenharia excessiva de um problema para chegar à solução perfeita, quando muitas vezes isso não é realmente necessário.

Em essência, OOP não é realmente Programação Orientada a Objetos, mas mapeia o Pensamento Orientado a Objetos para uma linguagem de programação capaz de suportar Técnicas OO.As técnicas OO podem ser suportadas por linguagens que não são inerentemente OO, e existem técnicas que você pode usar em linguagens funcionais para aproveitar os benefícios.

Por exemplo, desenvolvo software OO há cerca de 20 anos, então tendo a pensar em termos OO ao resolver problemas, independentemente da linguagem em que estou escrevendo.Atualmente estou implementando o polimorfismo usando Perl 5.6, que não oferece suporte nativo.Optei por fazer isso porque tornará a manutenção e extensão do código uma tarefa simples de configuração, em vez de um problema de desenvolvimento.

Não tenho certeza se isso está claro.Tem gente que é dura na quadra OO, e tem gente que é dura na quadra Funcional.E há pessoas que experimentaram os dois e tentam tirar o melhor de cada um.Nenhum dos dois é perfeito, mas ambos têm características muito boas que você pode utilizar independentemente do idioma.

Se você está tentando aprender OOP, não se concentre apenas em OOP, mas tente utilizar a Análise Orientada a Objetos e os princípios gerais de OO para todo o espectro da solução do problema.

Answer 2

Sou veterano, mas também programo OOP há muito tempo.Pessoalmente, sou contra usar OOP apenas para usá-lo.Prefiro que os objetos tenham razões específicas para existir, que modelem algo concreto e que façam sentido.

O problema que tenho com muitos desenvolvedores mais novos é que eles não têm noção dos recursos que estão consumindo com o código que criam.Ao lidar com uma grande quantidade de dados e acessar bancos de dados, o modelo de objeto "perfeito" pode ser a pior coisa que você pode fazer em termos de desempenho e recursos.

Meu resultado final é: se faz sentido como um objeto, programe-o como um objeto, desde que você considere o impacto no desempenho/recurso da implementação do seu modelo de objeto.

Answer 3

Acho que se encaixa melhor quando você está modelando algo coeso com o estado e as ações associadas a esses estados.Acho que isso é meio vago, mas não tenho certeza se há uma resposta perfeita aqui.

O que acontece com o OOP é que ele permite encapsular e abstrair dados e informações, o que é uma grande vantagem na construção de um grande sistema.Você pode fazer o mesmo com outros paradigmas, mas parece que a OOP é especialmente útil nesta categoria.

Também depende do idioma que você está usando.Se for uma linguagem com suporte avançado a OOP, você provavelmente deverá usar isso a seu favor.Caso contrário, talvez seja necessário encontrar outros mecanismos para ajudar a dividir o problema em partes menores e facilmente testáveis.

Answer 4

Fui vendido para OOP.

Sempre que você puder definir um conceito para um problema, ele provavelmente poderá ser encapsulado em um objeto.

O problema com OOP é que algumas pessoas abusaram dele e tornaram seu código ainda mais difícil de entender.Se você tiver cuidado com o que coloca nos objetos e com o que coloca nos serviços (classes estáticas), você se beneficiará com o uso de objetos.

Só não coloque algo que não pertence a um objeto no objeto porque você precisa que seu objeto faça algo novo que você não pensou inicialmente, refatore e encontre a melhor maneira de adicionar essa funcionalidade.

Answer 5

Existem 5 critérios se você deve preferir código orientado a objetos em vez de código baseado em objetos, funcional ou processual.Lembre-se de que todos esses estilos estão disponíveis em todos os idiomas, eles são estilos.Tudo isso está escrito no estilo "Devo favorecer OO nesta situação?"

O sistema é muito complexo e possui aproximadamente 9k LOC (apenas um nível arbitrário).-- À medida que os sistemas se tornam mais complexos, os benefícios obtidos pelo encapsulamento da complexidade aumentam bastante.Com OO, ao contrário de outras técnicas, você tende a encapsular cada vez mais a complexidade, o que é muito valioso nesse nível.Baseado em objetos ou processuais devem ser favorecidos antes disso.(Isso não é defender um idioma específico, veja bem. OO C se encaixa mais nesses recursos do que OO C++ em minha mente, uma linguagem com uma reputação notória de abstrações vazadas e uma capacidade de comer em lojas com até mesmo um programador medíocre/obstinado para o almoço).

Seu código não consiste em operações em dados (ou seja,Baseado em banco de dados ou baseado em matemática/análise).O código baseado em banco de dados costuma ser representado mais facilmente por meio de estilo processual.O código baseado em análise geralmente é mais fácil de ser representado em um estilo funcional.

Seu modelo é uma simulação de algo (OO é excelente em simulações).

Você está fazendo algo para o qual o envio de subtipo baseado em objeto de OO é valioso (ou seja, você precisa enviar uma mensagem para todos os objetos de um determinado tipo e vários subtipos e obter uma reação apropriada, mas diferente, de todos eles) .

Seu aplicativo não é multithread, especialmente em um tipo de base de código de método de tarefa que não seja de trabalho.OO é bastante problemático em programas multithread e que exigem threads diferentes para executar tarefas diferentes.Se o seu programa estiver estruturado com um ou dois threads principais e muitos threads de trabalho fazendo a mesma coisa, o fluxo de controle confuso dos programas OO será mais fácil de lidar, pois todos os threads de trabalho ficarão isolados naquilo que tocam e podem ser considerados como uma seção monolítica de código.Considere qualquer outro paradigma, na verdade.Funcional é excelente em multithreading (a falta de efeitos colaterais é uma grande vantagem), e a programação baseada em objetos pode oferecer benefícios com parte do encapsulamento de OO, porém com código processual mais rastreável em seções críticas de sua base de código.É claro que o processual também se destaca nessa área.

Answer 6

Alguns lugares onde OO não é tão bom são onde você lida com "conjuntos" de dados, como no SQL.OO tende a dificultar as operações baseadas em conjuntos porque não foi realmente projetado para otimizar a interseção de dois conjuntos ou o superconjunto de dois conjuntos.

Além disso, há momentos em que uma abordagem funcional faria mais sentido, como este exemplo retirado de MSDN:

Considere, por exemplo, escrever um programa para converter um documento XML em uma forma diferente de dados.Embora certamente fosse possível escrever um programa C# que analisasse o documento XML e aplicasse uma variedade de instruções if para determinar quais ações tomar em diferentes pontos do documento, uma abordagem indiscutivelmente superior é escrever a transformação como uma folha de estilo eXtensível Programa de transformação de linguagem (XSLT).Não é de surpreender que o XSLT tenha um grande traço de funcionalismo dentro dele

Answer 7

Acho que ajuda pensar num determinado problema em termos de “coisas”.

Se o problema puder ser pensado como tendo uma ou mais 'coisas', onde cada 'coisa' possui um número de atributos ou informações que se referem ao seu estado, e um número de operações que podem ser executadas nele - então OOP é provavelmente o caminho a percorrer!

Answer 8

A chave para aprender Programação Orientada a Objetos é aprender sobre Design Pattern.Ao aprender sobre padrões de design, você poderá ver melhor quando as classes são necessárias e quando não são.Como qualquer outra coisa usada na programação, o uso de classes e outros recursos das linguagens OOP depende do seu design e requisitos.Assim como os algoritmos, os padrões de design são um conceito de nível superior.

Um Design Pattern desempenha um papel semelhante ao dos algoritmos para linguagens de programação tradicionais.Um padrão de design informa como criar e combinar objetos para executar alguma tarefa útil.Assim como os melhores algoritmos, os melhores padrões de projeto são gerais o suficiente para serem aplicados a uma variedade de problemas comuns.

Answer 9

Na minha opinião, é mais uma questão sobre você como pessoa.Certas pessoas pensam melhor em termos funcionais e outras preferem classes e objetos.Eu diria que a OOP é mais adequada quando corresponde ao seu modelo mental interno (subjetivo) do mundo.

Answer 10

O código orientado a objetos e o código processual têm diferentes pontos de extensibilidade.As soluções orientadas a objetos facilitam a adição de novas classes sem modificar as funções existentes (consulte o Princípio Aberto-Fechado), enquanto o código processual permite adicionar funções sem modificar as estruturas de dados existentes.Muitas vezes, diferentes partes de um sistema requerem abordagens diferentes, dependendo do tipo de mudança prevista.

Answer 11

OO permite que a lógica relacionada a um objeto seja colocada em um único local (a classe ou objeto) para que possa ser desacoplada e mais fácil de depurar e manter.

O que observei é que todo aplicativo é uma combinação de OO e código processual, onde o código processual é a cola que une todos os seus objetos (no mínimo, o código da sua função principal).Quanto mais você transformar seu código processual em OO, mais fácil será manter seu código.

Answer 12

Por que OOP é usado para programação:

1. Sua flexibilidade – OOP é realmente flexível em termos de implementações de uso.
2. Isso pode reduzir seus códigos-fonte em mais de 99,9% – pode parecer que estou exagerando, mas é verdade.
3. É muito mais fácil implementar segurança – Todos sabemos que a segurança é um dos requisitos vitais quando se trata de desenvolvimento web.Usar OOP pode facilitar as implementações de segurança em seus projetos web.
4. Torna a codificação mais organizada – Todos sabemos que um Programa Limpo é uma Codificação Limpa.Usar OOP em vez de processual torna as coisas mais organizadas e sistematizadas (obviamente).
5. Isso ajuda sua equipe a trabalhar uns com os outros facilmente - eu sei que alguns de vocês tiveram/experimentaram projetos de equipe e alguns de vocês sabem que é importante ter o mesmo método, implementações, algoritmo etc etc etc

Answer 13

Depende do problema:o paradigma OOP é útil no projeto de sistemas distribuídos ou frameworks com muitas entidades vivendo durante as ações do usuário (exemplo:aplicação web).

Mas se você tiver um problema matemático, preferirá uma linguagem funcional (LISP);para sistemas de desempenho crítico, você usará ADA ou C, etc.

A linguagem OOP é útil porque também utiliza provavelmente o coletor de lixo (uso automático de memória) na execução do programa:você programa em C muito tempo você deve depurar e corrigir manualmente um problema de memória.

Answer 14

OOP é útil quando você tem coisas.Um soquete, um botão, um arquivo.Se você terminar uma classe em er, quase sempre é uma função que finge ser uma classe.TestRunner provavelmente deveria ser uma função que executa testes (e provavelmente chamada de testes de execução).

Answer 15

Pessoalmente, acho que OOP é praticamente uma necessidade para qualquer aplicação grande.Não consigo imaginar ter um programa com mais de 100 mil linhas de código sem usar OOP, seria um pesadelo de manutenção e design.

Answer 16

Eu te digo quando OOP é ruim.

Quando o arquiteto escreve código OOP realmente complicado e não documentado.Sai no meio do projeto.E muitas de suas partes de código comuns que ele usou em vários projetos estão faltando código.Graças a Deus pelo .NET Reflector.

E a organização não estava executando o Visual Source Safe ou o Subversion.

E eu sinto muito.2 páginas de código para fazer login são um tanto ridículas, mesmo que sejam lindamente OOPed....