OOP vs Programação Funcional vs Processual [fechado]

Question

Quais são as diferenças entre esses paradigmas de programação, e eles são mais adequados para problemas específicos ou fazer quaisquer casos de uso favorecer um sobre os outros?

exemplos Arquitetura apreciada!

Answer 1

Todos eles são bons em suas próprias maneiras - Eles são abordagens simplesmente diferentes para os mesmos problemas

.

Em um estilo puramente processual, dados tende a ser altamente dissociado das funções que operam nele.

Num modelo orientada a objectos, dados tende a levar com ele um conjunto de funções.

Num modelo funcional, dados e funções tendem para ter mais em comum umas com as outras (como em Lisp e Esquema), oferecendo maior flexibilidade em termos de como funções que são realmente utilizados. Algoritmos tendem também a ser definido em termos de recursividade e composição, em vez de laços e iteração.

Claro, a linguagem em si só influencia qual estilo é o preferido

. Mesmo em uma linguagem pura funcional como Haskell, você pode escrever em um estilo processual (embora isso é altamente desencorajado), e até mesmo em uma linguagem procedural, como C, você pode programar em um estilo orientado a objetos (como no GTK + e EFL APIs).

Para ser claro, a "vantagem" de cada paradigma é simplesmente na modelagem de seus algoritmos e estruturas de dados. Se, por exemplo, o algoritmo envolve listas e árvores, um algoritmo funcional pode ser a mais sensata. Ou, se, por exemplo, seus dados são altamente estruturado, pode fazer mais sentido para compô-lo como objetos se for esse o paradigma nativo de seu idioma - ou, ele poderia facilmente ser escrito como uma abstração funcional de mônadas, que é o paradigma nativa de linguagens como Haskell ou ML.

A escolha de qual você usa é simplesmente o que faz mais sentido para o seu projeto e as abstrações seus suportes de linguagem.

Answer 2

Eu acho que as bibliotecas disponíveis, ferramentas, exemplos e comunidades supera completamente o paradigma estes dias. Por exemplo, ML (ou qualquer outro) pode ser a programação para todos os fins final idioma , mas se você não pode obter quaisquer boas bibliotecas para o que você está fazendo, você está ferrado.

Por exemplo, se você estiver fazendo um jogo de vídeo, existem mais exemplos bons de código e SDKs em C ++, então você é provavelmente melhor fora com isso. Para uma aplicação web pequena, existem alguns grandes estruturas Python, PHP e Ruby que vai levá-lo fora e correndo muito rapidamente. Java é uma excelente escolha para projetos maiores por causa das correntes e empresariais bibliotecas e plataformas de tempo de compilação.

Ela costumava ser o caso de que as bibliotecas padrão para diferentes idiomas foram belos pequenos e facilmente replicado - C, C ++, Assembler, ML, LISP, etc .. veio com o básico, mas tendem a sair de frango quando se tratava de padronização de coisas como as comunicações de rede, criptografia, gráficos, formatos de arquivo de dados (incluindo XML), até mesmo estruturas de dados básicos, como árvores equilibradas e hashtables foram deixados de fora!

línguas modernas, como Python, PHP, Ruby e Java já vêm com uma biblioteca padrão muito mais decente e tem muitas boas bibliotecas de terceiros que você pode facilmente usar, graças em grande parte à sua adoção de namespaces para manter bibliotecas de colidir com um ao outro, e coleta de lixo para padronizar os sistemas de bibliotecas de gerenciamento de memória.

Answer 3

Esses paradigmas não tem que ser mutuamente exclusivos. Se você olhar para python, ele suporta funções e classes, mas, ao mesmo tempo, tudo é um objeto, incluindo funções. Você pode misturar e combinar / oop / style processual funcional tudo em um pedaço de código.

O que quero dizer é, em linguagens funcionais (pelo menos em Haskell, o único que eu estudei) não existem declarações! funções só são permitidas uma expressão dentro deles !! MAS, funções são cidadãos de primeira classe, você pode passá-los em torno de como parâmetros, junto com um monte de outras habilidades. Eles podem fazer coisas poderosas com poucas linhas de código.

