O que você faria se seu cliente exigisse que você não usasse programação orientada a objetos?

31

Estou escrevendo um programa para simular a atividade de formigas em uma grade (PDF). A formiga pode se mover, pegar e largar coisas.

O problema é que enquanto a ação das formigas e as posições de cada formiga podem ser rastreadas pelos atributos de classe facilmente (e podemos facilmente criar muitas instâncias de tais formigas), meu cliente disse que, como ele tem experiência em programação funcional, ele gostaria que simulação a ser feita usando programação funcional.

Para ser claro, as palavras originais do cliente são apenas "sem classe", mas não "programação funcional". Então, suponho que ele não se refira à programação funcional e posso fazê-lo imperativamente. Além disso, não tenho experiência anterior em programação funcional.

No entanto, acho que é benéfico focar nesta questão particularmente sobre um requisito de programação funcional do que simplesmente "fazê-lo imperativamente".

Como você lidaria com essa situação? Você tentaria persuadir seu cliente de que o uso de programação orientada a objetos é muito mais limpo, tentaria seguir o que ele exigia e fornecer a ele código de baixa qualidade ou fazer outra coisa?

usuário
fonte
9
Uma coisa que pode mudar de idéia é se o custo de você fazer isso é maior (se você é mais experiente em linguagens OO do que em uma linguagem de programação funcional).
quer
Pode ser interessante comparar o código de simulação de formigas de Rich Hickey ( gist.github.com/1093917 ) - no Clojure tão basicamente funcional, embora a simulação tenha sido projetada principalmente para demonstrar o uso do STM.
Mikera
13
Comentaristas: não deixe uma resposta aqui nos comentários. Escreva sua própria resposta. Os comentários não são um local para discutir várias respostas possíveis para a pergunta: faça a sua sugestão como resposta ou use -a para conversar primeiro.
6
Apenas querendo ter certeza de que você viu o ponto do N3dst4 de que "programação funcional" é uma disciplina de programação específica. A programação que não é orientada a objetos é geralmente descrita como "programação procedural".
DJClayworth
1
Por que você acha que a implementação orientada a objetos seria "muito mais limpa"? Muito provavelmente, será muito menos legível do que uma solução funcional adequada.
SK-logic

Respostas:

201

O código orientado a objetos não é, por definição, mais limpo, e, por outro lado, o código não OO não é, por definição, ruim. Embora pareça haver um mapeamento orientado a objetos bastante óbvio para esse problema em particular, sugiro que você tente a abordagem de programação funcional de qualquer maneira. Dê o melhor de si, tente resolver o problema com o melhor estilo de programação funcional possível, e você pode aprender algo que não esperava.

Joris Timmermans
fonte
83
+1 em "você pode aprender algo que não esperava"!
Kenneth
2
Além disso, a programação orientada a dados permite excelentes desempenhos, pois é amigável ao cache e é melhor implementada em conjuntos de funções que processam blocos de dados. Parece perfeito para o problema em que você está trabalhando. Não sei como isso se aplica à programação funcional, mas acho que ajuda mais do que dói.
Klaim 29/11
8
+1 para "você pode apenas aprender algo que não esperava" !, MAS: Se o OP não tiver muita experiência em programação funcional e o cliente esperar uma solução boa e barata, seria bastante arriscado mergulhar em um nova maneira de resolver problemas.
mort
3
@ mort - O cliente, neste caso, quer algo específico, parece que sabe o suficiente para realmente saber o que quer, por isso, se a pessoa que contratou não puder fazê-lo, isso é problema deles. Eu acho que o que estou dizendo é o fato de o cliente querer algo "bom e barato" e dizer que contratou a pessoa errada que não pode fornecer isso, a culpa é do cliente, não a culpa do autor, ele não sabe como fornecer um serviço barato e boa solução de programação funcional para esse problema. Um deles vale a pena o autor tentar fornecer o que o cliente deseja, pois não há razão técnica para não fazê-lo.
Ramhound 29/11
2
Em nenhum lugar da questão o OP disse as palavras "bom e barato". O desejo pode ser "Rápido e bom" (dos três: rápido, bom e barato). Tudo isso é irrelevante, sem orientação do OP, pois as "Especificações" dizem "Usar programação funcional".
WernerCD
68

Você menciona que o cliente costumava programar em uma linguagem funcional; talvez ele tenha um motivo para exigir que você escreva o código em um estilo funcional. Você deveria perguntar a ele o porquê .

