Dados imutáveis são realmente nescessários?

Desde que o objeto esteja bem encapsulado e testado, por quê não daria pra ser compartilhado, sendo que uma das principais premissas da OOP é reuso?

De fato, muitos patterns conhecidos em OOP acabam por ser desnecessários em linguagem funcional por motivos óbvios, mas evitar o estado a todo custo também tem seu custo em alguns cenários: muitos sistemas são feitos em OOP devido ao paradigma facilitar a abstração dos problemas, facilitar reuso, definição de tipos, etc. Sem contar que muitas equipes têm profissionais com experiência em OOP apenas, então não adianta tentar socar o paradigma funcional (de uma hora pra outra) numa equipe assim que vai ficar uma zona e mais caro no final.

Contudo, entretanto, todavia :), acho fantástico o paradigma funcional e a forma como resolvo problemas que seriam bem mais ardilosos utilizando OOP. Alguns projetos que tenho começado recentemente, tenho feito com Erlang/Elixir e até o momento não sinto falta alguma de OOP.

TDD não deve jamais ser imposto, alguns naquela thread apenas colocaram a experiência desenvolvendo TDD, como este contribuiu para diminuir custos e também atingir bons resultados de forma iterativa. Por isso que quando existe uma vaga pra desenvolvedor, muitas empresas colocam se fazem TDD ou não, desta forma o candidato fica livre pra escolher.

Mas assim como você diz que TDD não deve ser algo imposto, e eu concordo, programação funcional também não deve ser imposta e vendida aos 4 ventos como a solução para todas as coisas.
Eu uso TDD mesmo quando estou fazendo coisas em Elixir ou Clojure, pois TDD é um mindset que me ajuda a guiar o design do software, não importa se é imperativo, funcional, lógico, etc.

Resumindo: eu acho que nenhum paradigma é a prova de programador. Quando fazemos uma coisa mal feita num paradigma, nada nos impede de continuar fazendo mal feito em outro paradigma. A coisa mal feita continua, só muda de padrão

Se o programador é forçado a passar objetos como parâmetros em métodos, ele estará passando dados irrelevantes junto com dados necessarios para a função funcionar. Todo esse ocultamento e dados excessivos só torna mais difícil saber o que exatamente o método faz, sem falar que devido a herança, métodos e dados ficam espalhados em diferentes classes, dificultando o raciocínio (e o teste) das invariantes do objeto. Por tudo isso, na minha opinião encapsulamento destrói os benefícios da transparência referencial.

como foi falado na outra thread, front-end não precisa evitar estado mutável a todo custo. Mas software critico geralmente sim.

Sim, só pra software critico. Mas programadores OO também podem se beneficiar de aprender uma linguagem funcional visto que mesmo em linguagens sem transparência referencial, eles podem adotar um estilo de programação que evita estado mutável escondido para criar apps front-end ainda melhores.

Interessante. Eu mesmo não vejo desenvolvedores Erlang e Clojure falando de TDD. Mas pensando bem, o que eles falariam. Se eu uso uma biblioteca de terceiro, não me importa se o desenvolvedor usou TDD, só que tenha testes e estão passando.

Pelo que entendo, transparência referencial não está ligada apenas a linguagens funcionais. Nestas, devido à natureza da imutabilidade, é mais natural que se desenvolvam propriedades de transparência referencial, abrindo assim portas para as chamadas “funções puras”.

Mas isto não é impossível em OOP, pois nada impede-me de criar uma função:

int sumThree(int number) {
    return number + 3;
}

Se eu chamar sumThree(3) diversas vezes sempre me retorna 6. Entendo que isto é a propriedade de transparência referencial, certo?

Acho que perde-se a transparência referencial quando dentro da função temos acesso a escopo externo, global, então daí não temos mais controle algum do que pode acontecer, como você bem disse. Mesmo em linguagens funcionais, como Haskell, é permitido ter partes onde se tem mutabilidade, embora no Haskell isso é bem definido separando código mutável de imutável.

Escopo global tem de ser evitado quase sempre (uns dirão que sempre!), cabendo um estudo do que se vai desenvolver e decidir quando abrir mão de tal prática.

