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

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?

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.

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.

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

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.

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

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.

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.

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").

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.

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.

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.

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

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.

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.

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).

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

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!

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!!