Talvez ele pretenda manter o código e mantê-lo depois.

Além disso, não acho que as duas opções sejam : estilo OO ou escrever código de baixa qualidade como você mencionou. Certamente, escrever código funcional em um exemplo como esse poderia ser mais difícil, especialmente se você tiver apenas experiência em linguagens orientadas a objetos, mas se o cliente estiver disposto a esperar um pouco mais para que você se familiarize com o estilo funcional, isso não aconteceria ' não dói perguntar isso a ele.

Eu perguntava a ele por que ele quer o código em estilo funcional e, se o tempo não é um problema, eu pediria alguns dias a mais para acelerar a programação funcional. (viva para ser pago para aprender!)

Se tudo mais falhar, explique que levaria muito menos tempo para fazê-lo no estilo OO.

Thanos Papathanasiou
fonte
@downvoter você daria algum feedback?
Thanos Papathanasiou
3
Eu entendo que a tl; pena notação dr um downvote, até certo
Independent
1
Existe algo nas perguntas frequentes ou nas páginas de ajuda em qualquer lugar que exprimam o uso de "tl; dr"? Ou são apenas alguns usuários desonestos que não gostam? Parece-me que adicionar um resumo sucinto de uma resposta só pode ser uma coisa boa, então não consigo imaginar por que isso seria considerado digno de um voto negativo.
Ben Lee
1
@Bratch Eu pensei que a notação tl; dr era para o usuário tentando ler minha resposta. Significando que, mesmo se você pular todo o resto, se você acabou de ler isso, terá a essência da resposta. O que você quer dizer com o que você está dizendo?
Thanos Papathanasiou
1
Alguns de nós idosos não têm idéia do que tl; dr meios (eu fiz procurá-lo, mas por que usaria qualquer um tal absurdo enigmática?)
HLGEM
55

Você está ciente de que programação funcional não significa apenas "programação sem classes"?

Veja o artigo da Wikipedia sobre o assunto para obter mais informações, mas em suma ...

Na ciência da computação, a programação funcional é um paradigma de programação que trata a computação como a avaliação de funções matemáticas e evita dados de estado e mutáveis. Ele enfatiza a aplicação de funções, em contraste com o estilo de programação imperativo, que enfatiza as mudanças de estado.

A programação funcional é um paradigma de programação, assim como o OO é um paradigma de programação.

Se você tem experiência em OO, posso ver como você deseja que todas as suas formigas sejam objetos. Por outro lado, se você estiver simulando um formigueiro com milhões de formigas, o OO e a passagem de mensagens podem se tornar ineficientes.

Felizmente para você, o Python possui excelentes ferramentas para programação funcional (a mais importante é que as funções são objetos de primeira classe).

HOWTO de programação funcional em Python

N3dst4
fonte
+1 por comentar isso. Realmente deve ser esclarecido na pergunta.
Bratch
Você sabia que pode ter idiomas OO e funcionais? Esses são dois princípios organizadores que na verdade são amplamente ortogonais entre si. É certo que muitas linguagens OO também são linguagens imperativas estruturadas, mas não há base teórica para acoplá-las fortemente.
Donal Fellows
@DonalFellows Absolutamente, é um bom argumento que os dois não sejam mutuamente exclusivos. O Python (porque a pergunta foi originalmente marcada como Python) é imperativo, orientado a objetos e funcional, dependendo de onde você está quando olha para ele. Em outras partes desta página, alguém menciona o OCaml, que é OO e funcional.
N3dst4
22

Explique ao seu cliente que, se ele quiser programação funcional, ele deve contratar alguém especializado nisso. A programação funcional é muito diferente da OOP, e você se enganará se achar que pode buscá-la facilmente e fornecer uma solução complexa de alta qualidade.

KaptajnKold
fonte
Aceita. É apenas senso comum aplicado.
Mister Smith
1
O problema é que, do ponto de vista comercial, nem sempre é fácil admitir sua falta de conhecimento para o cliente ("Você deve contratar alguém familiarizado com programação funcional"). É mais fácil afirmar que OOP é melhor, simplesmente porque você está familiarizado com isso. Menos honesto , mas mais fácil.
Andres F.
@ André F: Lidar com uma nova linguagem (e paradigma) não é nada fácil. Cedo ou tarde, o cliente precisa reconsiderar o problema. Melhor logo que depois.
Mister Smith
4
@ Smith Smith: concordo plenamente com você. Só estou dizendo que esse tipo de honestidade do provedor (ou seja, do programador) nem sempre é iminente. Essencialmente, você está dizendo ao cliente para contratar outra pessoa, o que faz todo o sentido no mundo, mas, no entanto, é doloroso.
Andrés F.
13