Quanto ao encapsulamento, não me referi apenas à forma naive de “getters and setters”, mas encapsulamento de objeto e estado, garantindo que o estado é gerenciável apenas dentro de um objeto. Um exemplo disso é o React com Redux, onde você tem componentes que são declarativos e um “grande objeto” que controla estado, responsável por gerenciar o estado a aplicar mudanças. Posso estar exagerando, mas ao meu entender, vejo que esse é um exemplo do “mix” entre OO e funcional.

E sobre herança, acho que é bem divulgado na comunidade que devíamos ao invés sempre favorecer composição, pois facilita testes e track do estado. Herança é outra coisa que tem de ser usada com muita cautela mesmo, com exceção em cenários como por exemplo extensibilidade, que é uma das propriedades da OOP (mas mesmo assim tento evitar herança ao máximo).

De novo, acho (no meu limitado conhecimento) que transparência referencial não é propriedade de uma linguagem ou paradigma específico apenas, mas se torna difícil garantir a mesma em linguagem OO se utilizarmos mutabilidade a rodo, escopo global e herança. Podem existir N casos que a falta de transparência referencial não será de todo um problema, é questão de avaliar.

E concordo contigo, paradigma funcional aplicado em linguagens imperativas com certeza traz muitos benefícios que ajudam a criar apps mais robustas.

Sobre a pergunta da thread: não sei onde você quer chegar exatamente, mas não vejo pq querer evitar mutabilidade a todo custo mesmo em sistemas críticos, sendo que muitas linguagens funcionais que não são 100% puras também têm sem quesito mutável quando necessário. De uma forma ou de outra, sistemas de qualquer categoria (backend, frontend, crítico, enterprise, não-enterprise, etc) vão precisar de estado, mesmo que seja na base de dados. Se puder explanar isso melhor, agradeço pq realmente não vejo como evitar a mutabilidade da forma como você tem argumentado.

Não sou experiente em Clojure, e me parece que a comunidade não investe mesmo em testes (digo pelos poucos projetos que vi). Não sei se pelo fato da S-expression já ajudar em algo pelo fato de validar conjunto de expressões, enfim…
Já em Elixir, vejo que a comunidade investe e clama muito por testes e principalmente TDD, visto que os doctests existem pra ajudar a escrever testes de forma incremental enquanto você documenta o código. Mas, de novo, isso sou eu. Não sou pago pra empurrar TDD no site do GUJ, portanto acho que nisto já estamos conversados e eu entendo seu ponto sobre testes

Sim, mas um compilador não pode substituir um pelo outro, como poderia numa linguagem que garante TR. Vai que dentro do método tem algum código que altera o estado de alguma variável de instância do objeto?

Eu acho que não é possível ter OO com apenas um objeto né?

Encapsulamento ajuda o programador a garantir as invariantes de um objeto, porque vc pode regular todo o acesso ao estado do objeto através de seus métodos. Composição de objetos não me ajuda porque é difícil garantir invariantes quando elas envolvem mais de 1 objeto.

Se for uma propriedade da linguagem, isso significa que o compilador pode afirmar algumas coisas sobre seu código, ex: substituir uma função pelo valor direto, pode rodar em paralelo, etc. Se a linguagem não garante TR isso não tem como.

Porque não? Estado mutavel é a razão para a maior parte do software hoje em dia ser tão complexo.

De uma forma ou de outra, sistemas de qualquer categoria (backend, frontend, crítico, enterprise, não-enterprise, etc) vão precisar de estado, mesmo que seja na base de dados. Se puder explanar isso melhor, agradeço pq realmente não vejo como evitar a mutabilidade da forma como você tem argumentado.

O problema não é estado, e sim estado mutável.

Todo projeto em Clojure que uso possui testes unitários. Mas TDD não é muito usado em linguagens funcionais, e pra explicar porque, ninguém melhor do que um especialista em TDD:

When we use TDD to develop a tell-don’t-ask system, we start at the high level and write tests using mocks to make sure we are issuing the correct “tells”. We proceed from the top of the system to the bottom of the system. The last tests we write are for the utilities at the very bottom.

