クライアントがオブジェクト指向プログラミングを使用しないように要求した場合はどうしますか？

グリッド内のアリの活動をシミュレートするプログラムを作成しています（PDF）。アリは動き回り、物を拾い、物を落とします。

問題は、アリのアクションと各アリの位置をクラス属性で簡単に追跡できる（そして、そのようなアリの多くのインスタンスを簡単に作成できる）一方で、クライアントは関数型プログラミングのバックグラウンドがあるため、関数型プログラミングを使用して行われるシミュレーション。

明確にするために、クライアントからの元の単語は「クラスなし」のみであり、「関数型プログラミング」ではありません。だから私は彼が関数型プログラミングを意味するのではなく、私が命令的にそれを行うことができると思います。さらに、関数型プログラミングの経験はありません。

ただし、単に「命令的に実行する」よりも、特に関数型プログラミングの要件に関するこの質問に焦点を当てることが有益だと思います。

この状況にどのように対処しますか？クライアントに、オブジェクト指向プログラミングを使用する方がはるかにクリーンであると説得して、彼が要求したものに従い、質の悪いコードを与えようとしますか、それとも何か他のことをしますか？

オブジェクト指向のコードは定義によるクリーナーではなく、逆に非OOコードは定義によるくだらないものではありません。この特定の問題へのオブジェクト指向マッピングはかなり明白なようですが、とにかく関数型プログラミングのアプローチを試すことをお勧めします。最高のショットを与え、あなたが集結できる最高の関数型プログラミングスタイルで問題を解決しようとしてください。

あなたはクライアントが関数型言語でプログラムするのに使用したと言いますが、多分彼はあなたが関数型スタイルでコードを書くことをあなたに要求する理由があります。彼に理由を尋ねるべきです。

たぶん、彼はコードを保持し、後で自分でそれを維持するつもりです。

さらに、2つの選択肢は、オブジェクト指向スタイルにするか、あなたが言ったようなくだらないコードを書くことだとは思いません。このような例で機能的なコードを書くことは、特にオブジェクト指向言語の経験がある場合は難しくなる可能性がありますが、クライアントが機能的なスタイルに慣れるのに少し長く待てば、それはそうではありません。彼にそれを尋ねるのは痛い。

私は彼に関数スタイルのコードが必要な理由を尋ねます。時間が問題にならない場合は、関数型プログラミングの速度に追いつくために数日余分に頼みます。（学ぶために報酬を得るための万歳！）

他のすべてが失敗した場合は、オブジェクト指向スタイルでそれを行う方がはるかに短い時間で済むと説明します。

関数型プログラミングは単に「クラスなしのプログラミング」を意味するものではないことをご存知ですか？

詳細については、Wikipediaの記事をご覧ください。

コンピューターサイエンスでは、関数型プログラミングは、計算を数学関数の評価として扱い、状態データと可変データを回避するプログラミングパラダイムです。状態の変化を強調する命令型プログラミングスタイルとは対照的に、関数の適用を強調します。

関数型プログラミングは、OOがプログラミングパラダイムであるように、プログラミングパラダイムです。

あなたの背景がオブジェクト指向の場合、すべてのアリをオブジェクトにしたい方法がわかります。一方、数百万のアリを含むアリの農場をシミュレートしている場合、オブジェクト指向とメッセージの受け渡しは非効率になる可能性があります。

幸いなことに、Pythonには関数型プログラミングのための優れたツールがあります（最も重要なのは、関数がファーストクラスのオブジェクトであることです）。

Python関数型プログラミングHOWTO

クライアントに関数型プログラミングが必要な場合は、それを専門とする人を雇う必要があることを説明します。関数型プログラミングはOOPとは非常に異なります。関数型プログラミングを簡単に選択して、高品質の複雑なソリューションを提供できると考えると、誤解されます。