Existe um equívoco comum de que "OO" é completamente contrário a "funcional". Essas coisas podem andar de mãos dadas muito bem. No seu exemplo, acho que um "Ant" pode ser modelado, bem como um tipo de dados abstrato, que pode ser implementado diretamente usando classes e objetos. As transições entre "estados Ant" podem ser modeladas naturalmente usando funções, o que o levará a uma abordagem funcional, desde que a classe "Ant" seja do tipo imutável.

E lembre-se de que "objetos" podem ser trocados pelo conceito funcional de um fechamento, pois os objetos são os fechamentos do pobre homem são os objetos do pobre homem são os ... ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

Doc Brown
fonte
+1 Programação funcional e POO são conceitos ortogonais. Veja OCaml, Scala, Clojure, python para linguagens que podem lidar com ambos.
Rds
Esses dois links valem uma upvote sozinho ...
Wayne Werner
8

Depois de conversar com o cliente, se ele ainda quer do jeito dele, você faz um trabalho profissional ou, se não pode, não aceita o contrato ou encontra alguma maneira de sair dele.

Produzir "código de baixa qualidade" apenas porque você discorda seria altamente profissional.

Jaydee
fonte
8
  1. Por que todos estamos assumindo que o cliente sabe a diferença entre programação funcional e imperativa? Muitas pessoas não conhecem os nomes ou as especificidades dos paradigmas que não são de programação OO e trocam prontamente termos como "procedural" "imperativo" e "funcional".

  2. Não ande como os outros dizem para você andar, a menos que você acredite que deve andar dessa maneira. Portanto, se você não acredita que a programação funcional seja adequada, não se arrume a falhar ou assuma um projeto sem entusiasmo.

  3. Se o cliente escreve a especificação, em seguida, implementar a especificação, caso contrário você escrever a especificação e implementar o seu spec.

  4. A melhor estratégia para influenciar as decisões dos clientes é tornar a opção indesejável significativamente mais cara. Funciona sempre.

  5. Se você é o especialista (em relação ao cliente), deve ser capaz de persuadi-lo.

  6. Para realmente saber se o cliente tem um ponto válido, você precisa ganhar mais experiência com programação funcional, para que você possa derrubá-lo com confiança ou perceber que seu viés em relação ao OO é devido à sua inexperiência.

  7. Por que não fazer as duas coisas, deixe o cliente ver as duas implementações e decidir qual é mais fácil de manter. Apenas considere tudo isso nas estimativas do seu projeto para que você possa aproveitar a curva de aprendizado enquanto é pago.

Sam
fonte
+1 para "Por que todos estamos assumindo que o cliente sabe a diferença entre programação funcional e imperativa?". O cliente pode significar algo como "Eu não quero que seja repetitivo, então divida tudo em funções", o que é senso comum para os desenvolvedores. Um cliente pode não achar que é bom senso, então está lhe dizendo.
AlexWebr #
1
+1, na realidade, o cliente não tem idéia do que é a programação funcional ou é motivado pelas últimas palavras da moda ou porque o fez há vinte anos e ainda se considera técnico.
Tipo anônimo
5

Antes de me preocupar mais, eu me certificaria de que vocês dois estejam falando sobre a mesma coisa. Você pode perguntar quando o software é 'orientado a objetos' para ele. Sine, ele disse que não é sua principal experiência, ele pode ter alguma idéia distorcida.

Por exemplo, muitas pessoas poderiam considerar

class C {
public:
  C();
  void f( int );
  void g();
};

ser uma abordagem clássica orientada a objetos, mas

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

não (mesmo que ambos sejam igualmente orientados a objetos no que diz respeito à definição clássica de "dados em conjunto com as funções que os operam").

