  |
はてなキーワード: GOFとは
ソフトウェア開発における名著とされる読みものがある。かつて、そういった著作のエッセンスをひたすら抜き出して黙々とまとめていくはてなダイアリーが存在した。2010 年代のことである。GoF のデザパタ本とか UNIX 哲学とかピープルウェアとかそういうの。ジュンク堂の本棚でいえば「SE 読みもの」というやつだ。業界に入って間もなかった当時の自分は、技術的な相談ができる大人が周囲にいなかった。いま思えば、残業中のオフィスで長いコンパイルを待つあいだ、ぼんやりとこのはてダを読み、目の前のやるせないソースや、所属するチームが置かれた状況について思いを巡らせながら、ガス抜き感覚でこのはてダを読む時間が好きだった。どの項目も歯切れの良い紋切り型の文体で読みやすく、読んでいるうちに不安のかたまりがスルスルと解かれていき、気持ちがラクになるような気がしたのだった。
その後、わたしがアラサーになるころには、そこで紹介されていた大部分の原著は書店で購入し物理的に所持するに至っている。あのはてダがなければ、本屋でも仕事関連の棚で足を止める人間にはなっていなかったのではないかと思う。その後、当時のはてダの内容を抜粋したものが秀和システムで書籍化され出版される運びになった。ファンだったわたしは発売をとても楽しみにしていた。が、本屋に並んだ書籍を手にとってみると、あのはてダにあった宝物のような輝きはすっかり失われていた。なぜかはわからないけれど、説得力が損なわれている気がしたのだった。書籍化の都合、はてダに貼られていた Amazon へのリンクが取り払われ、原著との接続性がいくぶん薄らいでしまったせいかもしれない。またこの書籍化に伴って、はてダも閉鎖されてしまった。もっとも新刊の売上にも関わるだろうし、あの「要約」は原著に対する網羅度がかなり高いもので、権利面ではかなりグレーなものだったように思うから、閉鎖されるのは当然の成り行きだったと言える。が、自分の成長期にあたる年代にあのはてダがあったことは本当にキャリアの上で助けになったと感じているし、原著を所持していてもなおあのはてダを参照したいという思いがあるくらい、とても優れたものだった。他人の「きれいなノート」を借りて勉強していたような感覚というか、そんなような。「新人に読ませたい n 冊の本」というタイトルのクソ記事がもはや春先の業界の風物詩になっているが、そんな記事とは段違いにもっと直接的に本が持つ価値を訴えてくるコンテンツだったのだった、少なくともわたしにとっては。
図解界隈というのが流行っていると聞いて、そんなはてダがあったことを思い出した。結局のところ「SE 読みもの」も自己啓発本に他ならないし、個人的に DDD
なんて宗教だとすら思う。それにしても「要約」がきっかけで世界が広がるとことは実際あるかもしれないよ、ということが伝えたかった。
「研究所流出説」を甦らせた素人ネット調査団、新型コロナの始祖ウイルスを「発見」！｜ニューズウィーク日本版 オフィシャルサイト
武漢研究所は長年、危険なコロナウイルスの機能獲得実験を行っていた｜ニューズウィーク日本版 オフィシャルサイト
ニューズウィークが新型コロナウィルス(SARS-CoV-2)の武漢ウィルス研究所(WIV)起源説をぶち上げているがひどくお粗末だ。
なぜお粗末かと言うと、ほぼデバンク済みの『コロナウィルス人工説』である上にその中でも完全に粉砕されている『RaTG13起源説』を提唱しているからである。
RaTG13は新型コロナウィルス(SARS-CoV-2)と最も近縁だが、これをいじってSARS-CoV-2を作ったという主張は既に反証済みなのだ。
詳しく説明しよう。
SARS-CoV-2とRaTG13のゲノムの相同性は約96%。しかしそれでは遠すぎる。
SARS-CoV-2の最も近い親類は、武漢ウイルス学研究所に保管されていたRaTG13という名前のコウモリウイルスです。このウイルスがSARS-CoV-2の起源であるという根拠のない憶測がいくつかあります。
ただし、
(i) RaTG13はCOVID-19が最初に発生した武漢(湖北省)とは別の省(雲南省)からサンプリングされました。
(ii) SARS-CoV-2とRaTG13の間のゲノム配列の相違のレベルは、平均50年(少なくとも20年)の進化的距離に相当します。
実際、Boni et al. (2020)の推定ではSARS-CoV-2とRaTG13が共通祖先から分岐したのは約39～71年前であった。さらに言えばSARS-CoV-2とRaTG13は祖先と子孫ではなく同じ祖先をもつ兄弟である。
研究室でRaTG13を培養して進化させてもSARS-CoV-2にはならないし、仮になり得るとしてもそれにはうん十年かかる。
WIVがRaTG13を見つける前、何なら研究所設立前から培養してなきゃいけないねえ。
Gain-of-Function research (GOF，機能獲得研究)には培養だけでなくゲノムを切り貼りしたキメラウィルスを作製する方法がある。これだ！
ゲノムを組み替えてキメラウィルスを作った場合、組み替えた部分だけ違っていて他のゲノム領域はほぼ同一になる。仮に組み換え後に培養を経ても変異の分布に痕跡が残る。
しかし、RaTG13とSARS-CoV-2の相違(変異)はゲノム全域にわたりほぼ均等に分布している(Zhou et al., 2020)。これはRaTG13のゲノムを組み替えてSARS-CoV-2を作ったとする主張の決定的な反証である。
これはRaTG13に限った話じゃないが、SARS-CoV-2は近縁のコロナウィルス(CoV)が持っていない特徴をいくつも持っている。
やつのスパイクたんぱくのRBD配列は2019年時点では他に類似の配列を持つものがいなかったし、フューリン多塩基切断部位とO-結合型グリカンも近縁のCoVでは見られなかった。
仮にSARS-CoV-2を研究室で作製するなら、これらの当時未知だった特徴をどうやって組み込んだのか説明できない。
意図的に組み込んだのではなく、培養中に進化して偶然できたと答えようにも、2020年に野生動物(センザンコウ)から発見されたCoVのもつRBD配列はSARS-CoV-2とほぼ同じだったという事実が立ちふさがる。
研究室の選択圧のもと進化した配列が、自然環境下で進化してできたそれと偶然一致するのはまずあり得ない。
あり得たとしても、『自然環境にはSARS-CoV-2に類似した特徴を持つ未知のCoVが色々いる』可能性の方がはるかに高い。
以上から、RaTG13に限らず当時の地球においてSARS-CoV-2を人工的に生み出すためのバックボーンウィルスを人類は持っておらず、このウィルスは自然環境下で進化したものだと考えるのが妥当である(Andersen et al., 2020)、と言うわけだ。
『RaTG13起源説』は科学的に完膚なきまでに粉砕されている陰謀論である。
“証拠がない”ではなく“否定する証拠がある”レベルの仮説である。WIV起源説に好意的な研究者ですら肯定していない。
ニューズウィークの記事の前編のタイトルは『「研究所流出説」を甦らせた素人ネット調査団、新型コロナの始祖ウイルスを「発見」！』であるが、『RaTG13はSARS-CoV-2の始祖ウィルスではない』という科学的事実の前には滑稽と言うしかない。
“「研究所流出説」を甦らせた”と言うのも嘘で、最近のWIVへの追及は『研究所経由説』とでも呼ぶべき新しい(本当は古いけど陰謀論に隠れて無視されてた)説による。
ニューズウィークの記事の前編も後編も、あれが怪しいこれが怪しいと疑惑をてんこ盛りにしていたが、その怪しさを全部『RaTG13起源説』に紐づけしたせいで、台無し。
過激な陰謀論がピックアップされてしまえば、類似のしかし陰謀論とはとても言えない“あり得る仮説”でさえ、十把一絡げに陰謀論扱いされてしまうという危機感を持ってほしい。
『RaTG13起源説』みたいな糞陰謀論で『研究所経由説』をつぶそうとするのはやめてくれ。
Andersen et al. (2020)やLiu et al. (2020)、Hakim (2021)など、SARS-CoV-2を研究室内で作り出すのは合理的に考えれば不可能であることがわかり、初期の雑い陰謀論(含『RaTG13起源説』)はだいたい駆逐された。
そのおかげで『ウィルスは自然起源だが拡散にはWIVが関わっているかもしれない』という元々あった穏当な仮説が台頭してきた。
SARS-CoV-2は野生動物に起源をもつが、WIVの研究員がそれを武漢に持って来たかもしれないと言う説です。厳密に言えば研究所起源の説ではありません。
最近の、WIVを追求する流れは主にこの説が念頭に置かれています。
SARS-CoV-2の起源に関する現在の最有力な仮説は以下ですが、
宿主(起源)：祖先ウィルスの宿主。人との接触が少ない野生動物。コウモリが有力。
↓
中間宿主：人との接触が頻繁な動物。ウィルスを媒介するほか、感染中にウィルスが進化する場合も。SARSの時はハクビシン(有力)、MERSの時はラクダ(確信)、COVID-19では……？
↓
ヒト集団
中間宿主のポジションあるいは中間宿主とヒト集団の間のポジションに“研究員/研究所”を置いたのが研究所経由説です。
『ウィルス探してフィールドワーク。コウモリひしめく洞窟で、SARS-CoV-2に感染して武漢に帰ってきました』と言うわけです。亜種として『サンプルをラボに持ち込んでから流出しちゃった』バージョンもありますが大意は変わりません。
この説の利点は『まったく無理がない』ことです。ウィルス学的なエビデンスと競合することもなければ未知のウィルスをでっちあげる必要もない。
ウィルスに感染しているかもしれない動物やウィルスを含んでいるかもしれないサンプルを採取する立場の人が、その途上でウィルスに感染したかもしれないと言うのは非常に合理的な考えです。
もちろん、食卓に並ぶべく中国各地で採集された野生動物たちによって武漢の生鮮市場にウィルスが持ち込まれた可能性も当然あります。
あるいはミンクなどの家畜の群れでウィルスがサーキュレートしていたかもしれません。
たまたま山歩きをしていた市民がコウモリとバッティング(激うまギャグ)して感染した可能性もあるでしょう。
重要なのは、これが“あり得る仮説”であり、検証が可能であることです。
そう、検証が可能なのです。中国側が研究所職員・学生の血液サンプルや、武漢の血液銀行のサンプル(19年12月より古いやつ)を提供してくれれば、非常に多くのことがわかるはずです。
WIVの職員が皆陰性であれば、選択肢が一つ消え、他の仮説がより確からしくなります。
陽性であれば、その陽性者の行動を追跡することでわかることが多々あります。野外採集には行かず生鮮市場を訪れていれば、感染源は市場かも知れません。野外採集に行っていれば、その行先に祖先ウィルスがいるかもしれません。
あるいはWIVとは関係なく12月よりずっと前からCOVID-19が蔓延していたことが明るみに出るかもしれません。
WHOは19年12月よりずっと前に武漢でCOVID-19のような症状を出した人を見つけました。それも90人以上。
アメリカはWIVの職員3人が11月にCOVID-19のような症状で入院したのを明らかにしました。バイデン大統領は継続調査を求めました。
今、中国やWIVに対しての批判とはつまり、検証への非協力への非難であるともいえましょう。
何故データを出さないのか？出しさえすれば否定できる仮説に対して、何故データを出さずに否定しようとするのか？何を隠しているんだ？HEY！！
『研究所経由説を選択肢から外しはしない』という各国の研究者やWHOの声明は、ほっかむりは許さんぞという宣言なのです。
野生動物起源一本やり(WIVの関与は無視)にすると、どうしたって武漢の血液データへの追及は弱まりますからね。
親愛なるブックマーカー諸氏におきましては、同じラベルでも中身は違いますので糞(『RaTG13起源説』等)も味噌も一緒くたにしてしまわないようお願いいたします。
お前「GoFのデザインパターンが重要であるかのように言うやつムカつく！」って、もう一年ぐらい怒ってるんだな
低レベルから努力してやっと平均かその一段下くらいになっただけの雑魚が「自分は上級者」だと勘違いして偉そうにしているケースが多くて、嫌になる。
たとえば、C言語のポインタが難しいとよく言われる。まあ、中学生や高校生がはじめて学ぶならともかく、あんなもの別に難しくはない（実際のソフトウェアでポインタを適切に使うことは難しい）。
実際、ポインタに躓かなかった人なんかたくさんいて、そういう人の一部はより高度なことをどんどんやっている。一方、ポインタに躓いて努力してやっと最低限のレベルに達したような人が、声を大にして「プログラマになるなら、ポインタくらい理解しないとな」とか言ってる。
プログラミングのセンスのある奴はすぐ見抜けることだが、アレには何の重要性も無い。だが、頭の悪い奴は、あの程度でも苦労しないと覚えられないから、重要だと思ってしまうらしい。これはギャンブルや宗教にハマる心理と同じである。つまり、時間や労力をかけたのだから、その対象にそれに見合う価値があって欲しいと思うわけだ。
頭が悪いと、こういう意味で物事を客観的に見られなくなる。学歴コンプレックスになると、一生そのことを引き摺って、何に関しても学歴と絡めて論じたくなるようなものだ。
今更、こんな本を読む必要はないです。いや、出版された当時でも実質的な価値はなかったと思います。
また、挙げられている23個のパターンには特に根拠はなく、著者が思いついたものを挙げただけです。
Code Completeにも書かれているように、GoFのデザインパターンは使える状況で使えば保守性が上がるというものでありません。たいていの場合は無駄に複雑になるだけです。必要のない場面では使うべきではなく、使って良さそうに見える場面でも、ドメインモデルを再検討した方が良いです。優れたソフトウェア開発者であれば必ずそうします。
GoFを推薦している人というのは、以下の特徴があるように見えます。
実際は、GoFのデザインパターンはほとんど有用ではなく、またまともなプログラマなら仕事の片手間にぺらぺらと読んでいれば、内容も底の浅さも理解できる程度のものでしかないのですが。
これと非常に似たものに、麻雀の点数計算があります。麻雀の点数計算は、普通の知能のある人からは無意味に複雑なものに見えますが、麻雀プレイヤーの多くは合理的なものだと思っているようです。この理由は単純で、大多数の麻雀プレイヤーは頭が悪いからです。だから、点数計算が無意味に複雑なシステムであることが理解できず、また普通の人なら1日で覚えられる点数計算を苦労して覚えたから価値あるものだと思いたがるわけです。
誤解しないでいただきたいのは、「デザインパターン」という概念自体は重要であるということです。しかし、GoFは別に「デザインパターン」の原点とか典型とかでは全くないのです。理解力が低いとそういう勘違いをしてしまうようですが。
クリーンコード、リーダブルコードなど、"美しいコード"を書くための本は知ってるけど、
例えば要件定義とUML図があってその解説をするような、"美しい設計"について書いた本/記事ってよく考えると知らない。
GoFとかのデザインパターンは設計だけど、「どう活用するか？」がメインで、
ある定義の中に埋め込まれた一部としてその姿を解説付きで見たことがない。
整理されたコードを書くことは設計かつ実装だけど、それが全てだったら上流/下流って世間の工程が分かれてる意味って？
「こんな一見勘違いしそうなややこしい要件を、こんな風に設計しました！」っていう例をたくさん見てみたい。
優しく博識な増田さんや、どうぞ教えてくださいな。
http://anond.hatelabo.jp/20130325172822 の続き
言語はJava7を想定。(Java8が迫っていますが、Lambdaなど関数型は、まだ早いと言うことで)
選定理由は、C++と比較して学べるところが大きく、安全でシンプルな言語だから。
※いきなりJavascriptはやめとけ、PHPは論外。
Ruby・Scalaでないのは、筆者が初心者には適切には教えられないから。
おもちゃ・ToyとしてjQueryで遊ぶのは、悪くは無いと思う。
これ以降は名著の紹介や学習方法の紹介が主体となります。名著のコンポジションという形が時間的限界ですね。
量については「初級になるなら、専門書を計3,000ページは修得することは覚悟してね」なんて言ったりしています。
Javaで初級のわかりやすい指標ですと、[amazon:Effective Java]とGoFまでの修得。
初級になるまでに登竜門への挑戦期間を含めて、３~４年はかかっても仕方が無いとも思います。
※逆に「一山いくらのコーダー」というのは、Effctive JavaやGoFが達成している技術も知らずに「自分がJavaプログラマー」だと誤解してしまっているような人達です。
そういったコーダーは何年経とうとも初級プログラマーにすら敵いません。
初級を目指して、プログラミングを楽しんでください。
ただ、学ぶべきことはべらぼうですが、「各分野毎に、エレガントな方法がある。だから探して修得する」ということが大切です。
※「一を聞いて十を知る」ような優秀な人に、50冊くらいドーンと本を置いてあげて、各本の目次を読ませるだけで、
底の見え無さを悟ってくれたりすると、嬉しくなってしまいます。
※余談ですが、その底の見え無さは数学という学問そのものですね。例えば、関数型言語の底流に「圏論」というここ100年の最新の数学があります。
また中級くらいで、Liskovの置換原則などが載っている本を紹介しますが、
そのLiskovの置換原則の周辺で出てくるcovariant(共変)って、圏論という数学の概念だったりします。
数学畑出身としては、数学が現実に活かされている嬉しい事例です。
「速く正確に大量の出力」という能力は、プログラミングをする上でも、ドキュメントを書く上でも、何より「つまらん仕事」の時間圧縮ができるようになるため、重要です。
スローガンとしては「思考のスピードで出力することを目指そう」です。
紹介するエディターはemacsやvimやExcelです。ついでにIMEとしてATOKを使用しているため、ATOKの操作をEmacsライクにする話も紹介します。
ExcelはWindows環境でMeadowすら入れさせてくれない場合の最後の砦という扱いです。
コマンドラインは、「コマンドラインというものがある」「時として非常に強力である」程度の紹介です。
※筆者はzshは全然使えません。使いこなしている方々と接する度に「勉強しなきゃな~、でも、あっちの方を先にやりたい・・・」とグズグズして、はや何年・・・
正規表現は置換を用いて、テキストの一括編集が重要です。後、遭遇したくない事態ですが、スパゲッティコードの解析をする上での最後の砦です。
※遭遇したくない例
ん?何か変なところで副作用のある処理があるようだなぁ(消沈)、SQLのInsertかUpdateか一応Mergeも使っているところから逆算して原因箇所を探すか・・・(諦念)
この糞コードがっ!!こんなところに書くんじゃねぇ!!(憤怒激高)
(ここで、他にやらかしていそうな似たようなコードを正規表現でgrep検索。改行コード込みにすれば複数文検索も可能)
わはは、予想通り共通化すべきロジックのメソッドがそこら中にある・・・
入門編で一つLinkedListというアルゴリズムを学びました。
少なくとも一つ本を読みながら自力でアルゴリズムを学べる人なら、大成できる可能性があります。
前に紹介した[amazon:C++実践プログラミング]には、LikedListやStackなど基本的なアルゴリズムが載っておりますが、
これに加えて、初級になるためにはこれくらいは知っておいて欲しいというものを紹介します。
※後、最初から必ずしも手を出さなくても良い上限も紹介いたします。
プログラムは、データを入力して、加工して出力・保存する処理の繰り返しです。
つまり、各一連の繰り返し毎に、「正しい入力」「正しい出力」を定式化する必要があります。
それを人間の手では無くコンピューターにやらせられるように、つまり自動テストできるようにテストをプログラミングします。
そこで処理の進捗を確認するためにロギングし、処理が想定通りであるかをアサーションでチェックし、
不正な入力・不正な出力=例外が起きたら、対処策をプログラミングします。
(ex 途中で処理を中断して、入力者に適切な入力のメッセージを伝えてあげる。入力の自動補正などもあり得る)
で、ここら辺をまとめてどうあるべきかとして「契約プログラミング」があります。
※余談。定式化・テストに際して、数学畑の人間としては、Javaだとequalsのオーバーライドでも必要になるし、同値関係・同値分割だけでなく、集合論・群論から学んで欲しい・・・(ここいらは数学科の学部１~２年の学習内容)
名著は英語で読みましょう。名著が名著たる由縁は、度々引用されることにあります。
つまり最新の技術書を読むときに、引用された名著のフレーズが、新旧のリンクをなし、理解の助けになります。
壁打ちといって、独り言で思考補助をするよりも遙かに有益です。
※素晴らしい師匠を探すなら、大学行くのが一番ですが、見聞を広げていく中で出会いを待つしかないとも思います。
マルチスレッドが難しいのは「バグを起こしにくいプログラミング」を求められるから。
つまりTry and Errorからの決別が求められ、今後の仕様変更・拡張も踏まえて慎重に慎重にデザインする必要があります。
できる限りステータス変数を持たずに安全に、でもマルチスレッドにするのだから、効率を追求しなければ本末転倒。
でも効率のためにはメモ化に代表されるキャッシングは必須と、アンビバレンツな要素のバランス取りが難しい。
このために、リエントラントな実装・抽象と実装の分離など様々なエッセンスを駆使することが必要です。
というよりも孔子曰く、知っているよりも好きであること。好きであることよりも楽しめることのほうが強く、
気づいたら日々時間が許す限りプログラミングをしてしまうのが理想です。
※仕事として嫌々スキルを磨かなきゃということが、これほど不幸な職業も無いですね。
学習の達成度を測るには、簡単すぎる不適切な問題ですね。
写経は数学の証明問題を、教科書のテンプレ通りに、数値や名称だけ変えて記述することしか出来ない人の発想。
つまり「矛盾無く一貫した論理モデル」の構築が自由に出来ず、テンプレの微修正しか出来ない人の発想。
また、外部の「矛盾無く一貫した論理モデル」の吸収が不自由で、アルゴリズムを「手順」としてしか捉えられないように見受けられる。
「連続」であること確かめるための「ε-Δ論法」(数学科の学部１年の学習内容)
事前知識無く、このモデルを理解できる人は、十分に「矛盾無く一貫した論理モデル」を構築できる人。
１.まず「連続」とは何ぞやと考えて概念を膨らませてください。
これは http://anond.hatelabo.jp/20110316202255 の続編です。
GTをやる前に改を書いてくれている人がいてとてもしっかりした内容なのでちゃんと勉強したい人はそっちを見てね！
d:id:ryoasai:20110317 - ドラゴンボールで学ぶオブジェクト指向 改 | 達人プログラマーを目指して
またオブジェクト指向については
d:id:m-hiyama:20080109 いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ | 檜山正幸のキマイラ飼育記
がとても詳しいです。合わせて読むとかなりしっかりと理解出来ると思います。
ホットエントリに行くとは思っておらず、皆様ありがとうございます。
「ドラゴンボールをオブジェクト指向にする」というコンセプトではなく、「オブジェクト指向を（無理矢理）ドラゴンボールで説明する」という遊びだったので
プログラマーの方々にはツッコミを受けてしまいましたがここは遊びだと思って楽しんで下さい…。
ドラゴンボールは小さい頃から大好きでしたが流石にうるおぼえ過ぎました。
それはさておき「説明する題材を決める→好きな漫画から無理矢理当てはまりそうな例を考える」という思考実験なので、気が向いた方は色々考えてみると楽しいと思います。僕は楽しかったです。
これは難易度が高そうです。
やっぱりドラゴンボールで例えると分かりやすいな！
無理がある！
デザインパターンとはドクターゲロが考えた「こうやって設計すれば色々捗るぞ」という例のことです。実際はGoFという人たちが考えたもので23個のよくあるパターンに名前を付けて整理してくれたわけですね。
23個の中にはブルマさんですらわからないものが多いので（さすがドクターゲロですね）良く使う、代表的な物をいくつか紹介します
Singletonは世界に一つだけしか存在出来ないようにする方法です。
balls = new DragonBalls(); //これでは誰でもドラゴンボールを作れてしまう！ balls.callShenron();
クラスの中にはいくつかのメソッドがありますが、簡単に言うと外から呼べるもの、外からでは呼べないものの
二種類があります。そうやってメソッドを保護することで世界の崩壊を防ぐわけですね。
基本的な戦闘力をアップさせるには本人の努力が必要になり、外から簡単に挙げられてしまうとジャンプの三本柱が外れてしまいます。
ただナメック星の最長老や界王神などはかなり偉いので、本人の才能を引き出すことが可能でした。
現実には思いつきのような仕様を後から言われることが多々あります。困ります。
//地球上にひとつだけ存在するドラゴンボールをつくろう class DragonBalls{ private DragonBalls(){ //ドラゴンボールを作れないように生成メソッドを保護します。 } static function sagasouze(){ static singleton_dragonball; //ドラゴンボールを生成。 //DragonBallsクラスの中なので、保護してある「new DragonBalls()」を呼べます。 if(!singleton_dragonball)singleton_dragonball = new DragonBalls(); return singleton_dragonball; } }
地球のみんなは地球語しか話せませんが、ナメック星にいるクリリンを通して願いを叶える必要があります。
クリリンももちろん地球語しか話せませんが、ナメック語を話せるデンデがいるため、地球のみんなは願いを叶えることが出来ます。
class Kuririn{ private dende = new Dende(); function request( wish1, wish2, wisth3){ this.dende.request(wish1); this.dende.request(wish2); this.dende.request(wish3); } } kuririn.request( "ピッコロを生き返らせてくれ", "ピッコロをナメック星へとワープさせてくれ", "ナメック星にいる孫悟空とフリーザ以外を全員地球へとワープさせる" );
この場合のメリットはデンデが何をやっているかクリリンをプログラミングした人が知る必要が無いということです。
地球の人はナメック星にいるナメック星人が「デンデ」であることを知る必要もありません。
それでも願いは叶うんです。
本来であればデンデやクリリンは願いが叶うのを待つ必要がありましたが、地球の人は一気に伝えることが可能なように設計しました。
//デンデクラス。ナメック星人は英語でNamekianらしいです。 class Dende extends Namekian{ function translate(word){ namekian = *****//ナメック語に翻訳します。 return namekian; } function request(wish){ static polunga; if(!polunga){ polunga = DragonBalls.spell("タッカラプト ポッポルンガ プリピット パロ"); } polunga.ask(this.trasnlate(wish)); } }
大まかなアルゴリズムだけ決めておいて、実装はサブクラスに任せる設計がTemplate Methodです。
ナメック星に行く方法を考えた時いくつかの方法がありました。古い宇宙船を探してきて直して載せて…っていちいち書くより同じメソッドでナメック星に行けたほうが便利ですね。
abstract class WayToNamek{ abstract function prepareSpaceShip(); abstract function launchSpaceShip( ship ) ; function gotoSU839045YX( people ){ ship = prepareSpaceShip( ); //船を修理します ship.load(people); //人を載せます this.launchSpaceShip(ship); //船を出発します。 } }
ナメック星に行く方法を定義したので「ブルマ、クリリン、悟飯」組と「悟空」をそれぞれナメック星に連れて行きましょう。
way = new WayWithKamisamaShip(); way.gotoSU839045YX( buruma, kuririn, gohan ); way = new WayWithSaiyajinShip(); way.gotoSU839045YX( goku );
と簡単に方位SU83、距離9045YXまで乗員を連れて行くことが出来ます。
二つの方法を実装します。神様の船を修理して行く方法と、サイヤ人の船(悟空が乗ってきた船)で行く方法の二つです。
//神様の船で行きます。 class WayWithKamisamaShip extends WayToNamek{ function prepareSpaceShip(){ return new KamisamaShip(); //船を準備します。神様の船を使います。 } function launchSpaceShip(ship){ ship.inputByVoice("ナメック星に出発"); // } } class WayWithSaiyajinShip extends WayToNamek{ function prepareSpaceShip(){ return new SaiyajinShip(); //船を準備します。サイヤ人の船(フリーザの船？)を使います。 } function launchSpaceShip(ship){ //audio = new HighSpecAudio(); //ship.setAudio(audio); ship.turnOnCenterButton(); //真ん中のボタンを押すだけ } }
元になる船も違いますし、発射の仕方も違いますが同じ呼び出し方が出来ます。
オーディオの位置が決まりませんでしたが、今回の運用では不要とのクライアントからのご意見でしたのでだったので
せっかく用意したオーディオも無駄になりましたが、コメントアウトしてあります。
手順を考えて、その手順を書くだけ。
言語もあらかじめ決められた手順に沿って解析されて実行されるから、オートマトンやBNF記法、構文木などの仕組みを一通り覚えてどういう機構でチューリングマシンが原理的に実行可能なコードへと落とされるかを理解すれば言語自体も覚えるのなんてそんなに難しくない。
手順を考えるなんて、人間が生活する上でいつもやっていること。
プログラムを走らせるためのデータ構造を考えるのに苦労するという話も聞くけど、プリミティブな要素が数値、型へのリファレンス値しかないんだから大体は離散数学で使うグラフの初歩的な知識があれば事足りる。GoFのデザインパターンなんてまさにそう。
これらは、専門用語の知識は知らなくても概念としては理解できて当たり前の事だから書けることもそれほどすごい事ではない。