「OO」は「機能的」に完全に反するという一般的な誤解があります。これらは非常にうまく連動します。あなたの例では、「Ant」は抽象データ型としてうまくモデル化でき、クラスとオブジェクトを使用して簡単に実装できると思います。「Ant状態」間の遷移は、関数を使用して自然にモデル化できます。これにより、「Ant」クラスが不変型である限り、機能的なアプローチが可能になります。

また、オブジェクトは貧乏人の閉鎖であるため、「オブジェクト」は閉鎖の機能概念によって交換できることに注意してください。

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

クライアントと話し合った後、もし彼がまだ自分のやり方を望んでいるなら、あなたはプロの仕事をするか、できないならあなたは契約を引き受けないか、何らかの方法を見つけます。

あなたが同意しないという理由だけで「くだらないコード」を作成することは、非常に専門的ではないでしょう。

1. クライアントが関数型プログラミングと命令型プログラミングの違いを知っていると仮定するのはなぜですか？多くの人は、非OOプログラミングパラダイムの名前や詳細を知らず、「手続き型」、「命令型」、「機能型」などの用語を容易に交換します。

2. そのように歩くべきだと思わない限り、他の人が歩くように言っているように歩かないでください。したがって、関数型プログラミングが適切であると思わない場合は、失敗するように設定したり、中途半端にプロジェクトを引き受けたりしないでください。

3. クライアントが仕様を書いたら仕様を実装し、そうでなければ仕様を書いて仕様を実装します。

4. クライアントの決定に影響を与える最良の戦略は、望ましくないオプションを大幅に高価にすることです。それは毎回動作します。

5. あなたが（クライアントに対して）専門家であれば、彼らを説得できるはずです。

6. クライアントが有効なポイントを持っているかどうかを本当に知るためには、関数型プログラミングでより多くの経験を積む必要があります。

7. 両方の方法で実行してから、クライアントに両方の実装を見てもらい、どちらが保守しやすいかを決定してください。このすべてをプロジェクトの見積もりに織り込むことで、報酬を得ながら学習曲線を楽しむことができます。

さらに悩む前に、私はあなたとあなたの両方が同じことについて話していることを確認します。ソフトウェアがいつ彼にとって「オブジェクト指向」であるかを彼に尋ねることができます。彼はそれが彼自身の主な専門知識ではなく、彼がいくらか歪んだ考えを持っているかもしれないと言った。

たとえば、多くの人々が考慮することができます

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

古典的なオブジェクト指向アプローチであるが、

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

（両方とも、古典的な「データとそれに作用する関数」の定義に関する限り、どちらも等しくオブジェクト指向ですが）。

オブジェクト指向プログラミングを使用する方がはるかにクリーンであるとクライアントを説得してみませんか？

プログラミングのパラダイムについてもっと教育する必要があると思います。オブジェクト指向のプログラムされたコードは必ずしもきれいではなく、実際、普遍的に適用できるわけではありません。また、優れたオブジェクト指向コーダーは、手続き型/モジュラーを使用して優れた作業を行う方法を知っています-許容可能なFP /宣言型ソリューションへ。）

繰り返しますが、手続き型プログラミングとモジュール式プログラミングを十分に理解していなければ、オブジェクト指向をいつどのように使用するかを十分に理解することはできません。オブジェクト指向は、クラスと継承階層を宣言するだけではありません。

それとも、彼が必要とするものに従い、彼にくだらないコードを与えようとしますか？

手続き型で適切なコードを記述できない場合、オブジェクト指向の方法で適切なコードを記述できるとは思えません。期間。私はここで判断しようとはしていませんが、これは断言する必要があります。

オブジェクト指向は、手続き型およびモジュール型プログラミングの拡張機能です。オブジェクト指向は、適切に使用すると、カプセル化、結合、結合、コードの再利用/拡張性の問題に対処するためのより優れたメカニズムを提供するツールを提供します。

しかし、これらの問題はすべて固有のものではなく、オブジェクト指向に固有のものではありません。それらは手続き型/モジュール型コード（および他のパラダイム）に存在します。これは、本質的にパラダイムに依存しないタイプの複雑さの問題です。オブジェクト指向の接着剤なしでそれらを処理できない場合、それでそれらを処理できる可能性は低いです。

