OOP、IP、FP、ハノイタワー

これは、OOP、FPの大きな違いを説明するための試みです。
（関数型プログラミング）およびPI（必須）およびPIの理由を証明する
問題を解決するときの好ましい考え方です。
ハノイの塔の問題を解決する例を使用して、これらすべてを実行しようとします。
当然、私は経験豊富なオブジェクト指向、F、またはIと呼ばれるふりをしません
プログラマーですが、まだいくつかのスキルがあり、それらを試してみます
このタスクに適用されますが、私の考えのコースは可能性が最も高く、さらに、
さらに、特に建設的な批判をする必要があるので、
真実に到達します。


まず、問題の本質は何かを思い出させてください。 最初に3本のロッドが与えられました：1、2、3-オン
そのうちの1つは、半径が異なるN個の円の砲塔に張られており、
大きい半径は常に小さい半径の円です。 プログラムは
これらの円をロッドからロッドに移動して、砲塔が
別のロッドになってしまいました。 同時に、各シフトは保存する必要があります
円の順序-すべての円は、より大きな円にのみ配置できます
半径、または空のロッドで、あなたはほとんどの1つだけをシフトできます
棒の上の円。
そのため、最初に1本の棒の上に2つの円の高さがある砲塔を与えた場合、
ロッド番号2に転送する必要がある場合は、正しい
シーケンス
移動は次のようになります：1-> 3、1-> 2、3-> 2.ルールではN-> M
ロッド番号のみが使用され、以下を示します。
ロッドNからロッドMへの円
機能的アプローチ。 それは古典を与えるので、最初に考慮
問題に対する「学校」の解決策。
関数を作成する必要があります。

  N abcを移動 

関数。タレットの高さ、最初のロッドa、最後のロッドb
さらにcを押すと、移動のリストが表示されます。 うーん...まあ、他の何から
機能を調理できますか？ 他からいくつかの関数をコンパイルすることが本質です
アプローチ。 機能を考え出すことができます

  movetoken ab 

ある棒から別の棒に円を移動しますが、意味がありません
それを呼び出す方法が明確ではないためです。 少し必要
素晴らしい機能コンセプトで脳を瞑想し、陰影をつけます：
最初の例を見て、砲塔を動かすには、まず
上部を補助ロッドに移動し、下の円を
ターゲット、そして同じロッドでタレットの上部を移動します。 同時に
上の円はどのロッドにも移動できます。なぜなら、
それらの下では、半径が大きくなります。
やったー 挑戦する
解決しました。 関数moveが何を返さなければならないかを理解するだけです。
原因に。 しかし、ここではすべてが単純であり、FPは代替手段を提供しません。 だから
ビジネス。 実装は大ざっぱで、Haskellで記述できるものに似ています。

 N abcを移動
 // 1つの円をターゲットの砲塔に移動します
移動1 abc =（a、b）
 // topをrod cに転送、大きな円をrod bに転送、
 //ロッドcからロッドbにトップを移動します
移動N abc =移動（N-1）acb：（a、b）：移動（N-1）cba

 //さて、このようなものを呼び出します
印刷移動16 1 3 2 

エレガントで挑戦的。
しかし、今ではオブジェクト指向のアプローチです。 最初に強調する必要があります
オブジェクト。 さて、これは簡単です。マグカップとロッド、そして砲塔そのものです。
何らかのオブジェクトにメッセージを送信するという形のソリューションが必要です。 何か
のような。

  tower.move（a、b、c） 

素晴らしい。 砲塔、マグカップ、ロッドがあります。 そして、それをすべてまとめる方法
メッセージの送信を通じて？ うーん...後頭部に敬意を払い、一般的なロッドからそれを決める
彼女だけでは問題ないので、1つのチップからも無駄です。
影響します。 砲塔に集中し、カボチャを傷つけて、それを言うことは残っています
砲塔は、2つのオブジェクトで構成されています：上部、
砲塔または欠落している、およびベースの大きな円です。 素晴らしい。
このようにオブジェクトを構築する場合、ソリューションは再び明白です。 砲塔を尋ねる
補助を使用して別のロッドにジャンプし、彼女は
最初に補助ロッドの上部にジャンプするように要求し、次に
ベースをターゲットロッドに移動し、ジャンプするように要求する
このターゲットロッドはその先端です。 さて、今度はいくつかのクラスをロールします。
すべてが回路図であり、Javaに似ています。 すべてのメソッドはオープンであり、データはプライベートです。

クラスタワー{
 // a-これは砲塔が立つロッドで、チェックに便利です
 //タレットが1にある場合、たとえばmove（1、3）などの無効なリクエスト
 //ピボット。  FIGはどのリクエストが来るかを知っているため、信頼性が高く、
 //カプセル化。 しかし、コードにはチェックがありません。
         int N、a;
        タワートップ。

        タワー（N、位置）{
                 N> 1の場合{
                         top =新しいタワー（N-1、a）;
                 }
                その他{
                         top = null;
                 }

                 this.N = N;
                 this.a = a;
         }

        リスト移動（b、c）{// b-移動先、c-補助ロッド
                リストl;

                トップ{
                         l.append（top.move（c、b））;
                 }

                 l.append（a.toString + "->" + b.toString）;

                トップ{
                         l.append（top.move（b、a）;
                 }

                 a = b;  //新しいロッドに移動しました

                 return l;
         }
 }

 //起動
 System.out.print（（new Tower（N、1））。Move（2、3）.toString）;

