Que feriez-vous si votre client vous demandait de ne pas utiliser de programmation orientée objet?

J'écris un programme pour simuler l' activité des fourmis dans une grille (PDF). La fourmi peut se déplacer, ramasser des objets et les faire tomber.

Le problème est que l'action des fourmis et les positions de chaque fourmi peuvent être suivies par les attributs de classe facilement (et nous pouvons facilement créer de nombreuses instances de telles fourmis) mon client a déclaré que, comme il avait une formation en programmation fonctionnelle, il aimerait simulation à effectuer à l'aide d'une programmation fonctionnelle.

Pour être clair, les mots originaux du client sont "pas de classe" seulement, mais pas "programmation fonctionnelle". Je suppose donc qu'il ne veut pas dire programmation fonctionnelle et je peux le faire impérativement. De plus, je n'ai aucune expérience préalable en programmation fonctionnelle.

Cependant, je pense qu'il est bénéfique de se concentrer sur cette question concernant en particulier une exigence de programmation fonctionnelle plutôt que simplement «le faire impérativement».

Comment géreriez-vous cette situation? Souhaitez-vous essayer de persuader votre client que l'utilisation de la programmation orientée objet est beaucoup plus propre, essayer de suivre ce dont il a besoin et lui donner un code de mauvaise qualité, ou faire autre chose?

Le code orienté objet n'est pas par définition plus propre, et inversement le code non OO n'est pas par définition merdique. Bien qu'il semble y avoir un mappage orienté objet assez évident pour ce problème particulier, je vous suggère d'essayer l'approche de programmation fonctionnelle de toute façon. Donnez-lui votre meilleur coup, essayez de résoudre le problème dans le meilleur style de programmation fonctionnel que vous pouvez rassembler, et vous pourriez juste apprendre quelque chose que vous ne vous attendiez pas.

Vous mentionnez que le client avait l'habitude de programmer dans un langage fonctionnel, il a peut-être une raison pour laquelle il vous demande d'écrire le code dans un style fonctionnel. Tu devrais lui demander pourquoi .

Peut-être qu'il a l'intention de garder le code et de le maintenir lui-même plus tard.

De plus, je ne pense pas que les deux choix soient de le faire à la manière OO ou d'écrire du code merdique comme vous l'avez mentionné. Bien sûr, écrire du code fonctionnel dans un exemple comme celui-ci pourrait être plus difficile, surtout si vous n'avez qu'une expérience dans les langages orientés objet, mais si le client est prêt à attendre un peu plus longtemps pour que vous vous familiarisiez avec le style fonctionnel, il ne le ferait pas '' t mal de lui demander cela.

Je lui demanderais pourquoi il veut le code dans un style fonctionnel et si le temps n'est pas vraiment un problème, je demanderais quelques jours supplémentaires pour se familiariser avec la programmation fonctionnelle. (hourra pour être payé pour apprendre!)

Si tout le reste échoue, expliquez qu'il vous faudrait beaucoup moins de temps pour le faire dans un style OO.

Savez-vous que la programmation fonctionnelle ne signifie pas seulement "programmation sans classes"?

Voir l'article Wikipedia à ce sujet pour le schéma complet, mais en bref ...

En informatique, la programmation fonctionnelle est un paradigme de programmation qui traite le calcul comme l'évaluation de fonctions mathématiques et évite les données d'état et mutables. Il met l'accent sur l'application des fonctions, contrairement au style de programmation impératif, qui met l'accent sur les changements d'état.

La programmation fonctionnelle est un paradigme de programmation, tout comme OO est un paradigme de programmation.

Si votre arrière-plan est en OO, je peux voir comment vous voudriez que toutes vos fourmis soient des objets. D'un autre côté, si vous simulez une ferme de fourmis avec des millions de fourmis, l'OO et la transmission de messages peuvent devenir inefficaces.

Heureusement pour vous, Python dispose d'excellents outils de programmation fonctionnelle (le plus important étant que les fonctions sont des objets de première classe.)

HOWTO de programmation fonctionnelle Python

Expliquez à votre client que s'il veut une programmation fonctionnelle, il devrait embaucher quelqu'un qui se spécialise dans ce domaine. La programmation fonctionnelle est très différente de la POO, et vous vous tromperez si vous pensez que vous pouvez facilement la récupérer et fournir une solution complexe de haute qualité.

