Programaçao Orientada a Objetos: um outro olhar
comentada em 23/10/2019 22:19

hahahaha é exatamente assim!

Existem outras formas de pensar o projeto sim:

divisão por módulos ao invés de objetos (ex. Go) ou dividir em módulos e objetos (a maioria das linguagens suporta)

programação funcional.

Também é por esse motivo que se utiliza o conceito de divisão por camadas bem definidas.

Ainda temos a divisão em microsserviços 

injeção de dependências...

Tem várias formas de deixar a coisa menos caótica.

bom sobre o tema eu recomendo um livro 'Practical Object Oriented Design in Ruby' e por que livro de ruby? Primeiro por que eu uso ruby a muito tempo e estou seguro em dizer que esse livro é ótimo para se entender as vantagens e desvantagens da OOP bem como aplicar os principais conceitos de forma pratica, segundo porque ruby e de longe uma das linguagens mais próximas de smalltalk o que significa que ela implementa varios dos conceitos originais da OOP da maneira como foram idealizados.

E se quiser ir pro lado funcional da força procura sobre elixir que roda na VM do Erlang.

 

E aqui uma palestra sobre os principios SOLID e como fazer um codigo OOP que não pareça um spaguetti



Espero ter ajudado.

Lembrei de um texto que vi outra vez que compara programação funcional com programação orientada a objetos: Functional Programming? Don’t Even Bother, It’s a Silly Toy

OOP não é sobre a criação de taxonomia. Mas, sobre não ter memória/estado compartilhada(Dr. Alan Kay on the Meaning of "Object-Oriented Programming").

Daí, para resolver mudança de estado, você agrupa no mesmo lugar o estado e as funções que o manipulam.

Mais sobre como chegamos no OOP: The Forgotten History of OOP - JavaScript Scene - Medium

@ThiagoDV caraca por 2 segundos eu pensei que o texto era sério

É muito difícil criar testes para sistemas que não são OO. Aliás, os testes dão sentido à OO.

Só é pior quando utilizada de forma errada.

Muito programador se foca demais na linguagem, e esquece coisas como herança, polimorfismo e design patterns.

@gustavob qual seria a dificuldade em testar um codigo funcional ou mesmo estruturado?

 

E só comparar o resultado de uma função com o resultado esperado e ver se da um match.

Concordo. Não há nenhuma diferença entre testar um código estruturado e um orientado a objetos. 

Nao há nenhuma facilidade na OO que diga que deixa os testes melhores. 

O problema é que a grande maioria não testa nada, seja lá que paradigma for, que projeto for ou que linguagem foi escolhida 

@philipel me enganaram também huaeuae
E só agora eu vi que a pessoa que escreveu o texto do tópico foi a mesma que escreveu o texto que eu mandei

Li o texto agora. Excelente. Concordo com muita coisa. E como dito acima, já conhecia a opinião de quem escreveu o texto em outro texto bem interessante.

Tendo mais pro lado de programação funcional do que pro lado de OOP. Acho as coisas mais intuitivas e organizadas. 

@gustavob a frase "É muito difícil criar testes para sistemas que não são OO."

Me parece um pouco exagerada. Mais sobre isso a frente.

 

@philipel, @FlyCavok a única coisa que *realmente* complica teste automatizado é estado compartilhado. E, enquanto código estruturado tem o hábito de usar variável global. De um código OO tem-se a expectativa de que não o faça.

@Tiago41 interessante como esse texto está me lembrando de um do Joe Armstrong, criador do ERLang, criticando OOP: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm

 

 

Mais interessante ainda, o próprio Alan Kay pensar no Actor Model do Carl Hewitt serem idéias muito semelhantes. No sentido de terem o mesmo ideal: esconder estado e late biding(não sei traduzir, tá relacionado com o código só ter acesso ao local dos métodos em tempo de execução, diferente de um C da vida onde vc tem a "posição de memória no arquivo executável").

What is the difference between Alan Kay's definition of OOP and Carl Hewitt's Actor Model? - Quora

 

Qual a relação de Actor Model com ERLang? Bom, o Actor Model tem uma "forte influência" em ERLang: Is Erlang really an actor model language? - Software Engineering Stack Exchange

Pra que testar, faz certo da primeira vez !

Vi em algumas das críticas ao OOP a questão de "Mutable States" e que seria melhor criar o objeto com todos os dados de uma só vez (através do construtor) e eliminando Setters, assim teríamos a OOP original: objetos com estados imutáveis
Nesse caso, criaríamos sempre novos objetos para representar diferentes estados.
Mas acho talvez que essa ideia não é totalmente aplicável: se estamos trabalhando com um procedimento para servir de base para armazenar dados, usar uma classe para ser a ponte para a fonte de dados requeriria um construtor com muitos parâmetros, em vez de vários Setters. Já ouvi muitas vezes falarem que o construtor não deve ter muitos parâmetros... (Não sei se com fundamento)

A pergunta que me vem a cabeça é: até que ponto usar "Estados Imutáveis" e até que ponto pode se usar "Estados Mutáveis"?

@Tiago41 tu tá confundindo estado mutável com esquizofrenia de Java com get e set.

A OOP original, que estou assumindo que se refere a cunhada por Alan Kay, é implementada na linguagem Smalltalk. Nela o estado é mutável. Mas, preferencialmente, escondido do mundo dentro do objeto.
A preocupação, nesse caso, são os problemas causados por variável global.

ERlang implementa o "paradigma de programação" chamado ActorModel. Que, como citei mais acima, é bem semelhante a uma linguagem OOP com estado imutável. Uma das vantagens de imutabilidade é paralelismo.

Sobre a questão de Construtor com muito parâmetro só é problema em linguagem que não te permite dar nome aos parâmetros. Fazendo com que você dependa da ordem em que passa eles. Daí, vale mais a pena passar um Map/Set/Hash/Dict(uma lista cujo índice não seja um número, mas uma string) da vida com os parâmetros.


Sobre até que ponto usar, depende do teu problema e a ferramenta que usa para lidar com ele.

Para construção sistemas de informação, seguir a máxima de: "baixo acoplamento e alta coesão" já resolve uma boa parte dos teus problemas.