うわー、それはクールでした。 彼らは優雅さを失いましたが、私たちはクールです
エラーをチェックできるオブジェクトがカプセル化され、
一般的に、すべてとてもかわいい。 疑わしい命令的アプローチ
さらに優雅さをマージし、レンズはきれいになりませんので、
彼は図で、理論的に。 しかし、私たちは歯を食いしばって突破します。
それでは、命令型アプローチには何がありますか？ なし：機能もオブジェクトもありません。
メモリの特定の領域の状態とこれらの変更の説明がない限り
状態。 この状態では、各ディスクに円のリストを作成できます。
うーん...あまり楽観的ではありません。 さて、リストとリストが、それらをどうするか？ うーん...
リスト。 交響詩、エウレカ、私たちはまだいくつかの動きのリストを持っていますが、どれですか？
たとえば、砲塔を2円高く移動するための移動のリストがあります。
2番目から3番目の1番目のロッド：1-> 2、1-> 3、3-> 2。
素晴らしい。 それで何ができますか？ たとえば、列番号を置き換えます。
たとえば、次のようになります。1= 1、2 = 3、3 =2。そして、プログラムを取得して、
2番目のコアの2つの円の農場：1-> 3、1-> 2、3-> 2。
私は何を得ていますか？
今、2レベルの経済を2番目の経済に移行するためのプログラムがあれば
列、3番目に3番目に大きいパンケーキを配置できます。
次に、すでによく知られている2ファームの転送プログラムを使用して、
1番目のロッドを2番目から3番目に置き換え、その中に置換を作成します。
1 = 2、3 = 1、2 = 3、2番目のロッドからの転送プログラムを取得します
3番目から最初。 そして、最終的に私たちは素晴らしいプログラムの所有者になります
3番目のロッドを最初のロッドから3番目のロッドに転送します。 などなど。

このようなプログラムの開発を開始する方法を理解することだけが残っています。 でも
これは明らかです。タレットの高さが奇数の場合、最初の移動が必要です。
ターゲットロッド、それ以外の場合は補助。 書かれたソリューション
iscriptに似たもの。

 nextblock（cmdnew、cmdold、f）{
         a = f [0];  //現在のプログラムはaからbからcまでの順列です
         b = f [1];  //上位N個の円
         c = f [2];

         //（N + 1）円をaからcに移動します
         listappend（cmdnew、{.from = a; .to = b;}）;

         f [0] = b;  // aを介してbからcへの順列を生成します
         f [1] = c;
         f [2] = a;

         i = cmdold.head; 私に;  i = i.next {
                 listappend（cmdnew、{.from = f [i.from]; .to = f [i.to];}）;
         }

         f [0] = a;  //これで、aからcにbまでの順列ができました
         f [1] = c;  //（N + 1）-ファーム
         f [2] = b;
 }

 solve（N、a、b、c）{
         f [0] = a;
         N％2の場合{
                 f [1] = b;
                 f [2] = c; 

         }
        または{
                 f [1] = c;
                 f [2] = b;
         }

         Nで;  N = N-1 {
                 nextblock（fl、sl、f）;
                
                 i = fl.head; 私に;  i = i.next {
                         print（ "％0->％0 \ n"、i.from、i.to）;
                 } 

                 listmove（sl、fl）;  //すべてを最初のリストから2番目のリストに移動します
         }
 }

 solve（16、2、0、1）;