Il y a une idée fausse commune selon laquelle "OO" est complètement contraire à "fonctionnel". Ces choses peuvent très bien aller de pair. Dans votre exemple, je suppose qu'un "Ant" peut être modélisé ainsi qu'un type de données abstrait, qui peut être directement implémenté à l'aide de classes et d'objets. Les transitions entre les "états Ant" peuvent être modélisées naturellement à l'aide de fonctions, ce qui vous conduira à une approche fonctionnelle dans la mesure où votre classe "Ant" est un type immuable.

Et sachez que les "objets" peuvent être échangés par le concept fonctionnel d'une fermeture, puisque les objets sont les fermetures du pauvre sont les objets du pauvre sont les ... ;-):

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

Après en avoir discuté avec le client, s'il le veut toujours à sa façon, soit vous faites un travail professionnel, soit si vous ne le pouvez pas, vous ne prenez pas le contrat ou ne trouvez pas de solution.

Produire du "code merdique" simplement parce que vous n'êtes pas d'accord serait très peu professionnel.

1. Pourquoi supposons-nous tous que le client connaît la différence entre la programmation fonctionnelle et impérative? Beaucoup de gens ne connaissent pas les noms ou les spécificités des paradigmes de programmation non OO et échangeront facilement des termes comme "procédural" "impératif" et "fonctionnel".

2. Ne marchez pas comme les autres vous disent de marcher à moins que vous ne croyiez que vous devriez marcher de cette façon. Par conséquent, si vous ne croyez pas que la programmation fonctionnelle est appropriée, ne vous préparez pas à échouer ou à entreprendre un projet sans enthousiasme.

3. Si le client écrit la spécification, implémentez-la, sinon vous écrivez la spécification et implémentez votre spécification.

4. La meilleure stratégie pour influencer les décisions des clients est de rendre l'option indésirable beaucoup plus chère. Cela fonctionne à chaque fois.

5. Si vous êtes l'expert (par rapport au client), vous devriez pouvoir le persuader.

6. Afin de vraiment savoir si le client a un point valide, vous devez acquérir plus d'expérience avec la programmation fonctionnelle, soit pour pouvoir l'abattre en toute confiance, soit pour réaliser que votre parti pris pour l'OO est dû à votre inexpérience.

7. Pourquoi ne pas procéder dans les deux sens, laissez ensuite le client voir les deux implémentations et décidez quelle est la plus facile à maintenir. Il vous suffit de prendre en compte tout cela dans les estimations de votre projet afin que vous puissiez profiter de la courbe d'apprentissage pendant que vous êtes payé.

Avant de continuer, je m'assurerais que vous parliez tous les deux de la même chose. Vous pourriez lui demander quand le logiciel est «orienté objet» pour lui. Sine, il a dit que ce n'était pas son expertise principale lui-même, il se peut qu'il ait une idée biaisée.

Par exemple, de nombreuses personnes pourraient envisager

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

être une approche orientée objet classique, mais

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

pas (même si les deux sont également orientés objet en ce qui concerne la définition classique de "données avec les fonctions qui les opèrent").

Souhaitez-vous essayer de persuader votre client que l'utilisation de la programmation orientée objet est beaucoup plus propre?

Je pense que vous devez vous renseigner davantage sur les paradigmes de programmation. Le code programmé orienté objet n'est pas nécessairement plus propre, et en fait, il n'est pas universellement applicable. En outre, un bon codeur orienté objet sait faire du bon travail en utilisant un procédural / modulaire (avec les paradigmes fonctionnels et déclaratifs, c'est un peu plus difficile, mais il ne devrait pas être trop difficile pour un bon programmeur d'arriver - via la lecture et la déduction - vers une solution FP / déclarative acceptable.)

Vous ne pouvez presque jamais, je le répète, vous ne pouvez presque pas avoir une bonne compréhension du moment et de la façon d'utiliser l'orientation d'objet sans avoir une bonne compréhension de la programmation procédurale et modulaire. OO est bien plus que la simple déclaration de classes et de hiérarchies d'héritage.

Ou essayez-vous de suivre ce dont il a besoin et de lui donner un code merdique?

Si vous ne pouvez pas écrire du bon code de manière procédurale, je doute que vous puissiez écrire du bon code d'une manière orientée objet. Période. Je n'essaie pas de juger ici, mais cela doit être affirmé.

L'orientation objet est une extension de la programmation procédurale et modulaire. L'orientation objet vous fournit simplement des outils qui, lorsqu'ils sont utilisés de manière appropriée, vous offrent de meilleurs mécanismes pour gérer les problèmes d'encapsulation, de couplage, de cohésion et de réutilisation / extensibilité du code.

