クライアントがオブジェクト指向プログラミングを使用しないことを要求した場合はどうしますか？
グリッド内のアリの活動 （PDF）をシミュレートするプログラムを書いています。アリは動き回ったり、物を拾ったり、物を落としたりできます。
問題は、アリのアクションと各アリの位置をクラス属性で簡単に追跡できる（そして、そのようなアリの多くのインスタンスを簡単に作成できる）一方で、クライアントは、関数型プログラミングのバックグラウンドがあるため、関数型プログラミングを使用して行われるシミュレーション。
明確に言うと、クライアントからの元の単語は「クラスなし」だけであり、「関数型プログラミング」ではありません。だから私は彼が関数型プログラミングを意味するのではなく、命令的にそれを行うことができると思います。また、関数型プログラミングの経験はありません。
ただし、この質問に焦点を当てることは、単に「強制的に実行する」だけではなく、関数型プログラミングの要件に特に焦点を当てることが有益だと思います。
この状況にどのように対処しますか？オブジェクト指向プログラミングを使用する方がはるかにクリーンであるとクライアントを説得しようとするでしょうか、彼が必要とするものに従い、低品質のコードを与えるようにするか、それとも何か他のことをしますか？
オブジェクト指向のコードは当然のことながらクリーンではありません。逆に、非OOコードは当然のことではありません。この特定の問題にはかなり明白なオブジェクト指向のマッピングがあるようですが、とにかく関数型プログラミングのアプローチを試すことをお勧めします。それをあなたのベストショットにして、あなたが集めることができる最高の関数型プログラミングスタイルで問題を解決するようにしてください、そしてあなたはあなたが予期しない何かを学ぶだけかもしれません。
あなたは、クライアントが関数型言語でプログラミングするために使用したと述べましたが、おそらく彼は、関数型スタイルでコードを書くことをあなたに要求する理由があります。 理由を尋ねる必要があります。
多分彼はコードを保持し、後でそれを自分で維持するつもりです。
さらに、私はしないでください 2つの選択肢はOOスタイルにするか、くだらないコードを書くと思いますか？このような例で関数型コードを書くことは、特にオブジェクト指向言語の経験しかなければ、難しいかもしれませんが、クライアントが関数型スタイルに慣れるまでもう少し待つことをいとわない場合は、彼にそれを尋ねるのは痛い。
私は彼に関数型のコードが必要な理由を尋ねます。時間がそれほど問題ではない場合は、関数型プログラミングに慣れるまであと数日かかります。 （学ぶために給料をもらったばあ！）
他のすべてが失敗した場合は、OOスタイルで実行する方がはるかに短い時間で済みます。
関数型プログラミングは単に「クラスなしのプログラミング」を意味するのではないことを知っていますか？
詳細については Wikipediaの記事 を参照してください。ただし、要するに...
コンピュータサイエンスでは、関数型プログラミングは、計算を数学関数の評価として扱い、状態や可変データを回避するプログラミングパラダイムです。状態の変化を強調する命令型プログラミングスタイルとは対照的に、関数の適用を強調します。
関数型プログラミングは、OOがプログラミングパラダイムであるように、プログラミングパラダイムです。
背景がOOの場合、すべてのアリをオブジェクトにする方法を確認できます。一方、何百万ものアリがいるアリファームをシミュレートしている場合は、OOおよびメッセージパッシングが非効率になる可能性があります。
幸運なことに、Pythonには関数型プログラミングのための優れたツールがあります（最も重要なのは、関数がファーストクラスのオブジェクトであることです）。
関数型プログラミングが必要な場合は、その専門家を雇う必要があることをクライアントに説明します。関数型プログラミングはOOPとは大きく異なります。OOPを簡単に取り上げて、高品質の複雑なソリューションを提供できると考えるのは間違いです。
「OO」は「機能的」に完全に反するという一般的な誤解があります。これらのことは非常にうまく連携できます。あなたの例では、「Ant」は抽象データ型としてモデル化できると思います。これは、クラスとオブジェクトを使用して簡単に実装できます。 「Ant状態」間の遷移は、関数を使用して自然にモデル化できます。これにより、「Ant」クラスが不変の型である限り、機能的なアプローチが可能になります。
また、オブジェクトは貧乏人のクロージャであるので、「オブジェクト」はクロージャの機能的概念によって交換できることに注意してください。貧弱な人のオブジェクトは... ;-)：
https://stackoverflow.com/questions/501023/closures-and-objects
クライアントと話し合った後も、彼が自分のやり方でそれを望んでいる場合は、専門的な仕事をするか、それができない場合は、契約を結ばないか、それから何らかの方法を見つけることができません。
あなたが同意しないという理由だけで「くだらないコード」を作成することは、非常に専門家ではないでしょう。
クライアントが関数型プログラミングと命令型プログラミングの違いを知っていると私たち全員が想定しているのはなぜですか？多くの人々は、非OOプログラミングパラダイム）の名前や詳細を知らず、「手続き型」、「命令型」、「関数型」などの用語を容易に交換します。
あなたがそのように歩くべきだと信じない限り、他の人があなたに歩くように言うように歩いてはいけません。したがって、関数型プログラミングが適切であると思わない場合は、失敗したり、中途半端にプロジェクトに取り組んだりしないでください。
クライアントが仕様を作成する場合は、仕様を実装します。それ以外の場合は、仕様を作成してyour仕様を実装します。
クライアントの決定に影響を与える最善の戦略は、望ましくないオプションを大幅に高価にすることです。それはいつも働きます。
あなたが（クライアントに対して）専門家であれば、あなたは彼らを説得することができるはずです。
クライアントが有効なポイントを持っているかどうかを本当に知るには、関数型プログラミングの経験を積む必要があります。そうすれば、自信を持って撃ち落とすか、OOあなたの未経験に。
それを両方の方法で行わないで、クライアントに両方の実装を見てもらい、どちらが保守しやすいかを判断させてください。これらすべてをプロジェクトの見積もりに織り込むだけで、給与を受け取りながら学習曲線を楽しむことができます。
オブジェクト指向プログラミングを使用する方がはるかにクリーンであるとクライアントに説得してみませんか？
プログラミングのパラダイムについてもっと学ぶ必要があると思います。オブジェクト指向のプログラムコードは必ずしもクリーンであるとは限らず、実際、普遍的に適用できるわけではありません。また、優れたオブジェクト指向のコーダーは、手続き型/モジュラー型を使用して優れた作業を行う方法を知っています（機能的および宣言的パラダイムを使用すると、少し難しくなりますが、優れたプログラマーがリーディングと演繹を介して到着することはそれほど難しくありません） -許容できるFP /宣言型ソリューションに。）
繰り返しはできませんが、手続き型プログラミングとモジュール型プログラミングを十分に理解しないと、オブジェクト指向をいつどのように使用するかを十分に理解できません。 OOは、クラスと継承階層を宣言するだけではありません。
それとも、彼が必要とするものに従い、安っぽいコードを彼に与えようとしますか？
適切なコードを手続き的に記述できない場合、オブジェクト指向の方法で適切なコードを記述できるとは思えません。限目。私はここで判断しようとはしていませんが、これは主張されなければなりません。
オブジェクト指向は、手続き型プログラミングとモジュール型プログラミングの拡張です。オブジェクト指向は、適切に使用すると、カプセル化、結合、結合、およびコードの再利用/拡張性の問題に対処するための優れたメカニズムを提供するツールを提供します。
しかし、これらの問題はすべてOOに固有で固有のものではありません。それらは手続き型/モジュール型コード（およびその問題の他のパラダイム）に存在します。これは、その本質的にパラダイムに依存しないタイプの複雑さの問題です。 OO接着剤なしでそれらを処理できない場合、それを使用してそれらを処理できる可能性はほとんどありません。
=========
クライアントを説得しようとするかどうかという元の質問に戻ります。場合によります。ポスターのショーン・マクミランが言ったように、クライアントが単にいくつかの議題（読む、オフィスの政治）の開発努力をマイクロ管理しようとしているのであれば、立ち去ってください。そのサボタージュを行う人々は、他の誰かを非難するか、特定の議題をプッシュします。あなたはそれに関与したくありません。
OTH、そのような要件には他の理由があるかもしれません。多くの組み込みショップは、善悪を問わず、C++で実行できることに対して多くの制約を課すことを選択します（たとえば、仮想メソッドや例外はありません）。それは、ひざまずく方法で行われる場合があります。他の場合には、そうすることには正当な技術的理由があります。
したがって、クライアントがOOコードを避けたい理由を理解する必要があります。そして、政治的議題がない（危険信号がない）と推測できる場合は、専門家としてやるべきことを行う必要があります。これは単にコードを手続き型/モジュール式にして、それをうまく処理することです。
プログラミングパラダイムとは関係なく、くだらないコードを提供するための言い訳は本当にありません。 1つのパラダイムで受け入れ可能なコードを生成できない場合、一般的に受け入れ可能なコードを生成することはできません。
迷惑になる前に、私はあなたたち2人が同じことについて話していることを確認します。ソフトウェアが「オブジェクト指向」であるときは、彼に尋ねることができます。彼自身が彼の主な専門知識ではないと彼が言ったサイン、それは彼がいくつかの歪んだ考えを持っていることかもしれません。
たとえば、多くの人は
class C {
public:
C();
void f( int );
void g();
};
古典的なオブジェクト指向のアプローチであること
struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );
そうではありません（ただし、古典的な「データとそれを操作する関数を組み合わせたデータ」の定義が当てはまる限り、どちらも同じようにオブジェクト指向です）。
私のクライアントは、関数型プログラミングの経験があるため、関数型プログラミングを使用してシミュレーションを実行したいと考えています。
（これは、社会的問題が技術的/設計上の問題と間違われるもう1つの例です。）
ここには2つの可能性があります。
あなたのクライアントは、あなたが書いたコードを取り、あなたがそれを書いた後、自分でそれを適応または維持できることを期待しています。もしそうなら、「ハウススタイル」についてもっと知っておくべきです-ファンクショナルvs OOは氷山の一角にすぎません。プログラミングスタイルに限定する必要があります。クライアントが理解していない場合は、好みのスタイルでクライアントを教育する必要があります（クライアントが変更を加える可能性があるため、テンプレートやライブラリを使用せずに、CGIでWebアプリを構築するように求められました）。
あなたのクライアントは、いくつかの議題のために開発を制御しようとしています。これはあなたが何もしたくないクレイジーでいっぱいのバッグです。あなたが本当に「ターンキー」ソフトウェアを提供しているのであれば、クライアントはそれが確実に仕事をする限り、それが車輪で走っているハムスターでできているかどうか気にすべきではありません。この方法で自分自身をマイクロマネージメントできるようにするのは、痛みを求めているだけです。
現在の状況を決定し、それに応じて行動するのはあなた次第です。
データ構造とオブジェクト指向プログラミングを混同している（このOO感染した世界でよくある混乱）
あなたがする必要があるのがデータ構造の「データ属性の追跡」であり、それらを変更するだけなら、70年代以降に作成されたほとんどすべての言語は、そのための適切なサポートがありますOOかどうか。
OOで簡単にできることは、ラフフライです
- クラスベースの継承（古いクラスを装った新しいクラスを簡単に作成できます）
- クラスベースのポリモーフィズム（後でシミュレーションに新しい種類のアリを簡単に追加できます）
これらのいずれかの差し迫った必要性がない場合、基本的にどのプログラミングパラダイムでも、あまり問題なくこれを解決するはずです。
うーん...私だけがここにいるのですか「これは明らかにテストジョブ/割り当てです」。
まず、割り当て自体は、一種の「学問的」な性質です（アリの行動の側面をシミュレートします）。
第二に、非常に具体的なプログラミングパラダイムを使用して（または回避して）要件を実装する要求は、コードを読み取ってそのようなアサーションを作成できる「クライアント」の匂いがします。
これが事実である場合、あなたはあなたに必要なことをする方が良いです-それはむしろニースの学習経験であり、それができるなら、その過程で多くを学ぶでしょう...
これが当てはまらない場合は、実際に割り当てについての理由を自分自身または顧客に尋ねてください。推論がしっかりしている場合は、それを実行してください-あなたは学び、経験のプログラマーとしてより上手になります。誰が知っている-あなたはオブジェクト指向よりも機能的なスタイルを好きになることを学ぶかもしれません。
説明が不足している場合、すべての賭けはオフです。私はあなたに何をすべきかをお勧めすることはできません。
関数型言語/スタイルで要件を実装するかどうかに関係なく試してみたい場合や、何か怪しいと感じた場合は丁寧に提案を拒否する場合があります。
主なことは、要件の背後にある動機を理解すると、適切な行動方針が明らかになります。
編集：参照されているPDFを斜めに見てみると、そこに記述されているアルゴリズムは、OOよりも機能的なスタイルに適しているように見えます
関数型プログラミングを使用するという要求には、いくつかの優れた側面があります。
- あなたはクライアントを持っています、それは常に良い兆候です
- クライアントは、あなたがあなたがしていることに非常に優れていることを期待しています。これが、関数型プログラミングを求める理由です。あなたの販売組織は良い仕事をしているか、あなたのサービスに非常に高い価格を求めています。
- クライアント組織には、関数型プログラミングが良いことであり、将来的に大きくなることを知っている人がいます
しかし、いくつかの憂慮すべき兆候もあります：
- 関数型プログラミングで実装する準備ができていないようです。あなたはすでにあなたのスキルが少し古くなっていて、変化に追いつくことができません。
- または、クライアントは、あなたが実際よりも優れたプログラマーになることを期待しています。つまり、適切に実行できるようになるまで、要件をダウングレードする必要がある場合があります。
OOかもしれない上記の応答を支持することは、クライアントがポイントを持っているかもしれない場合の最良の解決策ではありません。
こちらの質問で詳細に説明されている動作の一部をモデル化するAIチャレンジを見てみましょう http://aichallenge.org 次に、さまざまなスターターパッケージを見てみましょう- http： //aichallenge.org/starter_packages.php/ ほとんどは、OOパラダイム内に配置しない言語です。
あなたはプログラミング言語について何も書いていません。それはおそらくそこで最も重要なことです。 OOPと関数型プログラミングの違いは、コードの編成方法だけでなく、言語自体でもあります。同時実行性が高い場合、関数型言語Erlangが使用されており、非常に高い利点があります。 over Java（これは、たとえばFacebookチャットで使用されます）OOPソリューションは、パフォーマンスの問題のために単に失敗する可能性があります。
ここのクライアントは大学です。したがって、言語はパフォーマンス/構成の問題だけではなく、コードは学生との教訓的な仕事や独自の研究にも使用できます。したがって、他のパラダイムを選択するようクライアントを「説得」することは、私の意見ではここでは適用されません。これは、タスクを処理できるかできないかです（そのため、そのプロジェクトを実行しないでください）。
クライアントを少し「対面」で調べます（非対立的な方法で）。
クライアントは実際にOOPと関数型プログラミングの違いを知っていますか？クライアントの懸念/要求は正当ですか？
「はい」の場合：資格がある場合は、彼らが望むことをしてお金を受け取ります。資格がない場合は、その旨を伝え、何をすべきかを彼らに決めさせます。
Else：こんにちは！
double dist(Point p1, Point p2)
{
//return distance
}
この関数は、関数の外部で何かを読み書きしない限り機能します。関数がクラス変数に接触した場合、関数は「機能的」ではなくなります。ファンクショナルスタイルの利点は、状態の変更または無効によるバグがなくなることです。大量の関数は単なる数式です。つまり、関数型プログラミングです。
ところで、オブジェクトベースまたは指向のデザイン内で機能的なスタイルを組み合わせることができます。たとえば、2つの「ポイント」変数は状態を持つオブジェクトです。そして機能はまだ機能しています！わーい！！
クライアントは「ジャンプ」と言い、あなたの答えは___？
私にとっては、それが理にかなっている場合（新しいプロジェクト）は説得しようとしますが、10歳のVB6アプリを使用しているクライアントもいて、ときどきアップグレードを行っています...