Frerich Raabe
fonte
2
Por que discutir sobre o significado preciso de POO? Seria melhor perguntar por que o cliente acha que sua simulação é mais adequada à programação funcional. O cliente pode estar certo ... duvido seriamente de "funcional" que ele quis dizer seu segundo exemplo em C, ou que ele estava confundindo "funcional" com "imperativo".
Andres F.
@ André F .: Não afirmei que por 'funcional' ele quis dizer meu segundo exemplo em C. Eu estava apenas salientando que algumas pessoas consideram OOP enquanto outras não. Portanto, antes de iniciar uma discussão, seria bom evitar qualquer mal-entendido. Talvez não haja discordância em primeiro lugar. Talvez o chefe, já que ele disse que não está familiarizado com o OOP, suponha que o OOP tenha certas propriedades (assim como o OP aparentemente assumiu que a programação funcional tinha certas propriedades).
Frerich Raabe
Estritamente, eu não consideraria o último como OOP, pois o envio de chamada / mensagem de método não é roteado pelo objeto. Essa é uma característica fundamental do OOP.
Donal Fellows
5

Você tentaria persuadir seu cliente que o uso de programação orientada a objetos é muito mais limpo?

Eu acho que você precisa se educar mais sobre paradigmas de programação. O código programado orientado a objetos não é necessariamente mais limpo e, de fato, não é universalmente aplicável. Além disso, um bom codificador orientado a objetos sabe como fazer um bom trabalho usando um procedimento / modular (com paradigmas funcionais e declarativos, é um pouco mais difícil, mas não deve ser excessivamente difícil para um bom programador chegar - via leitura e dedução - para uma solução FP / declarativa aceitável.)

Repito: você quase nunca pode, mas quase não consegue entender bem quando e como usar a Orientação a Objetos sem entender bem a programação processual e modular. OO é muito mais do que apenas declarar classes e hierarquias de herança.

Ou você tentaria seguir o que ele exigia e fornecer um código ruim?

Se você não pode escrever um bom código processualmente, duvido que possa escrever um bom código de maneira orientada a objetos. Período. Não estou tentando julgar aqui, mas isso tem que ser afirmado.

Orientação a objetos é uma extensão da programação processual e modular. A Orientação a Objetos simplesmente fornece ferramentas que, quando usadas adequadamente, oferecem melhores mecanismos para lidar com problemas de encapsulamento, acoplamento, coesão e reutilização / extensibilidade de código.

Mas todas essas questões não são inerentes e exclusivas ao OO. Eles existem em código processual / modular (e em outros paradigmas). Esse é o tipo de questões de complexidade que, em sua essência, são independentes de paradigma. Se você não pode lidar com eles sem cola OO, é improvável que você possa lidar com eles com ela.

=========

Voltando à sua pergunta original, tente persuadir seu cliente. Depende. Como o pôster Sean McMillan disse, se o cliente está simplesmente tentando microgerenciar o esforço de desenvolvimento de alguma agenda (leia-se, política do escritório), vá embora. As pessoas que fazem isso sabotam projetos para culpar outra pessoa ou forçar uma agenda específica. Você não quer se envolver nisso.

OTH, pode haver outras razões para esse requisito. Muitas lojas incorporadas, por certo ou errado, optam por impor muitas restrições ao que você pode fazer com C ++ (sem métodos virtuais, sem exceções, por exemplo). Outras vezes, existem razões técnicas válidas para isso.

Então, você precisa entender por que o cliente deseja evitar o código OO. E se você puder supor que não há agenda política (sem bandeiras vermelhas), faça o que é profissional, o que é simplesmente fazer o código processualmente / modular e fazer um bom trabalho.

Realmente não há desculpa para fornecer código de baixa qualidade, independentemente do paradigma de programação. Se você não pode produzir código aceitável com um paradigma, certamente não pode produzir código aceitável em geral.

luis.espinal
fonte
3

Você está misturando estruturas de dados e programação orientada a objetos (uma confusão comum neste mundo infestado de OO)

Se tudo o que você precisa fazer é "rastrear atributos de dados" em uma estrutura de dados e modificá-los, quase qualquer linguagem criada após os anos 70 terá um bom suporte, OO ou não.

As coisas que são mais fáceis de fazer no OO são difíceis

  • Herança baseada em classe (é fácil criar uma nova classe que finge ser antiga)
  • Polimorfismo baseado em classe (é fácil adicionar novos tipos de formiga à simulação posteriormente)

Se você não precisa urgentemente de um deles, basicamente qualquer paradigma de programação deve resolver isso sem muitos problemas.