Mais tous ces problèmes ne sont pas inhérents et uniques à OO. Ils existent dans le code procédural / modulaire (et dans d'autres paradigmes d'ailleurs). C'est le type de problèmes de complexité qui, à la base, est indépendant du paradigme. Si vous ne pouvez pas les manipuler sans colle OO, il est peu probable que vous puissiez les manipuler avec.

=========

Revenons à votre question initiale, à savoir s'il faut essayer de convaincre votre client. Ça dépend. Comme l'a dit l'affiche Sean McMillan, si le client essaie simplement de micro-gérer l'effort de développement d'un programme (lire, politique de bureau), éloignez-vous. Les gens qui font des projets de sabotage pour blâmer quelqu'un d'autre ou pour pousser un programme particulier. Vous ne voulez pas vous impliquer là-dedans.

OTH, il pourrait y avoir d'autres raisons pour une telle exigence. De nombreuses boutiques intégrées, pour le bien ou pour le mal, choisissent de mettre beaucoup de contraintes sur ce que vous pouvez faire avec C ++ (pas de méthodes virtuelles, pas d'exceptions, par exemple.) Parfois, cela se fait de manière agressive. D'autres fois, il existe des raisons techniques valables de le faire.

Vous devez donc comprendre pourquoi le client veut éviter le code OO. Et si vous pouvez supposer qu'il n'y a pas d'agenda politique (pas de drapeaux rouges), alors vous devriez faire la chose professionnelle à faire, qui est simplement de faire le code procédural / modulaire, et de faire du bon travail.

Il n'y a vraiment aucune excuse pour fournir du code merdique, indépendamment du paradigme de programmation. Si vous ne pouvez pas produire de code acceptable avec un seul paradigme, vous ne pouvez certainement pas produire de code acceptable en général.