In an ask-don’t-tell system, data starts at the bottom and flows upwards. The operation of each function depends on the data fed to it by the lower level functions. There is no mocking framework. So we write tests that start at the bottom, and we work our way up the the top.

Ou seja, não exatamente por ser S-expressions, mas pelo fato de Lisp ser uma linguagem funcional (isto é, as expressões são avaliadas de baixo pra cima, com a saída de cada função servindo de entrada para a próxima), o processo de desenvolvimento já é incremental e bottom-up por natureza.

Cara, lê o artigo até o fim.

Is TDD necessary in Clojure?
If you follow the code in the Orbit example, you’ll note that I wrote tests for all the computations, but did not write tests for the Swing-Gui. This is typical of the way that I work. I try to test all business rules, but I “fiddle” with the GUI until I like it.

If you look carefully you’ll find that amidst the GUI functions there are some “presentation” functions that could have been tested, but that I neglected to write with TDD[2]. These functions were the worst to get working. I continuously encountered NPEs and Illegal Cast exceptions while trying to get them to work.

My conclusion is that Clojure without TDD is just as much a nightmare as Java or Ruby without TDD.

Meu ponto é que o mindset TDD é diferente dependendo do paradigma usado. Como o especialista disse, TDD em linguagens OO é o oposto de linguagens funcionais.

Sobre clojure sem TDD ser um pesadelo, é a opinião pessoal dele. O uncle bob é especialista em TDD, não é autoridade em clojure. Em 2010, quando o artigo foi escrito, ele ainda estava começando na linguagem.

No meu caso ajuda na maioria das vezes. Desde que meus objetos estejam bem testados, consigo eliminar essa invariância uma vez que utilizando injeção de dependências meus componentes são testados isoladamente com sua própria API.

Minha questão não é o compilador, mas a “técnica” de transparência referencial não é encontrada apenas em linguagens funcionais. De acordo com Wikipedia:

An expression e is referentially transparent if and only if e can be replaced with its evaluated result without affecting the behavior of the program.

Diversas linguagens modernas utilizam técnicas como memoization, lazy evaluation para otimizar calls a essas “funções puras”, mas meu ponto não é nem este. Afinal, como você mesmo disse dos benefícios que o paradigma funcional poderia trazer para OO, esse é um deles, aplicando TR de forma a deixar os componentes idempotentes.

Exatamente, era isso o que eu queria dizer.

Esse artigo é interessante, eu li ele alguns anos atrás antes mesmo de mergulhar em linguagens funcionais e quando comecei a fazer TDD em linguagens funcionais, fiquei feliz por saber que não estava sozinho, pois no final ele mesmo afirma que Clojure sem TDD é um pesadelo, assim como em outras linguagens.

O mindset TDD é sempre o mesmo. O que muda são as técnicas, o fluxo, e mesmo sendo tão antigo o artigo como é, hoje em dia existem bibliotecas em diversas linguagens funcionais que facilitam o teste top-down, como exemplo esta que encontrei em Clojure.

Em Elixir, por exemplo, e eu acho que Elixir e Clojure até têm lá suas semelhanças, é possível fazer mock testing com libs externas, mas o mais comum e recomendado é utilizando a própria feature de behaviours.

De novo, não quero eternizar isto dizendo o que é melhor ou pior. Apenas entender o motivo do argumento de que com OO é impossível ter coisa bem feita, idempotente, isolada e escalável para software crítico. Diversas linguagens OO carregam features funcionais, como lazy evaluation, map, reduce, pipes, etc o que permitem um desenvolvimento “declarativo” quando necessário.

Ou seja, a opinião do especialista é válida contanto que reforce suas convicções pessoais! Fantástico!

Sobre os tais sistemas críticos feitos em OO…

