  |
はてなキーワード: カプセル化とは
名前空間とは何でしょう?
広義の「名前空間」とは、項目をカプセル化するもののことです。
たとえば、たいていの OS はディレクトリでファイルをグループ化します。
この場合、ディレクトリがその中のファイルの名前空間として機能しています。
具体的に言うと、foo.txt というファイルは /home/greg と /home/other の両方に存在することが可能ですが、それらふたつの foo.txt を同じディレクトリに配置することはできません。
さらに、/home/greg ディレクトリの外から foo.txt にアクセスするには、ディレクトリ名をファイル名の前につけて /home/greg/foo.txt としなければなりません。
プログラミングの世界における名前空間も、この延長線上にあります。
名前空間を定義するには、namespaceキーワードの後に任意の空間名を記述します。
namespace 名前空間名;
まあ終了自体は仕方ない。このゲームはゲームと言うには余りに大きな設計ミスを抱えすぎており、また、システム的にもかなり古くなっている。
だいぶ前からオンラインゲーム終了時にどうするか、という話はあるけど、あまり進展はない（ソシャゲ、ネトゲ等のサービス終了後のゲームの保存について考える、とか、米国でサービス終了オンラインゲームを著作権法例外とする動き―ESAは反対とか）。一つ根本的な問題として、本当にオンラインが重要なゲームはオフラインモードに余り意味がないのも大きい。
逆に、ゲームとしてのサービスが終わろうが俺には見たいエロシーンがあるんだよ！
anond:20190209083051 とかでも書かれていたけど、エロの質はいいし、ここにしかないものも多い。しかもそれは(ゲーム上で)自分が苦労して手に入れたものだ。勝手に閉じてほしくない。
……けど、運営コストを考えたらそうも言ってられないのはよく分かる。
自分入手した分のデータをダウンロードして、後は各人がローカルPCで再生すればいい。
必要な機能は大きく分けて、サーバからデータをダウンロードしてくる部分、それからデータ（カードやエロシーン）を閲覧するパートだ。
ちなみにこのゲームは初期に作られただけあって(?)、エロシーンに機能が少なく、BGV はおろか BGM も無い。オーバレイも１枚のみで、基本的に背景(シーン画像含む)と、テキストに 1:1 対応するボイスしかない。
これなら割とできそうな気がしたので保存・再生するソフトウェアを書いてみることにした。
https://aakeeper.appspot.com 驚くほどあっさりできてしまった。
でも、今はできた物自体の話はいい。それより作る過程で色々感動したのでその話をしたい。
今回使ったのはざっくり以下のもの
Quasar Framework も Node.js も Electron も使うのははじめて、他はちょっと触ったことあるけどそんな詳しくない。 ES もあまり好きでなかったので基本的には避けてきた。
Quasar Framework は、とにかく物凄くよく出来ていてびっくりした。今回 Electron モードしか使っていないけど、本来はこれで SPA/PWA/モバイル(Cordova) アプリケーションが作れるという凄まじい対応幅のプラットフォームになっている。着手時に 1.0beta の予告だけあるというタイミングの悪さ(数日後に出た)だったので、 0.17 系を使った。しかし、それでも十分すぎるほどよく出来ている。
ES は今でも嫌いな点は多いんだけど、今回 async/await を使って感動した。これは素晴らしい。他の言語にも欲しい。
CoffeeScript は趣味だけど、とにかく短く書ける点が素晴らしい。あれは終わったという人もいるが、記述量の少なさは js 系では他の追従を一切許していない。今回みたいな急いでいるケースでは、括弧の世話を焼いたり eslint おばさんと語り合う時間はない。CoffeeScript ならコンパイラが全部上手くやってくれる。
HTML5 ベースの GUI は今や chronium の各種アクセラレーションのおかげで、並のポータブル GUI ツールキットよりずっと高速に動作する。
また、Vue.js + pug は非常に記述量が小さくて目的の画面がすぐ作れ、カプセル化がしやすくコンポーネントの再利用も容易だ。
Babel/Webpack は正にバッドノウハウを煮詰めて固めた感じだが、こいつがバッドな部分を吸収してくれるおかげで開発者は正気を保てる。ただし追求しだすとSAN値が減る。
ユーザ側から見ると、Electron 製のアプリはメモリをやたら喰う、少しもっさりしている、配布バイナリが巨大になるという問題は確かにある。
しかし、そうだとしても何より、とてつもなく高速に作れて、各種プラットフォームで割とちゃんと動く。
自分は色々初めてだったので結局２週間分くらい掛かったけど、前提知識が揃っている人なら本当に数日でできたりするんじゃなかろうか。
つい数年前まで、クロスプラットフォームなアプリケーションの作成というのは本当に本当に大仕事だった。こんなに早く手軽に書ける事は無かったし、ユーザ側でもラインタイムのインストールが必要とか環境側のハードルも非常に高かった。
自分は今まで知らなかったけど、最早そういう時代は終わっていた。
もちろん過去に数多くのクロスプラットフォームフレームワークが登場しては消えていったのと同じく、Electron もいつかその仲間入りをするだろう。
でも確実に、びっくりするくらい状況は良くなっている。
興味があるけどまだ触ってないという人は、ぜひ試して感動を味わってもらいたい。
コンピュータのマシン語は命令文もデータも数値で表す。これは今も昔も同じ。
数値だけでは人間が管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ。
複数の処理をひとまとめで扱うサブルーチン・関数・プロシージャ・ファンクションと
いったものができた。
（カプセル化）
アプリケーションからOSの機能を呼ぶシステムコール・APIが生まれた
（ブラックボックス化）
複数のクラスやコード、データをひとまとめにするにモジュールができた。
（カプセル化）
プログラムを外部から操作するRPC、CORBA、SOAP、RMIができた。
IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。
（ブラックボックス化）
（操作の簡略化）
Docker でWEB/DB/KVSなどをまとめてコマンド１つで扱えるようになった。
週末の書店。
プログラミングコーナーに行くと、いつもうんざりした気分になる。
何故ってこんなに入門書が溢れかえっているのに、何一つとして入門者向けの本が無いからだ。
日本の書籍小売の総本山、神保町は三省堂書店の棚の端から端まで見た所で、ビギナー向けの本などありはしない。
なぜなら、入門書を謳っている本のコードはほとんどが動かないコードだからだ。
入門書だと言うのに、ページを割くべきところに文章やイラストを割かない本が多すぎる。
例えばポインタ、コンストラクタ、インスタンス、カプセル化…それぞれの概念。
イラストの入門書だってそうだ。「入門」と書いてあるからといって、開いてみればデッサンや形のとり方を教える本などありはしない。
そう、日本の入門書とは「元々デキる人がリメディアルとして持っておく本」のことであり、「ビギナー向けのウェルカム本」ではないのである。
だからといって、誰もがpythonの専門家になる胎教を受けて産まれるわけではないし、誰もが10代で写真と見まごうスケッチを描けるわけではない。
では、その「デキる人」は誰に教わったのか？やはりデキる人たちや、海外の入門書を車座になって読んで学習したのである。
しかし、その「始祖・デキる人」がヒーローの時代とは、今とは複雑度合いも、求められるものも違う。
今は学生であっても、ある程度の高度な成果（ここでは、ネットで発表したものがネットニュースでバズった経験や、学会で評価された経験のこと）があって始めて企業の受験票でしかない。
なぜ入門者向けの本がないのか？
習うより慣れろ。仕事は見て盗め。教えられるのを待っているな。・・・
自分より出来ないやつに教えるのが大嫌いなのだ。（入門書の著者ですらそうなのだ！）
上にあるように、ある程度デキる人でないと、その手の会社には認められない。
だからといって、大学教育で手ほどきを受けられるわけではない。これもある程度デキる人向けなのだ。
では、書籍で自助努力を、となっても、文頭にあるように、入門書向けの本など無く。
では、デキる人はどこにいる？これもやはり雲の上の大学にしかいない・・・
今はネットがある？これも難しい。
知恵袋や、teratailであっても、初心者に与えられる答えは「ググレカス」のみ。
では、ネットにジャストな回答があるか？といえば・・・ない。基本的には公式リファレンスのコピーや、動かないコードしかない。
デキる人は、デキない人の気持がわからない。何がわからないのかわからない。
だからあいつらがわからないのは、あいつらが勉強不足だから、と考える。
わからないのは、あいつらの自己責任だ。だから初心者は嫌なんだ。となる。
適性を測っている、という見方もある。
しかし、適性というものは基本的にやらなければわからないもので、やる前の教育から放棄しているのは適性を測るというより、
日本人の初心者軽視、というか教育軽視は今に始まったことではない。
「失敗の本質」でもそれは指摘されている。ということは戦時から既に教育嫌いなのだ。
職場でもそう。教えられるのを待っているな、と言っておいて、いざ聞きに行けば「常識でわかるだろ」「ネットで調べて」「リファレンスマニュアル調べて」
学校でもそうだ。
授業の勉強も予習が前提。では授業ではより高度な話をするのか？しない。教師我流の演習である。
演習するだけならば、家や図書館で黒本や赤本を解いていたほうがマシじゃないか！
学校教育ですらこうだ。
現役ペチパーだけど、元々PHPはHTMLにスクリプトを埋め込むところから始まった変態言語なので、
普通に関数を作って組み合わせてしまえば大半は事足りるのも当然なんだけども。
実務で使うと便利だなと思うのは、まとまりのある複数の変数とメソッドを1つのクラスにカプセル化できること。
例えば、ユーザの情報を管理するときに、「ユーザ情報」というクラスを作って、
その中に publicな変数として、名前、フリガナ、郵便番号、住所、電話番号、会員ID、階級、職業、性別…
を放り込んでおく。
同時に、ユーザ情報の処理に関連する処理の関数を public なメソッドとして、定義する。
ユーザ情報をタブ区切りで得るメソッド getTABDATA()
フォーム入力からユーザ情報にセットする setFromForm()
こうしておけば、
・ユーザ情報を何かの関数に渡す時は、インスタンスの変数1つ渡せば済む。
・ユーザ情報に関する処理は、ユーザ情報クラスの定義部を観れば済む。
という２大メリットが得られる。
メソッドだって１つのファイルに関数並べてインクルードすれば同じメリットが得られるやん？
…と私も思ってた。ただねぇ、開発規模が大きくなると、関数名の重複を避けた命名が面倒になったり、
連想配列だと好きな場所で勝手に変数増やされたりして、メンテナンス性が悪くなるのね。
あとは、例えばメールを送るという１つの大きな処理に関連して複数の関数を定義する場合に、
その関数をまとめてメール送信クラスとしてしまうのはあるかな。
http://web-terminal.blogspot.jp/2014/04/php-file-mail-pear.html
PHPでエクセル出力できるPHPExcelもクラスになっているから使いやすそう。
http://qiita.com/suin/items/7a8d0979b7675d6fd05b
http://cmf.ohtanz.com/blog/archives/2463
結論としては、
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
CIツールを使って、常にcheckstyleでも走らせておけばいいんじゃないかな。今時、そんなのは人間様が労働力を割かなきゃいけないお仕事じゃないよ。
残りの「不注意やミス」をなんとかしたいなら、それこそ「高機能な」言語を使うべきだよ。
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
横だけど、これ何の話してるんだろ？
つまり、「生産性の高い言語」は、人間の不注意やミスを言語処理系の側で防止したり、影響範囲を最小限にしてくれるということ。
これを無邪気に言い放つ人とは一緒に仕事したくないわ、とだけ言っておきますよ。
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
そこに意識的にならないと、そもそも議論の出発点にすら立ってない。
Javaの場合、ユーザのフィードバックにより成熟したライブラリやツール群を、多くの場合無料で利用できるのがメリットと言える。
手続き型言語をやっていると、データを組み合わせて取り扱う必要が出てくる。
例えば、顧客のデータを扱う必要があるとき、顧客の「名前、住所、所属、電話番号、取引内容...」などをまとめて取扱いたい。
そこで、構造体という発想が出てくる。
構造体を扱っていると、新しく顧客データを作るとき、毎回毎回、作った後に同じ動作をしないといけないことに気づく。
そしたら、それをいっぺんにやってしまうために関数を作ることになるだろう。
init_customer(struct Customer*, char* name, char* addr, char* tel)
また、逆に顧客データが不要になったとき、メモリ解放などをさせるために、
delete_customer(struct Customer*)
も作ることになるだろう。
さらに、取引を行うたびに、取引データを追加しないといけない。そのために、このような関数を作るだろう。
add_deal_customer(struct Customer*, char* deal_name, char* deal_ammount)
そして、複数人でプログラムを作っていると
「おいおい！せっかく取引データ追加用のadd_deal_customer作ったのに、なんで自分で勝手に追加してるんだよ！てか、その方法だとメモリ解放どうすんの？ちゃんと作ったの使ってくれたら、delete_customer()でできるようになってるのに」
って状況が生じうる。それを防止するために、コメントに
「/* 取引データの追加は必ずadd_deal_customerを使うこと！ */」
と書くことになるだろう。
てか、わざわざコメント書いたのにこいつ読んでねーし。あーあ、めんどくさいめんどくさい。
そこで、だ。言語を少し別のものにかえて、構造体に関数を持たせられるようにしよう。
そして、構造体ができたときに、自動でinitって関数を、削除されるときに、自動でdelって関数を呼ぶとしよう。
そして、add_deal_customerも構造体の中に入れてしまおう。名前は長くて面倒なので、
Customer.add_deal(char* deal_name, char* deal_ammount)
のようにしてしまおう。
さらに、add_dealを使わずに直接、取引データを追加しやがるならず者対策も付け加えてしまおう。
privateにした変数は、構造体が持ってる関数からしか、いじくれないようにしてやろう。
今まではコメント読まない馬鹿の世話に苦労していたのだが、これからはコンパイラがそういうやつにエラーを出してくれる。
次は継承のお話。話は変わって、今度はGUIパーツで説明する。
ボタンってあるよね。あれを作りたい。
普通に文字が書いてあって押したら何かが起こるボタン、アイコンが描いてあって押したら何かが起こるボタン、
この２つを作りたい。
まず、文字のボタンを作ろう。
関数を持てる構造体を作り、「表示する文字(変数)、クリックしたときの動作を定義する関数へのポインタ(変数)、描画命令が出た時に描画する関数(関数)、クリック命令を受け取り、構造体にセットされた関数へのポインタを呼び出す関数(関数)」
がいるかな。
次に、アイコンのボタン。「表示するアイコン(変数)、クリックしたときの動作を定義する関数へのポインタ(変数)、描画命令が出た時に描画する関数(関数)、クリック命令を受け取り、構造体にセットされた関数へのポインタを呼び出す関数(関数)」
あ、さっき作ったのとほぼ同じじゃーん！文字ボタンの構造体をコピペしちゃえ！
あとは文字の変数を、アイコンに変えて、描画命令を、文字描画からアイコン描画に変えればできるじゃん！
ところが、文字ボタンのクリック命令を受け取る関数にバグが見つかった！よし、デバッグできた！
けど、アイコンのボタンにコピペしてたんだった！またコピペしなおしじゃん。あーめんどくさ。
もしそれ以外に、チェックボックスのボタンとか、もっと別のボタンとか、いろいろコピペで作ってたらもっとめんどくさ。
そこで、こんなことができたらいいんじゃないか？
文字ボタンにも、アイコンのボタンにも共通する、関数をもった構造体を作っておく。
ボタンの構造体「クリックしたときの動作を定義する関数へのポインタ(変数)、クリック命令を受け取り、構造体にセットされた関数へのポインタを呼び出す関数(関数)」
そして、文字ボタンは、ボタンの構造体に「表示する文字(変数)、描画命令が出た時に描画する関数(関数)」を、
アイコンのボタンは、ボタンの構造体に「表示するアイコン(変数)、描画命令が出た時に描画する関数(関数)」を追加すればいいんだ。
これを、継承と呼ぶ。
さらに、文字ボタンもアイコンのボタンも、同じ「ボタンの構造体」を持っているから、どっちも同じ「ボタン」として扱うことができる。
後で画面内のボタンを全部解放する必要があるときとか、実はこれ、すごく便利。
別の構造体で扱っていたら、文字ボタン用の配列とアイコンボタン用の配列を用意し、それぞれに作ったボタンをいれ、解放するときはそれぞれの配列の中身を解放しないといけない。めんどくさ。
けど、どっちもボタンを継承しているから、ボタンの配列を用意して、文字ボタンもアイコンボタンも全部同じ配列に入れて、１つの配列の中身を解放したらいい。楽ちん。
はい、そうすると、関数を持った構造体はもはや、もとの構造体とは違う感じになりました。
これをクラスと呼びましょう。クラスから作られたデータは、オブジェクトと呼びましょう。
なんか、オブジェクトがほかのオブジェクトから独立してカプセル化されてるみたいですね。
そして、オブジェクトが持ってる関数。メソッドとでも呼びましょうか。これ、まるでオブジェクトが自分のやりたいことを知っているかのようです。
手続きを構造体や関数に細かく分離していくにつれて、構造体と関数の組み合わせってのが出てきて、まとまりが見えてくるのです。
そいつらをまとめてしまって、一つの部品として扱って、外からはあんまり部品の中身を見えないようにしましょう。
部品の中身を直接いじらせるんじゃなくて、部品をいじらせるための関数を用意して、それを経由してやってもらいましょう。
それが、カプセル化とかいうやつです。
開発効率性を重要視するか、モジュールとしての錬度を重要視するのか、それが問題だ。ここで一つの提案をする。
開発途上において、どの変数を private にすべきで、どの変数に getter が必要で、どの変数に setter が必要で、
どの関数を private にすべきなのかを悩んでいては、本当に重要なところ、つまりアルゴリズムに時間をかけられない。
まずは、アジャイルプロトタイピングをするのだ。その時にカプセル化に頭を悩ますのは良い方法ではない。
コードでやることが決まった後、それをモジュール、ライブラリとして完成度をあげるリファクタリングの段階で、
カプセル化、クラス、関数名、関数の再利用性について頭を悩ますのが効率が良い。
ただし、イケプログラマに限る。
ダメプログラマにやらせると、アジャイルプロトタイピングの段階で、全ての処理が１つの関数に書いてあるなどということになりうる。
類似の処理がほぼコピペということになりうる。リファクタリングの作業が、もはやリファクタリングではなく、リストラクチューリングになりうる。
