Para quais problemas a programação orientada a objetos não é uma boa escolha? [fechadas]

Um pouco inspirado por esta pergunta: para quais problemas comuns a programação funcional não se encaixa? - mas, no entanto, uma pergunta que eu sempre quis, mas estava com muito medo de fazer.

Estive em ... bem, vamos chamá-lo de desenvolvimento de software de engenharia praticamente toda a minha vida e durante todo esse tempo, embora o OO sempre estivesse lá (bem, na maioria das vezes), nunca tive a necessidade de usar "seus caminhos", nem para aprender esse paradigma. Sempre usamos estruturas, rotinas / funções / módulos de programas bastante simples e, embora seja oposto às práticas recomendadas de hoje em dia, gerenciar esses programas (programas de até aproximadamente 300k LOC, nada grande demais) nunca provou ser difícil, muito menos impossível.

Então, eu queria perguntar a você, quais seriam os problemas para os quais o paradigma orientado a objetos não seria uma boa escolha? Em comparação com a programação procedural?

Programação orientada a objetos é programação procedural. O que orienta os objetos OO é, como Robert Harvey menciona em um comentário, que OO abstrai dados de uma maneira particular (isto é: agrupar as funções que operam em uma estrutura com essa estrutura).

William Cook explica bem a diferença entre objetos e tipos de dados abstratos.

Portanto, com o risco de parecer fácil, eu diria que os objetos não são adequados para quando você precisa estender facilmente as (número de) operações que executam em seus dados e não precisa ter implementações variadas de seus dados. dados. Dito isto, há coisas que você pode fazer para aproximar os dois.

O principal valor do OO é que ele fornece dissociação entre os componentes do seu sistema, facilitando a gravação de código DRY e a adaptação a tipos específicos de alterações que você planeja em seu design. O custo é que ele adiciona camadas de indireção, o que pode tornar o código mais difícil de raciocinar, menos eficiente e mais difícil de modificar de maneiras imprevistas (as formas que não são auxiliadas pela dissociação fornecida pelo seu design). Portanto, é uma perda de tempo para qualquer subproblema em que você não precise da dissociação que ela fornece. Especificamente, é um desperdício de tempo se você puder escrever facilmente código DRY sem ele e não antecipar nenhuma alteração de requisito específico que se beneficiaria da forte dissociação que o OO fornece.

simultaneidade: o mecanismo de bloqueio parece meio problemático; somente alguns desenvolvedores muito bons são colocados para trabalhar na parte de segmentação dos projetos

estendendo: não sabe o quão extensível são os idiomas OO atuais. só sei que Java é ruim. portanto, as DSLs (linguagens específicas do domínio) devem ser implementadas como Frameworks. O Clojure, por outro lado (que é funcional), possui macros.

A maioria dos programadores, conhecedores ou não de OO, usa conceitos como abstração, ocultação de informações e interfaces em seu código. As linguagens OO simplesmente facilitam isso, pois esses conceitos já estão embutidos. Você não precisa inventá-los você mesmo.

Um algoritmo básico como qsort()usa abstrações para comparação de objetos arbitrários. fread()usa uma interface para abstrair os detalhes do fluxo etc.

Desse ponto de vista, acho difícil encontrar qualquer problema específico que seja melhor resolvido com uma abordagem não OO.

Eu acho que ao criar sistemas que combinam outros sistemas através de APIs da Web (resto, xmlprc, curl / wget simples), você pode escrever wrappers OO, mas é claramente apenas uma conveniência. Se o serviço da Web a ser usado for simples e for apenas uma ou duas linhas, o OO será demais. Se, por outro lado, você tiver que quebrar uma API da Web complexa (como o Amazon AWS, por exemplo), é bom ter uma biblioteca de wrapper (como boto em python para AWS).

Pensamentos?

As linguagens orientadas a objetos PURE não são adequadas para muitos casos. Porque existem alguns critérios a serem cumpridos por ser pura linguagem orientada a objetos. Consulte
/programming/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

Mas as linguagens de programação mais usadas são multiparadigma. Eles incorporam muitos recursos não OO para encontrar vários tipos de problemas de programação e desenvolvimento. C ++, C #, Java ou Ruby têm funcionalidades não OO. Portanto, eles podem enfrentar problemas nos quais o OO puro não é bom.

A programação orientada a objetos pode ser usada para modelar seu domínio. As classes podem ser usadas para representar o estado e o comportamento de entidades, agregados, colaborações, serviços dentro do seu modelo de domínio. Além disso, as invocações e protocolos de método entre os objetos podem modelar os relacionamentos dinâmicos entre entidades.

Descobri que é uma maneira útil de produzir um modelo DRY que possa representar de maneira limpa as regras e o comportamento do seu aplicativo, de maneira dissociada de problemas técnicos (como o uso de um banco de dados, uma fila de mensagens ou o é uma aplicação web). Um bom livro sobre o tema é Design Orientado a Domínio

Uma coisa importante a ser observada aqui é que as "entidades" que mencionei acima não precisam ser mapeadas para objetos do mundo real! Eles podem representar partes abstratas do domínio do seu aplicativo.

Portanto, se é nisso que a programação orientada a objetos é boa; o que não é bom? Bem, qualquer coisa em que o modelo de domínio não possa ser expresso bem como objetos. Por exemplo, alguns programas matemáticos (estatísticos, lógicos, etc.) ou técnicos (por exemplo, um compilador) são expressáveis ​​melhor em diferentes estilos. Descobri que, para aplicativos de fluxo de trabalho de negócios, uma combinação de técnicas OO e DSL personalizadas foi muito eficaz para permitir modelar os tipos de relacionamentos e eventos que ocorrem no processo de negócios. Para a verificação do programa e a verificação automatizada de provas, uma abordagem funcional é frequentemente usada, porque suas funções puras permitem um raciocínio matemático mais direto.