hugomg
fonte
Eu acrescentaria que qualquer linguagem de programação funcional com suporte para polimorfismo deve facilitar bastante escrever um estilo orientado a objetos ou orientado a pseudo-objetos que permita adicionar facilmente novos tipos de formigas.
Marcin
@ Marcin: é verdade que as linguagens FP modernas são bastante poderosas. Eu realmente queria salientar o distingction entre dados-structurs / ADTs e OO
hugomg
Mas OO é realmente apenas ADTs mais despacho de método controlado por objeto. Tudo o resto se baseia em cima disso. (Bem, muitas vezes, o único controle pelo objeto ao longo da expedição é pelo tipo do objeto, mas isso é um refinamento.)
Donal Fellows
3

meu cliente disse que, como ele tem experiência em programação funcional, ele gostaria que a simulação fosse feita usando programação funcional.

(Este é mais um exemplo de um problema social confundido com um problema técnico / de design.)

Existem duas possibilidades aqui:

  1. Seu cliente espera poder pegar o código que você escreveu e adaptá-lo ou mantê-lo depois que terminar de escrevê-lo. Nesse caso, você deve saber muito mais sobre o "estilo da casa" - funcional vs OO é apenas a ponta do iceberg. Você precisará se limitar a um estilo de programação que seu cliente entenda ou precisará educá-lo nos estilos que preferir. (Uma vez, fui convidado a criar um aplicativo Web com CGI, sem usar modelos ou bibliotecas, porque o cliente pode querer fazer alterações.)

  2. Seu cliente está tentando controlar o desenvolvimento por causa de alguma agenda. Esta é uma sacola cheia de loucuras com as quais você não quer nada. Se você estiver realmente fornecendo um software "chave na mão", o cliente não deve se importar se é feito de hamsters rodando sobre rodas, desde que faça o trabalho de maneira confiável. Permitir que você seja microgerenciado dessa maneira é apenas pedir dor.

Cabe a você decidir em que situação está e agir de acordo.

Sean McMillan
fonte
3

Umm ... eu sou o único aqui pensando "este é obviamente um trabalho / tarefa de teste"? .

Primeiro: a tarefa em si é uma espécie de natureza "acadêmica" (simula um aspecto do comportamento das formigas).

Segundo - uma solicitação para implementar requisitos usando (ou evitando) um paradigma de programação muito específico cheira ao "cliente" que pode ler o código e fazer tais afirmações.

Se for esse o caso, é melhor você fazer o que é necessário - será uma experiência de aprendizado bastante agradável e, se você puder, aprenderá muito no processo ...

Se não for esse o caso, você deve perguntar a si mesmo e / ou ao cliente o motivo da atribuição. Se o raciocínio for sólido, faça-o - você aprenderá e será melhor como programador da experiência. Quem sabe - você pode até aprender a gostar de estilo funcional em vez de OO.

Se a explicação estiver faltando, todas as apostas estão desativadas. Não posso recomendar o que fazer.

Você pode tentar implementar independentemente os requisitos na linguagem / estilo funcional ou pode recusar educadamente a oferta se sentir algo suspeito.

O principal é que, depois de entender a motivação por trás dos requisitos, o curso de ação adequado se torna evidente.

EDIT: Depois de dar uma olhada na diagonal do PDF referenciado, os algoritmos descritos lá certamente parecem um bom ajuste para o estilo funcional, em vez de OO

Roland Tepp
fonte
2

Existem vários aspectos bons em sua solicitação para usar a programação funcional:

  1. Você tem um cliente, é sempre um bom sinal
  2. O cliente espera que você seja muito bom no que está fazendo. É por isso que eles pedem programação funcional. Portanto, sua organização de vendas está fazendo um bom trabalho ou você está solicitando um preço muito alto pelos seus serviços.
  3. A organização do cliente tem algumas pessoas que sabem que a programação funcional é uma coisa boa e será grande no futuro

Mas existem alguns sinais alarmantes também:

  1. Você não parece preparado para implementá-lo na programação funcional. Você já está um pouco desatualizado em suas habilidades e não pode acompanhar as mudanças.
  2. Ou o cliente espera que você seja melhor programador do que realmente é. Isso significa que você pode precisar fazer o downgrade de seus requisitos até poder fazê-lo corretamente.