Se estamos falando de sistemas onde uma falha pode acarretar perda massiva de vidas humanas, como sistemas de defesa e controle de usinas, então existem restrições na indústria sobre o uso de linguagens com alocação dinâmica de memória e garbage collectors. O que inclui Java em sua forma tradicional e praticamente TODAS as linguagens funcionais, inclusive Clojure. A maior parte desses sistemas é feita em C ou ADA (nenhuma relação com gangs). Ambas as linguagens não exigem imutabilidade, nem possuem qualquer facilidade nesse sentido. Por outro lado, ADA possui um vasto ecossistema de ferramentas para provar código, análise estática, etc.
Veja que nos manuais da NASA e do DoD não há nada que mencione transparência referencial como um pré-requisito suficiente nem necessário para a construção dessa classe de sistemas. A programação funcional sequer é considerada. O consenso na indústria ainda é que o método de construção é o fator primordial de qualidade em sistemas críticos e não a linguagem de programação. Eles estão satisfeitos programando estruturado em linguagens imperativas…

Eliminar invariância?

Invariantes

Por que você quer eliminar as invariantes do objeto??? Você tem que testar elas, não eliminar.

Estou falando do problema que é testar as invariantes que envolvem mais de 1 objeto. Se vc testa os objetos isoladamente, não testa invariantes que envolvem mais de 1 objeto. Então você mudou o problema.

Esse trecho não diz nada sobre TR ser encontrado em linguagens não-funcionais.

Mas eu entendo o que vc quer dizer, que TR é uma boa prática que o usuário de qualquer linguagem pode seguir. Mas ela não é característica de nenhuma linguagem OO. Programadores OO em geral nem sabem o que é TR.

A questão não é o número de técnicas que a linguagem disponibiliza, senão Scala seria um sucesso. Nenhuma linguagem não funcional é comum programação lazy. Simplesmente pq não há sinergia entre ter estado mutável e lazy evaluation. O inventor da linguagem pode até disponibilizar a técnica, mas é só isso mesmo.

Os beneficios do paradigma funcional para OO são limitados uma vez que depende da competência e disciplina de toda a equipe pra estar constantemente lembrando de evitar estado mutável. Basta alguém anular o seu método sumThree numa subclasse de maneira errada, e acabou a TR que você achou que tinha.

Engraçado porque não tem motivo nenhum pra hoje, os banco de dados serem mutáveis, isso é do tempo em que armazenamento era recurso escasso. Hoje em dia armazenamento é infinito na nuvem, as pessoas nem tem mais disquetes e cd-roms nos computadores.

Não é clojure sem TDD que é um pesadelo, mas sim clojure sem programação bottom-up. TDD é programação top-down.

Palavras tem significado. Se tudo muda e continua sendo TDD, eu suspeito que o termo (TDD) deixou de ter valor prático e talvez precisamos de um novo termo que possa melhor capturar a essência do que esta sendo comunicado?

Nenhum momento eu disse ser impossível, apenas dificil e portanto improvável dado a realidade do mercado. Mas com uma combinação de programadores ninja e rock stars, de preferencia com experiência em linguagens funcionais, tudo é possível.

Desde quando orientação cima - baixo é uma convicção minha? O próprio texto fala em top-down e bottom-up, que são coisas diferentes. Se você quer chamar coisas diferentes do mesmo nome porque o especialista disse, fique à vontade.

Você sabe que nem C nem ADA são orientadas a objetos né?

Poderia simplesmente ter dito que não tem sistemas criticos em OO, só relacional, funcional e estruturado.

Verdade, interpretei mal a tua primeira frase quando você disse que encapsulamento ajuda a garantir as invariantes de um objeto. Viajei total quando me referi ao termo, obrigado pelo toque.

ADA possui OO há mais de 10 anos. O DoD investigou a possibilidade de adotar OO em projetos de defesa. As linguagens funcionais sofrem da mesma restrição que as OO (alocação dinâmica, binding dinâmico). Mas isso na verdade não te interessa. O que te interessa é papaguear o que você leu no blog da esquina, como se fossem suas idéias…

Por favor, nos poupe dessa papagaiada de NASA e DoD. Você ainda não respondeu porque governos, corporações, bancos, telecoms, etc. só usam OO pra fazer CRUD. Na hora do vamos ver, é relacional ou funcional mesmo.

Eu só queria saber quem é o grande nome do OO? Assim como os nomes Oracle, Ericson e Neymar estão para o paradigma relacional, funcional e a seleção brasileira. Da pra ser ou tá difícil?