Enquanto em uma linguagem procedural, como C, a única maneira que você pode passar funções redor é usando ponteiros de função, e que por si só não permite muitas tarefas poderosos.

Em Python, uma função é um cidadão de primeira classe, mas pode conter número arbitrário de declarações. Então você pode ter uma função que contém o código de procedimento, mas você pode passá-lo em torno de como linguagens funcionais.

O mesmo vale para OOP. A linguagem como Java não permite que você para escrever procedimentos / funções fora de uma classe. A única maneira de passar uma função redor é envolvê-lo em um objeto que implementa essa função e, em seguida, passar esse objeto ao redor.

Em Python, você não tem essa restrição.

Answer 4

Para GUI eu diria que o Paradigma Orientado a Objetos é muito bem adaptado. A janela é um objeto, as caixas de texto são objetos, e Ok-Button é um também. Por outro material mão como processamento de cadeia pode ser feito com muito menos sobrecarga e, portanto, mais simples, com paradigma processual simples.

Eu não acho que é uma questão da língua nenhuma. Você pode escrever funcional, processual ou em quase qualquer linguagem popular orientada a objetos, embora possa haver algum esforço adicional em alguns.

Answer 5

A fim de responder à sua pergunta, precisamos de dois elementos:

1. A compreensão das características dos diferentes arquitetura estilos / padrões.
2. A compreensão das características dos diferentes paradigmas de programação.

A lista de estilos de arquitetura de software / padrão é mostrada na software arquitetura artigo em Wikipeida. E você pode pesquisar sobre eles facilmente na web.

Em suma e geral, processual é bom para um modelo que segue um procedimento, OOP é bom para o projeto, e Funcional é bom para a programação de alto nível.

Eu acho que você deve tentar ler a história em cada paradigma e veja por que as pessoas criá-lo e você pode entendê-las facilmente.

Depois de entender os dois, você pode ligar os itens de arquitetura estilos / padrões de paradigmas de programação.

Answer 6

Eu acho que muitas vezes eles não são "versus", mas você pode combiná-los. Eu também acho que muitas vezes, as palavras que você menciona são apenas chavões. Há poucas pessoas que realmente sabem o que significa "orientadas a objetos", mesmo se eles são os evangelistas mais ferozes do mesmo.

Answer 7

Um dos meus amigos está escrevendo um gráfico aplicativo usando NVIDIA CUDA . ataques de aplicação em muito bem com OOP paradigma e o problema pode ser decomposto em módulos ordenadamente. No entanto, para usar CUDA você precisa usar C, que não suporta herança . Portanto, você precisa ser inteligente.

a) Você conceber um sistema inteligente que irá emular a herança até certo ponto. Isso pode ser feito!

i) Você pode usar um sistema de gancho, que espera que cada criança C do pai P ter uma certa substituição para a função F. Você pode fazer as crianças registrar suas substituições, que serão armazenados e chamados quando necessário.

ii) É possível usar struct .

Isto pode ser puro, mas não é fácil chegar a à prova de futuro, solução confiável. Você vai gastar muito tempo projetar o sistema e não há nenhuma garantia de que você não vai ter problemas no meio do caminho através do projeto. Implementação herança múltipla é ainda mais difícil, se não quase impossível.

b) Você pode usar a política de nomenclatura consistente e usar dividir e conquistar abordagem para criar uma programa. Não vai ter qualquer herança, mas porque suas funções são pequenos, fáceis de entender e consistentemente formatado você não precisa dele. A quantidade de código que você precisa escrever sobe, é muito difícil manter o foco e não sucumbir às soluções fáceis (hacks). No entanto, esta forma de codificação ninja é a forma C de codificação. Ficar em equilíbrio entre a liberdade de baixo nível e escrevendo código bom. Boa maneira de conseguir isso é escrever protótipos usando uma linguagem funcional. Por exemplo, Haskell é extremamente bom para prototipagem algoritmos.

Eu tendo para abordagem b. Eu escrevi uma possível solução usando a abordagem de um, e eu vou ser honesto, senti muito natural usando esse código.