tp1
fonte
-1 para a suposição implícita de que FP é melhor que POO.
Russell Borogove
@ tp1 1) Você supõe que o cliente é tecnicamente mais inteligente que o programador, o que não é o caso, já que o cliente é exatamente esse cliente. 2) O FP é mais antigo que o OOP e, apesar de estar recebendo muita imprensa ultimamente, não há nada errado com o OOP e você não precisa se esquecer de usar o FP 3) A pior parte disso é presumir que o FP é melhor e está usando O FP faz de você um programador melhor, só é verdade caso a caso e, nesse caso, parece não ser verdade.
Joe Tyman
@ Joe Tyman: Bem, tem que haver suposição de que as pessoas não são estúpidas, ou de outra forma os clientes desaparecem em um instante. Eu não estava tentando dizer que oop é ruim ou pior, mas, em vez disso, assumir que o funcional pode ser um requisito irracional nessa situação - talvez o cliente não conheça as habilidades dos programadores, ou pior, tentando fazer com que os programadores mudem de tecnologia.
tp1 29/11
@ Joe Tyman: Além disso, o pior cenário que eu tinha em mente era que os clientes realmente precisam de pessoas que possam fazer alguma programação funcional avançada, como a teoria das categorias, e estão tentando encontrar uma equipe que possa fazer isso - é por isso que a solicitação para eles poderia ser irracional.
tp1 29/11
1

Apoiar as respostas acima de que talvez o OO não seja a melhor solução; nesse caso, o cliente pode ter razão.

Dê uma olhada no Desafio de IA, que modela alguns dos comportamentos detalhados na pergunta aqui http://aichallenge.org e, em seguida, dê uma olhada na variedade de pacotes iniciais - http://aichallenge.org/starter_packages.php/ most são línguas que eu não colocaria dentro do paradigma OO.

Lucas
fonte
1

Você não escreveu nada sobre linguagem de programação, que é provavelmente a coisa mais importante lá. A diferença entre OOP e programação funcional não é apenas a maneira como o código é organizado, mas a própria linguagem. Quando alta simultaneidade é o caso, a linguagem funcional Erlang está em uso e possui uma vantagem muito alta sobre, por exemplo, Java (é usada, por exemplo, por bate-papo no Facebook). A solução de POO pode simplesmente falhar devido a problemas de desempenho.

O cliente aqui é universitário; portanto, o idioma não é apenas um problema de desempenho / configuração; o código também pode ser usado para trabalho didático com estudantes ou pesquisa própria. Portanto, 'convencer' o cliente a escolher outro paradigma não é, em minha opinião, aplicável aqui. Ou você pode lidar com a tarefa ou não (e, portanto, não deve aceitar esse projeto).

Marinheiro Danubiano
fonte
0

O cliente diz "pular", sua resposta é: __ _ ?

Para mim, tentaria persuadir se isso fizesse sentido (novo projeto), mas também tenho um cliente com um aplicativo VB6 de 10 anos que faço atualizações ocasionalmente ... para não convencê-los a

boomhauer
fonte
tecnicamente, embora o aplicativo VB6 seja bom, é quase OO e, se funcionar bem no sistema operacional atual, por que "atualizar" para o .NET. Isso não faz sentido, a menos que você queira tirar proveito das novas funcionalidades.
Tipo anônimo
Sim, mas você já tentou usar o vb6 ultimamente? é muuuuito dolorosa;)
boomhauer
Sim. Usamos bastante para manter os aplicativos existentes que ainda não receberam orçamento para uma atualização para java ou .net. É doloroso (comparado a um IDE moderno), mas também é relativo. Como qualquer linguagem (incluindo scripts), uma vez que você é bom nisso, sua definição de dor se torna muito mais subjetiva.
Tipo anônimo
0

Faça 'Cross Examine' seu cliente um pouco (de maneira não conflituosa):

O cliente realmente sabe a diferença entre OOP e programação funcional? As preocupações / solicitações do cliente são legítimas?

Se 'Sim': se você estiver qualificado, faça o que eles querem e pegue seu dinheiro. Se você não estiver qualificado, diga a eles e deixe-os decidir o que fazer.

Senão: olá! Fora daqui!

Vetor
fonte
0
double dist(Point p1, Point p2) 
{
  //return distance
}

Esta função é funcional desde que não leia / grave nada fora da função. Se a função tocasse em uma variável de classe, ela não seria mais "funcional". A vantagem do estilo funcional é que não há mais erros de alteração ou estado inválido. Uma grande quantidade de funções são apenas fórmulas matemáticas. Essa é uma programação funcional em poucas palavras.

BTW, você pode combinar um estilo funcional em um design baseado em objeto ou orientado. Por exemplo, as duas variáveis ​​"Point" são objetos com state. E a função ainda está funcional! Yay!!

Lord Tydus
fonte