No DDD, a entidade que é o aggregate root é responsável por garantir as invariantes, mas ela não pode conter outras entidades, apenas value objects. Isso pq se existir uma entidade dentro do aggregate root que é root em outro agregado, não teria como garantir todas as invariantes dos dois agregados em conjunto. Então um dos aggregate roots teria que ser “desligado”? Enfim, parece complicado usar composição nesse caso.

De onde você tirou essa informação? Simplesmente, não corresponde à realidade do mercado. Eu tenho conhecimento direto de dezenas de sistemas bancários feitos em Java, incluindo conta corrente, análise de risco, internet banking. Em telecom, conheço plataformas de OSS e BSS, Billing, Charging e Inventário feitas em Java e/ou C++.

Confesso que nunca encontrei em campo um sistema feito todo em Lisp, Erlang ou afins. E olha que eu trabalhei na empresa que você citou (mas errou o nome).

Na verdade, a maior parte das plataformas complexas envolve mais de uma linguagem…

Você está falando sem ter a experiência real. Saia para o mundo e olhe a verdade.

Não faz sentido a mesma Entidade ser parte de dois Aggregate Roots. Seria um design errado.

Conhece dezenas mas não pode citar um grande nome da OO?

Só 1 vamos lá, vc consegue.

Felizmente isso não é um problema no modelo relacional ou funcional, por isso as pessoas criam esses paradigmas, pra rodar sistemas criticos, e OO para criar apps pra iPhone e Android.

Você não sabe nem escrever Ericsson.

O “grande nome” do paradigma funcional que você citou usa programação funcional em domínios extremamente específicos. Então, de acordo com esse critério, podemos citar como “grandes nomes da OO”: IBM, Oracle, Xerox, Microsoft, Siemens, Apple, Google e dezenas de outras empresas que usam ou usaram Java, C++, Python, Objective-C, …

Sua pergunta sequer faz sentido, porque grandes empresas não se desenvolvem em torno de paradigmas de programação.

Você espalha desinformação nesse fórum com muita convicção.

Eu não disse que era usada pra tudo, apenas em sistemas críticos. Pelo visto você esta com dificuldade de assimilar isso por algum motivo?

IBM e Oracle não usa OO no seu banco de dados relacional.

Para programadores criarem app front-end, como já falei, não tem coisa melhor do que OO. Nesse sentido, Microsoft Apple e Google usarem OO é uma coisa boa. Interessante Go não é OO…

Siemens, Xerox não sei nada sobre envolvimento com OO, poderia ser mais específico?

Não, cara. A Ericsson usa Erlang onde ela precisa de “soft” real time. Erlang não é adequada para sistemas hard real time e safety-critical.

Para uma operadora de telecom, o sistema de Billing é crítico, porque se faturar errado, você é processado ou não entra grana. Existem vários sistemas de billing feitos em C++ com Java. A Ericsson vende um desses.

Go não é OO, nem é funcional, nem força a imutabilidade. Go é um C modernizado, projetado por um cara que trabalhou com os criadores de C.

A Siemens usa OO em sistemas de automação industrial. A Xerox patrocinou o grupo que inventou o conceito de OO.

Eu não tenho idéia onde vc quer chegar. A Ericsson usa Erlang pra chutar o traseiro da concorrência no mercado de soft real time, e é isso que importa.

Não é crítico para a Ericsson, por isso é em OO.

Poderia simplesmente ter dito que não tem sistemas criticos em OO, só relacional, funcional e estruturado.

Links?

A Xerox patrocinou o grupo que inventou o conceito de OO.

Você quer dizer o conceito de GUI (Graphical User Interfaces)?

O sentimento é recíproco. Você já respondeu a pergunta do tópico: Dados imutáveis são realmente necessários? Não. É possível construir software de qualidade em qualquer domínio (inclusive sistemas críticos) sem forçar a imutabilidade. Já foi feito e continua sendo feito. Não creio que haja nada mais interessante pra sair desse papo.

BOMBA! Alan Kay afirma que mutabilidade viola o espírito da POO…

doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.

Generally, we don’t want the programmer to be messing around with state, whether simulated or not.

But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP.

Pelo visto muita gente vai ter que re-aprender OO, né @esmiralha.

