State: you’re doing it wrong
I’m completely convinced that mutable objects and the whole approach that is sort of implied by the design of Java, C#, Python, all the languages that followed along this path, is very much the wrong way to do most things… it is ok to do somethings, but it’s the wrong way to do most things.
Mutable objects are the new spaghetti code, and by that I mean that you eventually, with mutable objects, create an intractable mess, and encapsulation does not get rid off that, encapsulation just means: well, I’m in charge of this mess. But the real mess comes from this network you create of objects that can change, and your inability to look at the state of a system and understand how you got there, how to get there to test it next time… so it’s hard to understand the program… it’s very hard to test it. I think that’s interesting in telling all the emphasis on test driven design. I think people are driven to this because they know their systems are completely intractable…
Rich Hickey - Screencast: Clojure Concurrency (”transcrição” do minuto 21 ao 23)
| Enviar por e-mail | Hits para esta publicação: 2147
3 respostas para “ State: you’re doing it wrong ”
Deixe uma resposta.
[…] Classes imutáveis possuem uma série de vantagens: fáceis de manter, não possuem efeitos colaterais e acima de tudo são thread safe. Uma classe deve ser imutável a não ser que você tenha muito bons motivos para isso. Mesmo se não for possível tornar sua classe imutável, minimize a quantidade de métodos que alteram o estado do objeto. Um objeto previsível é muito mais simples de manter. Joshua Bloch cita String, BigInteger e diz que java.util.Date e java.awt.Point deveriam ter sido criadas imutáveis! Muitas APIs novas abusam da imutabilidade, como a Joda Time, classes wrapper, Money and Time do Eric Evans, etc. Aliás, é com o slogan da imutabilidade que linguagens como clojure e erlang tem chamado tanta atenção. Leia também essa citação no blog do Renato Lucindo. […]
[…] Classes imutáveis possuem uma série de vantagens: fáceis de manter, não possuem efeitos colaterais e acima de tudo são thread safe. Uma classe deve ser imutável a não ser que você tenha muito bons motivos para isso. Mesmo se não for possível tornar sua classe imutável, minimize a quantidade de métodos que alteram o estado do objeto. Um objeto previsível é muito mais simples de manter. Joshua Bloch cita String, BigInteger e diz que java.util.Date e java.awt.Point deveriam ter sido criadas imutáveis! Muitas APIs novas abusam da imutabilidade, como a Joda Time, classes wrapper, Money and Time do Eric Evans, etc. Aliás, é com o slogan da imutabilidade que linguagens como clojure e erlang tem chamado tanta atenção. Leia também essa citação no blog do Renato Lucindo. […]
[…] Em linguagens como Erlang, onde as “variavéis” são imutáveis, não existem efeitos colaterais ao se executar uma função, portanto podemos dizer que a “memória compartilhada” não sofre dos males das outras linguagens, já que não há estado que possa ser alterado. Muitos dizem que o grande problema das linguagens atuais é justo o estado. […]