=========

クライアントを説得しようとするかどうかの元の質問に戻ります。場合によります。ポスターのショーン・マクミランが言ったように、クライアントが単にアジェンダ（読み取り、オフィスの政治）の開発努力をマイクロ管理しようとしているなら、立ち去ってください。その妨害活動を行う人々は、他の誰かを非難したり、特定のアジェンダを推進したりします。あなたはそれに関与したくありません。

OTH、そのような要件には他の理由があるかもしれません。多くの組み込みショップは、正しいか間違っているかを問わず、C ++でできること（たとえば、仮想メソッドや例外はありません）に多くの制約を課すことを選択します。他にも、そうするための正当な技術的理由があります。

したがって、クライアントがオブジェクト指向コードを避けたい理由を理解する必要があります。そして、政治的アジェンダ（レッドフラッグ）がないと推測できる場合は、専門的なことを行う必要があります。これは、単に手順/モジュール方式でコードを実行し、それで良い仕事をするだけです。

プログラミングのパラダイムとは無関係に、くだらないコードを提供する言い訳は本当にありません。1つのパラダイムで受け入れ可能なコードを生成できない場合、一般的に受け入れ可能なコードを生成することはできません。

データ構造とオブジェクト指向プログラミングを混同しています（このオブジェクト指向の世界でよくある混乱）

データ構造内の「データ属性の追跡」とそれらの変更のみが必要な場合は、70年代以降に作成されたほぼすべての言語がオブジェクト指向かどうかに関係なくサポートされます。

オブジェクト指向で行う方が簡単なことは大雑把です

• クラスベースの継承（古いクラスのふりをする新しいクラスを簡単に作成できます）
• クラスベースのポリモーフィズム（その後、簡単に新しい種類のアリをシミュレーションに追加できます）

これらのいずれかの差し迫った必要性がない場合、基本的には、プログラミングパラダイムは、あまり多くの問題なくこれを解決する必要があります。

私のクライアントは、関数型プログラミングのバックグラウンドを持っているので、関数型プログラミングを使用してシミュレーションを作成したいと考えています。

（これは、社会的問題が技術的/設計的な問題と間違えられているもう1つの例です。）

ここには2つの可能性があります。

1. あなたのクライアントは、あなたが書いたコードを取り、あなたがそれを書いた後、自分でそれを調整または維持できることを期待しています。もしそうなら、あなたは「ハウススタイル」についてもっと多くを知る必要があります-機能的対オブジェクト指向は氷山の一角にすぎません。クライアントが理解できるプログラミングのスタイルに自分自身を制限するか、クライアントを好みのスタイルで教育する必要があります。（かつて、クライアントが変更を加える可能性があるため、テンプレートやライブラリを使用せずにCGIでWebアプリを構築するように求められました。）

2. クライアントは、アジェンダのために開発を制御しようとしています。これは、あなたが何の関係も持ちたくないという狂気に満ちたバッグです。本当に「ターンキー」のソフトウェアを提供している場合、クライアントは、確実に仕事をする限り、車輪の上を走るハムスターでできているかどうかは気にする必要はありません。この方法で自分をマイクロ管理できるようにすることは、痛みを求めるだけです。

どの状況にいるかを判断し、それに応じて行動するのはあなた次第です。

うーん...私はここで「これは明らかにテストジョブ/割り当てです」と考えている唯一のものですか？。

まず、課題自体は一種の「学問的」なものです（アリの行動の様相をシミュレートします）。

第二に-非常に特定のプログラミングパラダイムを使用して（または回避して）要件を実装する要求は、コードを読み取ってそのようなアサーションを作成できる「クライアント」の匂いがします。

この場合、あなたはあなたに必要なことをする方が良いです-それはかなり良い学習経験になるでしょう、そしてあなたがそれを行うことができれば、あなたはその過程で多くを学ぶでしょう...

