Elementos de estrutura em um programa funcional

5

No objeto orientado, temos requisitos, casos de uso e UML, que podem formar um bom quadro conceitual. O objetivo aí é definir objetos, suas responsabilidades, comportamentos e comunicações entre eles.

Qual seria o equivalente no mundo da programação funcional de objetos / responsabilidades, comportamentos e comunicação para definir uma alta visualização da estrutura do nosso programa?

    
por Benj 03.07.2016 / 10:24
fonte

1 resposta

7

Não tenho certeza se isso vai satisfazer totalmente sua pergunta, mas esperamos que se aproxime.

Requisitos / casos de uso / especificações funcionais / o que você quiser chamar ainda são ótimas ferramentas para comunicar um projeto de programa FP. Mas um modelo de design visual para programas FP é um pouco menos interessante. Isso equivale a definir entradas e saídas para cada caso de uso e uma função mapeando a entrada para a saída. Chato certo? Ok, alguma explicação ...

Responsabilidades diferem

Uma classe OO geralmente é proprietária de três conceitos diferentes: estado atual dos dados (um conceito implícito), estrutura de dados (propriedades ou getters) e comportamento nos dados (métodos).

FP - como em: programação com funções puras - geralmente só lida com 2 dessas coisas. Estrutura e Comportamento. O estado atual é empurrado para a borda do sistema como uma preocupação de persistência. Por exemplo, um módulo responsável pelo Produto saberia quais propriedades ele tinha (estrutura) e quais operações você poderia executar (comportamento). Mas você precisa informar às operações o estado atual de um Produto antes que ele possa executar a operação. Em seguida, ele retornará uma nova cópia do Produto com as alterações aplicadas.

Você poderia modelar isso em UML como uma classe com apenas métodos estáticos para comportamento. E uma classe de dados em que todas as propriedades são somente leitura para estrutura. A classe de dados seria usada como parte da entrada / saída nos métodos de comportamento. Mas conectá-los a outros módulos é onde o design do tipo UML seria quebrado, porque ...

Organização difere

Com o OO, muitas vezes você tem muitas classes interconectadas se comunicando umas com as outras. Cada um deles possui uma parte do estado que o sistema precisa operar. Mas, com o FP, os módulos como o Produto descrito acima são geralmente autônomos e independentes, já que não possuem estado. Eles estão "conectados" apenas naquelas funções de nível superior (isto é, funções de caso de uso como placeOrder ) chamarão as funções mais especializadas (como Order.validate e Product.canBeOrdered ) para ajudar a converter a entrada em um valor de retorno. / p>

É aqui que ferramentas como UML são classificadas como FP porque elas são essencialmente modelar gráficos de estado, mas programas funcionais são mais semelhantes a hierarquias de chamada de função. Uma maneira provavelmente mais útil de modelar programas funcionais é com diagramas de fluxo de dados, como mencionado nos comentários de esta questão . Você também pode usar um fluxograma aninhado, em que cada etapa de decisão possui seu próprio fluxograma para descrever seu fluxo interno.

Eu diria que modelar as funções especializadas é uma perda de tempo. Geralmente, elas são pequenas e as funções puras são fáceis de refatorar, para que possam ser atualizadas com frequência. Você pode ter muita rotatividade na atualização do seu modelo de design se descer para esse nível. Provavelmente, o nível mais baixo para o qual você deseja criar um modelo de design são as funções de casos de uso.

No entanto, eu não observei modelos de design de programas como prática comum em FP (não que a UML seja comum ... nunca a usei profissionalmente). A extensão da maioria dos métodos de projeto de FP que vi são apenas definir assinaturas de funções de cima para baixo no código. Então, ao preencher a implementação, crie assinaturas fn para as funções mais especializadas. Organize-os em módulos e, em seguida, comece a trabalhar em suas implementações. Apenas continue seguindo esse processo recursivo até atingir as tartarugas.

Edges

As bordas de um sistema são onde as coisas começam a ficar mais compatíveis com UML. Já que os programas precisam, de fato, saber o estado atual para serem úteis. É aí que você conecta as várias tecnologias, como bancos de dados, chamadas de API externas, etc. Esse design no nível do sistema é o único tipo de diagrama que eu já fiz.

Caso contrário, definir casos de uso com suas entradas e saídas (visualmente, se desejar) é o nível no qual você faria um modelo de design de um programa funcional. Defina estrutura de entrada, estrutura de saída e uma função que mapeie a entrada para a saída.

    
por 12.05.2017 / 23:22
fonte