O que se entende por "OOP esconde o estado"? [fechadas]

Em um dos muitos protestos anti-POO em cat-v.org , encontrei uma passagem de Joe Armstrong levantando várias objeções contra o modelo de POO, uma das quais era a seguinte:

Objeção 4 - Objetos possuem estado privado

O estado é a raiz de todo mal. Em particular, funções com efeitos colaterais devem ser evitadas.

Embora o estado nas linguagens de programação seja indesejável, no mundo real o estado é abundante. Estou muito interessado no estado da minha conta bancária e, quando deposito ou saio dinheiro do meu banco, espero que o estado da minha conta seja atualizado corretamente.

Dado que o estado existe no mundo real, que facilidades a linguagem de programação deve oferecer para lidar com o estado?

OOPLs dizem "ocultar o estado do programador". Os estados estão ocultos e visíveis apenas através das funções de acesso. As linguagens de programação convencionais (C, Pascal) dizem que a visibilidade das variáveis ​​de estado é controlada pelas regras de escopo da linguagem. Linguagens declarativas puras dizem que não há estado. O estado global do sistema é realizado em todas as funções e sai de todas as funções. Mecanismos como mônadas (para FPLs) e DCGs (linguagens lógicas) são usados ​​para ocultar o estado do programador, para que possam programar “como se o estado não importasse”, mas ter acesso total ao estado do sistema, caso isso seja necessário.

A opção "ocultar o estado do programador" escolhida pelos OOPLs é a pior opção possível. Em vez de revelar o estado e tentar encontrar maneiras de minimizar o incômodo do estado, eles o escondem.

O que exatamente se entende por isso? Tenho muito pouca experiência em procedimentos ou nível baixo, principalmente OOP, de modo que provavelmente explique o quanto eu não estou familiarizado com isso. E de um ponto de vista mais moderno, agora que a maioria da histeria orientada a objetos foi aprovada (pelo menos até onde eu sei), qual é a precisão / relevância que vocês acham que essa passagem é?

Obrigado pela ajuda.

O que exatamente se entende por isso?

Nesse contexto, significa que o OOP obscurece o estado de um programa, escondendo-o do programador, mas ainda o tornando visível através de métodos acessadores (com vazamento). O argumento é que, ao obscurecer o estado, torna mais difícil trabalhar e, por extensão, levar a mais erros.

quão preciso / relevante vocês acham que essa passagem é?

Eu sinto que é relevante, mas mal direcionado. Existe absolutamente um problema se sua classe vazar o conceito de seu estado para o mundo exterior. Existe absolutamente um problema se a sua turma tentar obscurecer o estado quando deve ser manipulado pelo mundo exterior. Isso, porém, não é uma falha do OOP como um todo, mas com o design individual da classe. Eu não diria que esconder o próprio estado é um problema - as mônadas fazem isso na programação funcional o tempo todo.

No melhor dos casos, o OOP funciona como a melhor combinação de programação funcional e processual - as pessoas podem usar a classe "como se o estado não importasse" porque o estado privado usado para proteger os invariantes da classe está oculto, mas tem liberdade usar um estado público bem definido da classe que abstraia os detalhes.

OOP torna mais difícil para as pessoas alcançarem esse melhor dos casos? Possivelmente. "Escolas Java" e toda a escola Forma / Círculo / Retângulo ou Carro têm o ensino de OO na Wheels, provavelmente têm mais culpa do que a própria abordagem. A OOP moderna se apóia bastante na programação funcional, incentivando objetos imutáveis ​​e funções puras, enquanto desencoraja a herança para ajudar a facilitar o design de classes que funcionam bem.

O raciocínio sobre um sistema será difícil se houver partes de estado mutável que não tenham um "proprietário" claro e único. Isso não significa que os objetos nunca devam ter um estado mutável, mas os objetos que têm um estado mutável não devem ser usados ​​de maneiras em que a propriedade não seja clara e, inversamente, que os objetos que precisarão ser passados ​​livremente sem rastrear a propriedade devem seja imutável.

Na prática, a programação eficiente freqüentemente requer que alguns objetos tenham um estado mutável; entretanto, esse estado deve ser confinado a objetos de trabalho não compartilhados . Considere as interfaces IEnumerable/ IEnumeratorno .NET: se uma coleção for implementada IEnumerable, ela permitirá que os itens sejam lidos um de cada vez. O processo real de leitura de uma coleção geralmente exige o controle de quais itens foram lidos (uma parte do estado mutável), mas esse estado não está contido na implementação de IEnumerable. Em vez disso, IEnumerablefornece um método chamado GetEnumeratorque retornará um objeto que implementa IEnumeratore contém estado suficiente para permitir a leitura de itens da coleção. O fato de o objeto conter esse estado não apresentará problemas, no entanto,se a implementação do objeto IEnumeratornão for compartilhada .

O melhor padrão na maioria dos casos é usar uma mistura de objetos que são compartilhados livremente, mas nunca serão modificados (pelo menos não depois de terem sido compartilhados) e objetos que tenham um proprietário claro e que possam ser modificados livremente por esse proprietário. , mas nunca são compartilhados com ninguém.

Correndo o risco de ir além da resposta à pergunta, é fácil ver falhas na ideia de OOP, mas estou inclinado a pensar que o poder de uma idéia se reflete em sua capacidade de ser abusado.

Afinal, todo mundo tem seu idioma favorito, que eles descrevem em termos como "muito, muito poderoso", significando que realmente gostam dele . Mas a maravilha da universalidade computacional é que, por mais gloriosa que seja uma linguagem, se é verdadeiramente poderosa, ela pode simular a linguagem assembly. E se puder, alguém verá que sim. (Não que haja algo errado com a linguagem assembly.)

Meu sentimento pessoal sobre o movimento da OOP é que ele representa um atraso na educação das pessoas em engenharia de software / ciência da computação. Eles são atrofiados em um nível em que acham que é tudo sobre estrutura de dados. Classes, herança, contêineres, iteradores, mapas de hash, propriedades, ocultação de estado etc. - tudo sobre estrutura de dados - quanto mais, melhor.

Pessoalmente, eu gostaria de ver um próximo nível em que as pessoas aprendam a resolver problemas olhando-os linguisticamente. Onde eles entenderiam o conceito de linguagens específicas de domínio, como fazê-las facilmente e permitir que sua criação seja parte integrante da solução de problemas. Não é incorreto dizer que uma estrutura de dados é uma linguagem. As pessoas devem ter essa habilidade no design da linguagem, para que não estejam apenas atrapalhando.

Como próximo nível, eu gostaria de ver a inteligência artificial revigorada. Gostaria de ver os programadores irem além de bytes, threads e tabelas de funções virtuais e CUDAs, além de entender como fazer com que as máquinas raciocinem, aprendam e criem. Eu sei que isso avançou muito longe nos cantos do campo, mas nem de longe o suficiente.

A acessibilidade não é um recurso do OOP, é específica para implementações como Java e Microsoft dotNET. A principal característica que define a POO é o polimorfismo.

De qualquer forma, ocultando o estado do objeto, não há como criar uma API significativa. A apresentação é um componente vital da OOP do mundo real. Aqueles que discordam provavelmente têm uma hostilidade irracional em relação à indústria de software, o que torna sua opinião irrelevante do meu ponto de vista.

Sites como o que você vinculou são famosos por pensamentos extremamente rígidos e críticas a novas tecnologias. Algumas pessoas simplesmente não entendem.