Vous mélangez les structures de données et la programmation orientée objet (une confusion courante dans ce monde infesté d'OO)

Si tout ce que vous avez à faire est de "suivre les attributs des données" dans une structure de données et de les modifier, alors presque toutes les langues créées après les années 70 auront un bon support, OO ou non.

Les choses qui sont plus faciles à faire en OO sont les mouches à papier

• Héritage basé sur les classes (il est facile de créer une nouvelle classe qui prétend être une ancienne)
• Polymorphisme basé sur les classes (il est facile d'ajouter de nouveaux types de fourmis à la simulation par la suite)

Si vous n'avez pas un besoin urgent de l'un d'entre eux, alors fondamentalement, tout paradigme de programmation devrait résoudre ce problème sans trop de problèmes.

mon client a dit que, comme il avait une formation en programmation fonctionnelle, il aimerait que la simulation soit faite en utilisant la programmation fonctionnelle.

(Ceci est encore un autre exemple d'un problème social confondu avec un problème technique / de conception.)

Il y a deux possibilités ici:

1. Votre client s'attend à être en mesure de prendre le code que vous avez écrit et d'adapter ou de le maintenir lui-même après avoir fini de l'écrire. Si oui, vous devriez en savoir beaucoup plus sur le "style maison" - fonctionnel vs OO n'est que la pointe de l'iceberg. Vous devrez soit vous limiter à un style de programmation que votre client comprend, soit vous devrez éduquer votre client dans les styles que vous préférez. (Une fois, on m'a demandé de créer une application Web avec CGI, sans utiliser de modèles ou de bibliothèques car le client pourrait vouloir apporter des modifications.)

2. Votre client essaie de contrôler le développement en raison d'un programme. C'est un sac plein de folie dont vous ne voulez rien avoir à faire. Si vous fournissez vraiment un logiciel "clé en main", le client ne devrait pas se soucier s'il est fait de hamsters qui roulent, tant qu'il fait le travail de manière fiable. Vous permettre d'être microgéré de cette façon, c'est simplement demander de la douleur.

C'est à vous de décider dans quelle situation vous vous trouvez et d'agir en conséquence.

Umm ... suis-je le seul ici à penser "c'est évidemment un travail / une mission de test"? .

Premièrement, la mission elle-même est de nature "académique" (simuler un aspect du comportement des fourmis).

Deuxièmement - une demande d'implémentation d'exigences utilisant (ou évitant) un paradigme de programmation très spécifique sent le «client» qui peut lire le code et faire de telles affirmations.

Si tel est le cas, vous feriez mieux de faire ce qui vous est demandé - ce sera une expérience d'apprentissage plutôt agréable et si vous pouvez le faire, vous apprendrez beaucoup dans le processus ...

Si ce n'est pas le cas, vous devez en effet vous-même et / ou le client demander le raisonnement sur la mission. Si le raisonnement est solide, faites-le - vous apprendrez et vous serez meilleur en tant que programmeur pour l'expérience. Qui sait - vous pourriez même apprendre à aimer le style fonctionnel par rapport à OO.

Si l'explication manque, alors tous les paris sont désactivés .. Je ne peux pas vous recommander quoi faire.

Vous voudrez peut-être essayer de mettre en œuvre les exigences dans un langage / style fonctionnel ou vous pouvez refuser poliment l'offre si vous sentez quelque chose de louche.

L'essentiel est - une fois que vous comprenez la motivation derrière les exigences, la ligne de conduite appropriée devient évidente.

EDIT: Après avoir regardé en diagonale le PDF référencé, les algorithmes décrits ici semblent sûrement être un bon ajustement pour le style fonctionnel plutôt que OO

Il y a plusieurs bons aspects dans leur demande d'utilisation de la programmation fonctionnelle:

1. Vous avez un client, c'est toujours bon signe
2. Le client s'attend à ce que vous soyez très bon dans ce que vous faites. C'est pourquoi ils demandent une programmation fonctionnelle. Votre organisation commerciale fait donc du bon travail ou vous demandez des prix très élevés pour vos services.
3. L'organisation cliente a des gens qui savent que la programmation fonctionnelle est une bonne chose et sera importante à l'avenir

Mais il y a aussi des signes alarmants:

1. Vous ne semblez pas prêt à l'implémenter dans la programmation fonctionnelle. Vous êtes déjà légèrement dépassé dans vos compétences et ne pouvez pas suivre les changements.
2. Ou le client s'attend à ce que vous soyez un meilleur programmeur que vous ne l'êtes vraiment. Cela signifie que vous devrez peut-être rétrograder leurs exigences jusqu'à ce que vous puissiez le faire correctement.

Appuyant sur les réponses ci-dessus que peut-être OO n'est pas la meilleure solution, auquel cas le client peut avoir un point.

Jetez un œil au défi AI qui modélise certains des comportements détaillés dans la question ici http://aichallenge.org , puis jetez un œil à la variété des packages de démarrage - http://aichallenge.org/starter_packages.php/ most sont des langues que je ne placerais pas dans le paradigme OO.

Vous n'avez rien écrit sur le langage de programmation, qui est probablement la chose la plus importante là-bas. La différence entre la POO et la programmation fonctionnelle n'est pas seulement la façon dont le code est organisé, mais le langage lui-même. Quand une concurrence élevée est le cas, le langage fonctionnel Erlang est utilisé, et il a un avantage très élevé par exemple sur Java (il est utilisé par exemple par le chat Facebook). La solution OOP peut simplement échouer en raison de problèmes de performances.

Le client ici est l'université, donc la langue n'est pas seulement un problème de performance / configuration, le code peut également être utilisé pour un travail didactique avec des étudiants ou pour ses propres recherches. Donc, «persuader» le client de choisir un autre paradigme n'est pas, à mon avis, applicable ici. C'est soit vous pouvez vous charger de la tâche soit vous ne pouvez pas (et donc, vous ne devriez pas prendre ce projet).

Le client dit "sauter", votre réponse est: __ _ ?

Pour moi, je tenterais de convaincre si cela avait du sens (nouveau projet), mais j'ai également un client avec une application VB6 de 10 ans pour laquelle je fais des mises à niveau de temps en temps ... ne vais pas les convaincre de

«Examinez un peu» votre client (de manière non conflictuelle):

Le client connaît-il réellement la différence entre la POO et la programmation fonctionnelle? Les préoccupations / demandes du client sont-elles légitimes?

Si «oui»: si vous êtes qualifié, faites ce qu'ils veulent et prenez votre argent. Si vous n'êtes pas qualifié, dites-le-lui et laissez-le décider quoi faire.

Sinon: hi-tail, il outta là!

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

Cette fonction est fonctionnelle tant qu'elle ne lit / n'écrit rien en dehors de la fonction. Si la fonction touchait une variable de classe, elle ne serait plus "fonctionnelle". L'avantage du style fonctionnel est qu'il n'y a plus de bogues dus à un état changeant ou invalide. Une grande quantité de fonctions ne sont que des formules mathématiques. C'est la programmation fonctionnelle en bref.

BTW, vous pouvez combiner un style fonctionnel dans une conception basée sur un objet ou orientée. Par exemple, les deux variables "Point" sont des objets avec état. Et la fonction est toujours fonctionnelle! Yay!!