そうでない場合は、実際に自分自身や顧客に割り当ての理由を尋ねてください。推論がしっかりしているなら、それをしてください-あなたは学び、あなたは経験のためにプログラマとしてより良くなるでしょう。誰が知っている-あなたはオブジェクト指向の機能的なスタイルを好むことを学ぶかもしれません。

説明が不足している場合、すべての賭けはオフになっています。

機能的な言語/スタイルで要件を実装するかどうかに関係なく試してみるか、怪しいものを感じた場合は丁寧にオファーを断るかもしれません。

主なものは、要件の背後にある動機を理解すると、適切な行動方針が明らかになることです。

編集：参照されたPDFを斜めに見てみると、そこに記述されているアルゴリズムは、オブジェクト指向ではなく機能的なスタイルに適しているようです。

関数型プログラミングを使用するという要求には、いくつかの優れた側面があります。

1. あなたはクライアントを持っています、それは常に良い兆候です
2. クライアントは、あなたがあなたがしていることに非常に優れていることを期待しています。これが彼らが関数型プログラミングを要求する理由です。したがって、あなたの販売組織は良い仕事をしているか、あなたのサービスに非常に高い価格を求めています。
3. クライアント組織には、関数型プログラミングが良いことであり、将来的に大きくなることを知っている人がいます

しかし、いくつかの驚くべき兆候もあります。

1. 関数型プログラミングで実装する準備ができていないようです。あなたはすでにあなたのスキルが少し時代遅れであり、変化に追いつくことができません。
2. または、クライアントは、あなたが実際よりも優れたプログラマになることを期待しています。これは、適切に実行できるようになるまで、要件をダウングレードする必要がある場合があることを意味します。

OOである可能性があるという上記の回答を支持することは、最良の解決策ではありません。

こちらの質問で詳しく説明されている動作の一部をモデル化したAIチャレンジをご覧ください。http：//aichallenge.orgから、さまざまなスターターパッケージ-http://aichallenge.org/starter_packages.php/ mostをご覧ください。私はオブジェクト指向のパラダイムに入れない言語です。

プログラミング言語については何も書いていませんが、プログラミング言語はおそらく最も重要なものです。OOPと関数型プログラミングの違いは、コードの編成方法だけでなく、言語自体です。同時実行性が高い場合、関数型言語のErlangが使用されており、たとえばJava（Facebookチャットなどで使用される）よりも非常に高い利点があります。OOPソリューションは、パフォーマンスの問題のために単に失敗する可能性があります。

ここのクライアントは大学であるため、言語はパフォーマンス/構成の問題だけでなく、コードは学生との教訓的な作業や独自の研究にも使用できます。したがって、他のパラダイムを選択するように「説得する」クライアントは、ここでは適用されません。これは、タスクを処理できるかできないかのいずれかです（そのため、そのプロジェクトを受け入れないでください）。

クライアントは「ジャンプ」と言って、あなたの答えは：__ _？

私にとっては、理にかなっているなら説得しようと試みます（新しいプロジェクト）が、時折アップグレードする10年前のVB6アプリを使用しているクライアントもいます...説得するつもりはありません

クライアントを少し「クロスチェック」します（対立的でない方法で）：

クライアントは実際にOOPと関数型プログラミングの違いを知っていますか？クライアントの懸念/要求は正当ですか？

「はい」の 場合：資格がある場合は、彼らが望むことをしてお金を取ります。資格がない場合は、その旨を伝え、何をすべきかを彼らに決めさせます。

それ以外の場合： そこから離れてハイテール！

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

この関数は、関数の外部で読み取り/書き込みを行わない限り機能します。関数がクラス変数に触れた場合、「機能的」ではなくなります。機能スタイルの利点は、状態の変更や無効化によるバグがなくなることです。大量の関数は単なる数式です。それは簡単に言えば関数型プログラミングです。

ところで、機能ベースのスタイルをオブジェクトベースまたは指向のデザインに組み合わせることができます。たとえば、2つの「ポイント」変数は状態を持つオブジェクトです。そして、機能はまだ機能しています！わーい！！