ふむ FPまたはOOPのオプションよりも長くなります。 しかし、このコードとそれらを比較しましょう
2つのオプションがあり、それらは互いに類似していると見なすことができます。 あなたができる注意
いくつかの機能を活用します。
まず、プログラムの生成はすぐに開始され、長時間待つ必要はありません
再帰が終了するまでの時間。これで十分かもしれません
長い間、動きのタスクの複雑さは指数関数的に増大します。 一方、有名な
移動は、さらに並列処理するために送信できます。たとえば、
このまさにハノイのゲームの視覚化プログラム。
第二に、命令型コードは無限のピラミッドで動作することができます。
通常、最初のNを決定する場合を除いて、Nは実際には必要ありません。
移動します。
2つの再帰構造ではこれを行えません。 うーん...少し哲学的
余談：多分これは、再帰的な構造では不可能だからです。
最初の動きとの不確実性。 再帰は常に定義する必要があります。 でも
これは将来の分析のための発言です。
最後に、個人的に私（私は強調します：個人的に、最後の手段の真実について
私はふりをしません）上記の推論は
プログラミングアプローチ。
プログラムは正確に動的システムと見なされる必要があります。つまり、
状態変化によって記述されるシステム。
やってみると
次のように、静的マッピングの形式で機能を定式化する
関数型プログラミング、私たちは自分自身を制限することを余儀なくされています
1.ダイナミクスでは、関数の値を計算する必要があるため、
私たちはそれを使うことができます
2.効率と分布：計算値が潜在的に
完全な計算が完了する前に使用でき、その後
古典的なFP、これを行う方法はありません。
もちろん、これらの問題の解決策が見つかっています。MLには次の機能があります。
命令型プログラム、Haskellには動的命令型のモナドがあります
計算は、値の無限リストをマップします
このダイナミクスの軌跡は、最も便利な解決策ではありません。
プログラムを相互作用するものとして見ようとするとき
特別なインターフェイス、オブジェクト、そして再びダイナミズムを失います。 なぜなら
直感的な表現のオブジェクトは、まったくないプロセスに対応しています。
すべての動的構造ではありません。 この例では、自然
画像（もちろん、私の意見では、多くの教科書によってバックアップされています
OOPでは、同様のタスク、たとえば約8フレーズがこの方法で正確に解決されます）、
オブジェクトが選択されました：タレット。 そして、そのような抽象化が何につながるのかを見る-
再帰アルゴリズムの即時構築、それが意味するすべてのこと
欠点。
もちろん、暗黙的なOOPの場合、ビジュアライザーのデータ生成
再帰が最初の底に達するとすぐに開始できますが、
非常に長い時間それに到達します。 FIの一部として、これも行うことができますが、やや
より紛らわしい。 さらに、私たちはそうではないことを忘れてはなりません
そのように選択されたオブジェクトのシステムでは、無限の砲塔で問題を解決できます。
OOPとFIがプログラマの能力を制限するためです
タスクのダイナミクスを参照してください、個人的に、私はデザインでそれらを使用することはありません。
プログラム内でのデータの流れ方とその方法に焦点を当てます
私の意見では、これはより美しくシンプルになります
決定。 世界はダイナミックだからです
存在しないため、オブジェクトまたは機能よりも物理的現実に近い
オブジェクト、本質的に機能なし。 動的システムのみが試行されます
現代の物理学を私たちに証明してください。 なぜあなたの心を制限する
FPである現実の静的モデルに焦点を当てる
おっと？ 数学的性質によるFP、およびその理由によるOOP
近代的な形は受動的との類推に関する意識を修正する
マテリアルオブジェクト。
公平に言うと、この例では、オブジェクトは
一連の動きを選択し、同様の命令型ソリューションを構築する
プログラム、しかしOOプログラマーは、明白なオブジェクトの検索から始まり、ではなく
設計機能を制限するダイナミクスの分析、
そして、これはしばしば彼に彼らのより類似した決定につながります
FP上の構造。 FPアプローチのフレームワークでは、これは潜在的に
行うことはできますが、はるかに難しく、無限の砲塔を数えることができます
のフレームワーク内で完全に遅延実行される関数型言語でのみ
ただし、ラムダ抽象化の場合、このような計算は計算できません。 また、ところで、
コンピューターはチューリングマシン以上のものであることを証明しています。
さらに、プログラミング言語は同様の設計に傾いていますが、
自分をオブジェクト指向と呼ぶ人。 それらのオブジェクトは
ダイナミックエンティティはメッセージを交換します。
Smalltalk、つまり静的
抽象データ型、これ以上。 独自の動的オブジェクト
人生、それを作成することは非常に困難です。 分散していても抵抗する
テクノロジー、同じCROBA、
リクエストに応じてのみオブジェクトが生き返ります。
実装：個別のスレッドの起動、およびインターフェースを使用した共有データへのアクセス
同期を使用します。 これは、本格的なクライアントサーバーの作成です
出てくるアプリケーション。 しかし、OOPは再びプロセスとしてではなく作成する傾向があります。
しかし、一連のオブジェクトの形で、再び死んで動的ではないことが判明しました
そのコアで。 それらの間の実際のデータフローを整理することは困難です。
並行して実行することは困難です。これは、再度実行する必要があるためです。
サーバー。
その間、純粋に機能的なソリューションとして始まったいくつかの言語は
最終的に進化して、まさにそのようなエンティティを作成する機能を提供しました
-メッセージングプロセス。 ErlangとO'Caml、例ですが、これは
可能性は、これらのほぼ機能的な機能に基づいています
言語：状態を保存するモナドまたは明示的な能力。 きれいに
これによる命令的な構造的アプローチはまったく発生しません。
Limbo、Ada、またはUNIX上のIPCなど。
実際、アピールはこれに基づいています（私だけでなく、
http://www.lysator.liu.se/c/pikestyle.html）OOPとFIをどこでも拒否
データ変更の分析のみに焦点を当てて
プログラム、状態プロパティ、および変更のロジック。
別の
余談：現代の物理学は既存のものを考慮し、それは直感的です
注目することなく、変化の過程で特性を保存することは明らかです
プログラム内のダイナミクスの分析では、保存されたプロパティを正確に識別できません。
したがって、オブジェクト。 このような分析は、より柔軟なソリューションとより効果的なソリューションにつながります。
インターフェース、関数、モジュール、クラスはプロセスで自然に発生します
プログラムの実装。 そして、それらは再利用できます。