It is unfortunate that much of what is called “object-oriented programming” today is simply old style programming with fancier constructs. Many programs are loaded with “assignment-style” operations now done by more expensive attached procedures.

Acho que já pode trancar o tópico né, quem vai querer discutir com o cara que inventou o negócio?

Esse tópico tem que ser trancado porque você é incapaz de sustentar uma discussão em busca de esclarecimento. Você só quer convencer alguém de que você está certo.

Reduzir a mutabilidade é um princípio importante. Ninguém negou isso. O que eu neguei e nego é que a imutabilidade seja um pré requisito obrigatório para construir software de qualidade para qualquer domínio, inclusive em sistemas críticos. A única teoria que não pode ser refutada é a realidade.

ok, é apenas sua opinião, e podia ter dito 16 posts atras. agora que o inventor da OO respondeu a pergunta do tópico, não é muito relevante.

…ou vc tb quer argumentar com o inventor da oo???

Ainda essa discussão? risos
Você pode mostrar um exemplo claro onde a mutabilidade num sistema crítico poderia ser um problema? Deixe-me reformular: pode explicar claramente por quê apenas imutabilidade funciona em sistemas críticos? Acha que nunca vai ser preciso mutabilidade em tais sistemas?

Óbvio que em termos de concorrência aplicar-se-ia imutabilidade, mas ainda dentro de um sistema crítico, podem existir cenários onde você precisa representar teus objetos com certa mutabilidade, pois fazer cópia excessiva de tudo poderia trazer problemas de performance.

Tem que ponderar. Em OO é possível programar com imutabilidade quando necessário. E em FP é possível programar com mutabilidade quando necessário.

Não, claro que não. Deixo ele mesmo te responder!
The basic idea (influenced by Sketchpad) is that most variables/values are in dynamic -relationships- with each other (maintained by the interior of the object), so being able to directly reset a value from the outside is dangerous. Because (in Smalltalk anyway) there is at least a setter method required, this allows the possibility of an outside setting action to be mediated by the internal method to maintain the desired interrelationships. But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP.
Ele está falando de manipular diretamente o estado interno de um objeto.
Molecagem não ler a resposta dele. Garoteou…

Se tiver não pertence a parte critica, o core, do sistema.

hum??? strings em Java são rápidas porque são imutáveis. rs

Que cópia excessiva esta falando. Poderia dar um exemplo?

Nao. Escolher não mudar uma estrutura mutável não oferece os mesmos benefícios de se trabalhar com estruturas imutáveis. Não da pra fazer cópia barata, não da pra confiar que não será acidentalmente modificado, compilador não consegue tirar proveito da imutabilidade, etc.

Você pode com certeza exigir que seus programadores ponderem. Mas como falei, e volto a repetir, isso raramente funciona na prática porque depende de disciplina e é ainda mais problemático no contexto de uma equipe, já que todos tem que estar ciente do problema o tempo todo. Nunca ouviu falar que a civizilização avança na medida que as pessoas podem fazer mais coisas, sem precisar pensar?

Você acabou de descobrir que tem feito errado todo esse tempo (se é que vc programa, ainda não estou convencido) e eu garotei?

O segundo paragrafo você esqueceu? Onde ele diz que só a história do objeto muda?

an object is only visible when it is stable and no longer computing

Você sabe o que stable significa né?

Significa que o objeto não pode estar acessível enquanto está em um estado inconsistente. Se uma operação exige a alteração do estado do objeto e essa alteração não é atômica, o objeto não pode estar visível até que essa operação seja concluída. Isso pode ser implementado através de locks (2PL que ele mesmo menciona). Ou através da criação de uma sequência de versões que representa o timeline desse objeto. Os dois mecanismos tem suas vantagens e desvantagens. Não é preto ou branco como você quer pintar.
Você cospe bobagens como “se tem mutabilidade não pertence ao core do sistema”. Isso é uma baboseira, é um bullshit do caramba.

Se for algo não crítico ou que não precisar escalar, eu uso locks.

Para todas as outras, a solucao imutavel é a melhor.

Estava me referindo a FP. Um programa funcional é modelado como uma cebola, com o centro imutável.