Encapsulando partes móveis em OO vs Minimizando partes móveis em FP

5

Sou de origem OO e comecei a aprender o paradigma de FP. Entrou em quote por Michael Feathers - " OO torna o código compreensível encapsulando partes móveis. O FP torna o código compreensível minimizando partes móveis "

O que exatamente ele quis dizer com " moving parts "? Meu palpite é que, ao mover partes, ele quis dizer " state mutation " porque FP promove immutability e minimiza a mutação de estado, enquanto OO não desencoraja a mutação de estado, mas encapsula dados (encapsulando assim o estado mutante do objeto)

Eu posso sentir como funções puras em FP promovendo imutabilidade e sem efeitos colaterais podem resultar em melhor clareza de código, tornando-o mais compreensível e mais declarativo vs imperativo. De alguma forma, benefícios de natureza semelhante não são muito aparentes para mim em OO quando o estado de mutação é encapsulado.

Por exemplo abaixo, o objeto adaptador é acessado somente por meio de interfaces públicas, mas ainda sinto que seu estado não é encapsulado, pois cada etapa assume uma transição de estado de classificação na etapa anterior e, portanto, o método de execução parece imperativo.

void Execute(IdataAdapter adapter) {
  adapter.ReadFromSource();
  adapter.ProcessData();
  adapter.WriteToDestination();
}

A definição OO em torno de encapsulamentos fala principalmente sobre a ocultação de dados e vantagens que temos como alterar a estrutura de dados internos sem quebrar clientes etc. Mas eu gostaria de entender melhor no contexto da declaração acima feita por Michael Feathers. A minha pergunta é basicamente - Ao encapsular o estado de mutação no OO torna o código compreensível da mesma forma que o FP, minimizando a mutação de estado?

    
por Rahul Agarwal 03.12.2018 / 15:25
fonte

2 respostas

5

Sim, ambos são abordagens para um problema comum.

Programas de software necessariamente têm muitas partes para passar de “Eu tenho um site que compartilha vídeos de gatos!” (ou o que for) para “Eu posso fazer algumas operações em 1s e 0s!”. Porque, fundamentalmente, todo programa acaba como algumas operações básicas em 1s e 0s.

Se você não fornecer abstrações, se você não fornecer nenhuma estrutura aos seus programas, eles serão um grande e inescrutável conjunto de grandes manipulações. Programação Orientada a Objetos fornece abstração e estrutura via objetos. Programas funcionais fornecem abstração e estrutura por meio de funções. E, claro, cada um tende a ter um pouco do outro, bem como alguma programação imperativa para uma boa medida.

Mas a motivação subjacente é a mesma.

    
por 03.12.2018 / 16:44
fonte
1

Somehow benefits of similar nature is not very apparent to me in OO when mutating state is encapsulated.

Depois de fazer o comentário acima, você mostra o código onde o estado é decididamente não encapsulado. Claro que você não vê os benefícios nesse caso.

Em código OO bem escrito, você verá que os métodos de classes são mais sobre como contar a um objeto o que aconteceu, em vez de dizer o que fazer, ( viewDidLoad , buttonTapped , serverRespondedWith , etc.)

No exemplo que você mostra, sua função informa explicitamente ao adaptador o que fazer e, mais importante, a classe que está usando o adaptador deve saber o estado do adaptador para chamar os métodos sem erro (mesmo que não verifique explicitamente o estado).

    
por 24.12.2018 / 18:40
fonte