Programação funcional versus programação orientada a objetos [fechado

Question

Eu fui exposto principalmente à programação OO até agora e estou ansioso para aprender uma linguagem funcional. Minhas perguntas são:

• Quando você escolhe a programação funcional em vez de orientada a objetos?
• Quais são as definições de problemas típicas em que a programação funcional é uma escolha melhor?

Answer 1

Quando você escolhe a programação funcional em vez de orientada a objeto?

Quando você antecipa um tipo diferente de evolução do software:

• As línguas orientadas a objetos são boas quando você tem um conjunto fixo de operações sobre coisas, e à medida que seu código evolui, você adiciona principalmente coisas novas. Isso pode ser realizado adicionando novas classes que implementam métodos existentes, e as classes existentes são deixadas sozinhas.

• As linguagens funcionais são boas quando você tem um conjunto fixo de coisas, e à medida que seu código evolui, você adiciona principalmente novo operações nas coisas existentes. Isso pode ser realizado adicionando novas funções que computam com os tipos de dados existentes e as funções existentes são deixadas sozinhas.

Quando a evolução dá o caminho errado, você tem problemas:

• Adicionar uma nova operação a um programa orientado a objetos pode exigir a edição de muitas definições de classe para adicionar um novo método.

• Adicionar um novo tipo de coisa a um programa funcional pode exigir editar muitas definições de função para adicionar um novo caso.

Esse problema tem sido bem conhecido há muitos anos; em 1998, Phil Wadler o apelidou de "problema de expressão". Embora alguns pesquisadores pensem que o problema de expressão pode ser resolvido com os recursos de idioma como Mixins, uma solução amplamente aceita ainda não atingiu o mainstream.

Quais são as definições de problemas típicas em que a programação funcional é uma escolha melhor?

As linguagens funcionais se destacam em manipular dados simbólicos em forma de árvore. Um exemplo favorito são os compiladores, onde as linguagens de origem e intermediárias mudam raramente (principalmente a mesma coisas), mas os escritores do compilador estão sempre adicionando novas traduções e melhorias ou otimizações de código (novas operações nas coisas). A compilação e a tradução geralmente são "aplicativos assassinos" para idiomas funcionais.

Answer 2

Você não precisa necessariamente escolher entre os dois paradigmas. Você pode escrever software com uma arquitetura OO usando muitos conceitos funcionais. FP e OOP são de natureza ortogonal.

Tomemos, por exemplo, C#. Você poderia dizer que é principalmente OOP, mas existem muitos conceitos e construções de FP. Se você considera Linq, as construções mais importantes que permitem que o LINQ exista são de natureza funcional: Expressões Lambda.

Outro exemplo, f#. Você poderia dizer que é principalmente FP, mas existem muitos conceitos e construções de OOP disponíveis. Você pode definir classes, classes abstratas, interfaces, lidar com a herança. Você pode até usar a mutabilidade quando torna seu código mais claro ou quando aumenta drasticamente o desempenho.

Muitas línguas modernas são multi-paradigma.

Leituras recomendadas

Como estou no mesmo barco (OOP Background, Learning FP), sugiro algumas leituras que eu realmente apreciei:

• Programação funcional para o desenvolvimento diário .NET, por Jeremy Miller. Um ótimo artigo (embora mal formatado) mostrando muitas técnicas e exemplos práticos do mundo real de FP em C#.

• Programação funcional do mundo real, por Tomas Petricek. Um ótimo livro que lida principalmente com conceitos de FP, tentando explicar o que são, quando devem ser usados. Existem muitos exemplos em F# e C#. Também, Blog de Petricek é uma ótima fonte de informação.

Answer 3

As ofertas de programação orientada a objetos:

1. Encapsulamento, para
   • Mutação de controle do estado interno
   • limitar o acoplamento à representação interna
2. Subtyping, permitindo:
   • Substituição de tipos compatíveis (polimorfismo)
   • Um meio bruto de compartilhar a implementação entre classes (herança de implementação)

A programação funcional, em Haskell ou mesmo em Scala, pode permitir a substituição por meio de mecanismo mais geral de classes de tipo. O estado interno mutável é desencorajado ou proibido. O encapsulamento da representação interna também pode ser alcançado. Ver Haskell vs OOP Para uma boa comparação.

A afirmação de Norman de que "adicionar um novo tipo de coisa a um programa funcional pode exigir a edição de muitas definições de função para adicionar um novo caso". Depende de quão bem o código funcional empregou classes de tipo. Se a correspondência de padrões em um tipo de dados abstrato específico for espalhado por uma base de código, você realmente sofrerá com esse problema, mas talvez seja um design ruim para começar.

EDITADO Removido referência a conversões implícitas ao discutir as classes de tipo. Em Scala, as classes de tipo são codificadas com parâmetros implícitos, não as conversões, embora as conversões implícitas sejam outro meio de obter substituição de tipos compatíveis.

Answer 4

1. Se você está em um ambiente fortemente simultâneo, a programação funcional pura é útil. A falta de estado mutável torna a simultaneidade quase trivial. Veja Erlang.

2. Em um idioma multiparadigma, convém modelar algumas coisas funcionalmente se a existência de estado mutável for um detalhe de implementação e, portanto, o FP é um bom modelo para o domínio do problema. Por exemplo, consulte as compreensões da lista em Python ou std.Range na linguagem de programação D. Estes são inspirados na programação funcional.