約 5,854,553 件
https://w.atwiki.jp/cs013059/pages/96.html
オブジェクト指向論 担当者名 丸山 勝久 教授 シラバス オンラインシラバス 講義資料 Webページ http //www.fse.cs.ritsumei.ac.jp/lesson/oo/ レポート課題 kadai.pdf quiz-1025.pdf quiz-1123.pdf answer-1025.pdf answer-1123.pdf レジュメ oo2006.pdf テスト test1.pdf test2.pdf test3.pdf test4.pdf test5.pdf test6.pdf
https://w.atwiki.jp/akitatnp/pages/59.html
オブジェクト指向講座 プログラムを勉強する上で何処かしらで出てくる「オブジェクト指向」。 ネットとか本で調べても難解な解説ばかりでよく分からない! という人のために「出来る限り実践で役に立ち、かつ簡単に」なるように 作った(つもり)の解説文章置き場です。 PDF形式で作成したもののを置いておきますので、 各項目をクリックし、「ファイルを開く」から見てください。 まだ未完成ですが、今後作る講義の内容(予定)も置いておきます・・・ 第一回 手続き型言語とオブジェクト指向言語 かんたん!手続き型言語 "恐怖の"オブジェクト指向言語 手続き型言語の限界 オブジェクト指向のメリット・デメリット オブジェクト指向言語には何がある? 第二回 オブジェクト指向の基本 ~ クラスとインスタンス そもそも「オブジェクト」って? 簡単なオブジェクトの例 クラスとインスタンス 第三回 オブジェクト指向の基本 ~ メッセージとメソッド メッセージを渡す メソッドを使ってみよう モノには個性がある 第四回 簡単なゲームを作ってみよう @近日公開予定 どんなクラスが必要? クラス同士の関連 見せたいもの、見せたくないもの
https://w.atwiki.jp/amakozen/pages/6.html
パターン名 説明 補足 Strategy 一連のアルゴリズムを定義し、それぞれをカプセル化して、それらを交換可能にする。Strategyパターンによって、アルゴリズムを使用するクライアントとは独立して、アルゴリズムを変更できる - Observer オブジェクト間の1対多の依存関係を定義し、あるオブジェクトの状態が変化すると、それに依存しているすべてのオブジェクトが自動的に通知され更新られるようにする put型とpull型がある
https://w.atwiki.jp/alicecode12/pages/696.html
『正統王国』所属機『正統王国 その他』『ホワイトレディ家』 『ナイト・オブ・ラウンズ』 『情報同盟』所属機『情報同盟 その他』『ナンバーズ計画』 『オブジェクトにおけるバリア装甲の研究』 『情報同盟深海軍』 『資本企業』所属機『資本企業 その他』『島国』 『アリスシステム』 『ナナシリーズ』 『アルカナ』 『ヤナギカゲ重工』 『プロメテウスインダストリー』 『プライベートオブジェクト』 『マグノリアファクトリー』 『マレブランケ』 『信心組織』所属機『信心組織 その他』『ゾディアックサイン』 『旧アルジェリア大戦』 『黙示録の四騎士』 その他の所属機『プロメテウスインダストリー』 『個人』 『PMC』 『とある財閥』 『ジェネシス』 『WOU』 『電脳技術団』 『アマノハバキリ』 『大陸』 『不成竜』 『光芒』 『シンギュラリティ超越AI』 『アルカネシア共和国』 『アナゲンネーシス』 『所属不明機』 ※登場巻よりも所属を優先してます。おかげで巻ごとの分類がされていないため見辛くなっています。許して 『正統王国』所属機 アースシェイカー ブラストブレイカー イエーガーシューター ランドスマッシャー アイアンハート バードキラー スフィアローラー ラストマイン ホエールスナイプ モーニングツリー ストライクワイバーン パニッシュフィーバー シャークヘッド スパークボンバー ルームドット パールネックレス チェインボルト エッジビートル ジャックポッド ソードエクスカリバー アースリベレーターズ グラスレイヤー エースピッチャー ネックチョッパー レッドパージ ラージシールダー バレットアトモスフィア マゾヒストスノー ストームブリンガー オールドパラディン ポポフポポフカ シンボルブレイク カーネイジスマッシャー アイスエイジ オーシャンイーター 『正統王国 その他』 ホワイトクリストキント リバーシブルランナー オブジェクト ヌル フファールパンケーキ クーゲルクローラー タップダンサー ダンスホール ムーンシャイン スカルクラッシャー クリフハート スレッジハマー アステリズム オーケストラウォーズ ケイオスカワード メイクアップ ダブルピース ホワイトアウト ツインハーモニー インセクトバスケット フローズンチュチュ ブレイブストライカー ディープスロート 『ホワイトレディ家』 コルコバード ゴールデンデイズ 『ナイト・オブ・ラウンズ』 コールブランド ヴァリーペネトレイター キャプチャーダイバー ギガントフォース ガラティーンレイザー アロンダイトブレイズ ロバストスニーカー アサルトランサー ヴォーパルバニー フェイルノートスカイ レゾナンスハウリング クラレントディスオベイ テスタメントグレイル 『情報同盟』所属機 バシレウス004 パルス220 オーソリティ001 クリエイト005 インビジブル014 シノビ971 ライトニング777 スラッシャー011 シムーン389 ブレイズ069 ネスト535 プレッシャー140 サイレン266 チューイングテスト013 キネシス241 スプリンター919 タンク064 エクスプロージョン000 ダイニング909 ボマー153 ウィップ221 スクラッチ541 ハンド655 マンカインド001 デザイア006 グライディング283 ダート109 『情報同盟 その他』 ■■ ヤプー097 ウォーゼット999 エンケ315 カタパルト496 オーロラ921 バルカン345 スクエア444 リスタート635 ログハウス606 ミクロスコピック064 ファーマー878 ノックアウト321 ドラゴンキラー900 マリオネット110/じょうるり オイド030 スイーツハザード648 『ナンバーズ計画』 トゥルーアイズ001i(イマジナリー) パラドックス002 ウェブ004 ルックアウト005 エリミネーター009 ジ・アース100 エンピレオ444 クリティシズム555 マスターキー666 ジオグラフ888 シャオリン999 『オブジェクトにおけるバリア装甲の研究』 クリッカー655 スクリーン147 ウラニウム235 カルクルス339 チャンバー594 シクヴァル703 ホログラム551 ドップラー205 トロープス179 クリティシズム555※所属被りあり 『情報同盟深海軍』 ダイバー701 バルバスバウ702 シクヴァル703※所属被りあり ベイトボール704 コムーナ705 ラブカ706 カイメン707 マリンスノー708 メルビレイ709 ベント710 ネーレウス711 フルディプス920 カンブリアン819 ロパリウム660 ノイズ168 イリジウム650 アイ108/ゆらひめ ジオグラフ888※所属被りあり クラックル671 マリアナ983 『資本企業』所属機 エリーゼ イスラデピノス リリアン カルメン アナスタシア シャーロット カトレア クラリス メルセデス リリウム マリアンヌ アンネ クララ セリーヌ キャロライン アンナマリー エスター アンジェリーク エヴリン サラ ミナ アマンダ シェンユェ コーデリア モイラ ワレンチナ マルヴィナ ゼノビア ミリンダ ユイカ 『資本企業 その他』 プリシラ コーデリア 黙娘 アデリーナ アリシア コンスタンツェ エルルーン PPO-003Ω-Y ミュルミドーン 『島国』 タチカゼ おとひめ みょう すぎ おりひめ ぬかひめ あやめ まいひめ まつ、たけ、うめ いなほ 『アリスシステム』 アリス(オーバーディメンション) 『ナナシリーズ』 カサンドラ 『アルカナ』 セリーヌ ラプンツェル ソフィア シンデレラ タバサ イヴ アントワネット パンドラ シャルロット マリア サロメ 『ヤナギカゲ重工』 ジャンクヘッド キルキンチュ ヘッジホッグボマー サンジャオロン スティンクディール ナァールウァル サヘラントロプス ヒレンソウオウ サーベラス アトロシアス フロントフォートレス(グレイライノ) ミラーボール901(ルーシオル) リンファ(リャンロン) ガネーシャ(オーリファント) キロネックス デンデンマイマイ フリルドリザード ホゥトーロン フローレイティア セイアジン ベルナデッタ ジラソール キニョンガ ウカキーラ ポルコスピーノ サンタテレサ ディアトリマ 『プロメテウスインダストリー』 アンダージョーズ ダモクレス 『プライベートオブジェクト』 アイリス スターキャッチャー Solar-Eater Plan-A Project:Star-Cradle 『マグノリアファクトリー』 アルシア DCO-001ψ 九龍 ADO-007η ブランカ NTW-026Ξ ニヴルヘイム 『マレブランケ』 マラコーダ スカルミリオーネ バルバリッチャ カニャッツォ リビコッコ チリアット ファルファレルロ ルビカンテ グラッフィアカーネ アリキーノ カルカブリーナ ドラギニャッツォ 『信心組織』所属機 ギャラルホルン(オールドジェネレーション) ガイア(エッジストーン) クラウ・ソラス(ソードライン) アイギス(ミラーハウス) オニャンコポン(オーソドックス) セラフィム ドミニオン パラダイス ミネルヴァ モイライ アズライール スレイプニル オーガ エインヘリアル サキエル ウリエル シーシュポース タムブーヤ フラガラッハ カマエル イレーネ ウラノス オシリス コントン オリオン ディオスクロイ トリウィア カオス 『信心組織 その他』 エイヤフィアトラ アクロティリ マクガニン マステマ 大羿/ダーイー 驪竜/ヘイロン スグルド ガルダ シェムハザ サイリーチ スキュラ サテュロス マバン テミス ジャガーマン フォルトゥーナ 『ゾディアックサイン』 アリエス ゴズ メタトロン/サンダルフォン カルキノス ナラシンハ イルマタル アストライア セルケト ケイローン ヘイズルーン ヴァッサーマン オーケアニス アスクレピオス 『旧アルジェリア大戦』 キマイラ バステト スケープゴート アナンタ 『黙示録の四騎士』 ホワイトライダー レッドライダー ブラックライダー ペイルライダー その他の所属機 『プロメテウスインダストリー』 インドミナス アンダージョーズ 『個人』 キジンテンユウ 『PMC』 グングニル 『とある財閥』 アタラクシア:α 『ジェネシス』 テトラグラマトン 『WOU』 テスカトリポカ アズールドミネーター 『電脳技術団』 ハイドラ 『アマノハバキリ』 アマノイワト フツノミタマ 『大陸』 玉龍/イーロン 九色鹿/クシキカ 霊亀 刑天 爬钩/パーゴゥ 相柳 『不成竜』 贔屓/ヒキ 螭吻/チフン 蒲牢/ホロウ 狴犴/ヘイカン 饕餮/トウテツ 𧈢𧏡/ハカ 睚眦/ガイサイ 狻猊/サンゲイ 椒図/ショウズ 囚牛 嘲風 負屓 螭首 『光芒』 太極 蒼竜 绝命 『シンギュラリティ超越AI』 ボーダーブレイカー ビヨンドオブホライズン 『アルカネシア共和国』 バニラジョーカー 『アナゲンネーシス』 ガンシュリンプ ウェーブストライカー サハクィエル デーヴァローカ アドナイ 『所属不明機』 エスペラント
https://w.atwiki.jp/imops-forth/pages/32.html
Mops言語のオブジェクトシステムにはどんな効果があるのか Forthのオブジェクト指向拡張は数多くある。実は、forthで言語の仕様を変更するのは容易なのである。初心者から一歩踏み出したあたりで、言語実装がforthプログラミングの課題となってくる、とさえいえるほどである。結局は、それでforthにおけるどのような問題が解かれるのかにかかってくる。 Mops言語のオブジェクト指向はNEONモデルといわれる構文を基としている。これは、forthのオブジェクト指向拡張としては最も早期のもののひとつである。実際には現時点でのMopsのオブジェクト指向特性は起源からもうかなり離れてしまっている。とはいえ極めて古い時代の設計が基礎となっていることは否定できない。ところが、偶然ではあろうが、驚くべきことに、比較的近年になって初めて注目された新しい着眼点とみなされている事柄についても、既に簡明な解答が与えられているように見える場合がある。(もっとも、forth系では、このような時間軸のねじれはよくあることだが。) というわけで、ある程度の期間Mopsのオブジェクトシステムの中でコードを書き、さらに、それを実装してみた経験から、このシステムが見せるいくつかの側面について、実装方法も含めて説明し、解明を試みることにしたい。Mopsのシステムはそれほど錯雑したものではないが、その効果は簡単には説明できないほど奥深いのである。これは、分析的個別問題解決指向が強烈なforthがその背景にあることも関連していると思われるが、その話はここでは触れない。 形式論理位階によるオブジェクト指向分類の試み Mopsのオブジェクト指向は、動的プログラミングを求めるということを主としていないように思われる。つまり、コンパイル時に行うことを実行時まで延期するという手段によって、メッセージ伝送という局所的な部分で"柔軟性"を得ることには、可能ではあるが、あまり腐心していない。というのも、それだけなら素のforthで十分に事足りるからである。つまり、xtを保存して入れ替えながら実行すれば良いのである。実際、xtをvTableに整理して特定のデータ構造と結びつけるだけで、"動的な"オブジェクト指向機能を導入できるのである。その程度ならば、アルゴリズムとデータ構造に関する入門レベルで簡単に実現できる。Forthの強みである。生のままのForthでできることを主たる利点としてオブジェクト指向システムを導入しようとするのは、無駄であるかナンセンスである。 クラスとそのメソッドを定義するというところまでは、MopsのOOシステムも、標準的にみられる機能をでていない。「できること」を表にして比べると、どうということはない印象になってしまう。Mops OOシステムの驚くべき特性は、そこからうかがい知ることはできない。その特性というのは、実はインスタンス変数と呼ばれる対象の仕様の差異から生じてくるのである。 First Order OO System 実用を考慮したオブジェクト指向システムの議論を見ると、インスタンスとして観念されるのは、属性データの塊という趣が強い。インスタンス変数をフィールドと呼んだりスロット — 全てがリストであるとする見方に相応しい — と呼んだりすることに、その思考前提が垣間見られる。そういった属性データの塊が、その上に稼働するメソッドと組になってクラスインスタンスを構成し、上位クラスに特有のデータ塊は、下位クラスの属性データの部分集合を成すことで引き継がれる。上位クラスのメソッドは、データ塊の部分集合に動作するものとして引き継がれ、下位クラスは追加的な属性データの上にもメソッドを持つことによって、上位クラスを拡張、変形するのである。 このようなオブジェクト指向システムは、具体的インスタンスの属性データを第0オーダー、その類型を定めるクラスとデータを操作する関数としてのメソッドを第1オーダーとみれば、形式論理でいうファーストオーダーシステムを形成していると見ることができる。変数と関数からなる特にオブジェクト指向システムを持たない手続的プログラムと、大差はない。データ指向であること、つまり、属性は違うが同類のデータを持つインスタンスを求心点として、その上のプロセスが集められ、編成されているというところが、オブジェクト指向の処理プロセス指向とは異なる点、ということになるだろう。 構成素(Objects) 位階(Logical Order) データワード(Variable, Value, Array etc.) 0階(the 0th order) 実行ワード(Executable words (colon-definition etc.) ) 1階(the first order) クラスインスタンス(Class instances) 0階(the 0th order) メソッド(methods) 1階(the first order) クラス(Class (prototype)) 2(1.5)階(the second or 1.5th order) 継承(inheritance) 3 (2.5)階 (the third order or 2.5th order) この数え方で、クラスはセカンドオーダーになる。クラスというオブジェクトが眼に見える形で導入されなくても、インスタンスを中心にメソッドが編成される形が、クローンなどで複製できれば十分である。クラスは数値を返さないので関数ではない。しかし、関数を対象として編成する。見方によっては、インスタンスの求めに応じて関数を返すメタ関数とみることもできる。インスタンスと関数を結びつけるのである。その意味で、クラスの論理階数は関数の1つ上になる。とはいえ、一方の端であるインスタンスがデータの塊として0次オーダーで考えられているのが、ややバランスが悪い。この点からみれば、ここではクラスはむしろ1.5階程度に止まっているというべきかもしれない。 Second Orderは「2次」と訳す人もあるようだが、数学ではかなり昔から「階」と訳していたと思う。まあ、分かればどっちでも良いが。 俗な言い方では、階が上がる毎に、いわゆる「メタ階層」に移行するという話である。 このような形のセカンドオーダーオブジェクトが導入されることが、オブジェクト指向によるプログラミングの革新の出発点であろう。 したがって、このレベルでもオブジェクト指向のプログラミングは可能であるが、そこで実際に新しくできるようになることは、あまり多くない。中心的なことは、関数がインスタンスをコンテキストとして持つことができるようになること、であろう。つまり、ひとつの名前で特定される関数が、それに付け加えられるインスタンスのコンテキストに応じて、様々な動作をするということである。ドグマ的に発想すれば大したことのようにも思われるが、実用上は、別のクラスが同じ名前のメソッドを持ちうるというだけの話で、画期的に有用かというと、それほどでもない。 そこで、このオーダーからはみ出さない頭で考えて、なお有用性を強調しようとすると、処理手順を「動的に」組み合わせ変更できるという方向がひとつある。その方向に行くと「Late Bindはオブジェクト指向を便利なものにするには必須」とかいいだすのである。 それどころか「動的」なものはオブジェクト指向的とか言い出すに至っては、知能崩壊としかいいようがない。そこまでいうことはないか。 実際、動的束縛が便利な局面というのはある。けれども、forthで考えると「屋上屋を架す」の類にしか感じられないのである。特別に静的にガッチリと固めなければならない言語であればメリットも感じられるのだろうが。 この方向をもっと伸ばそうとすると、インスタンスの個別的特性に応じて、前処理や後処理を追加したり、処理の順番を変えたりできるような手段があればいい、ということになる。MOPの議論はこの方向でオプションを追加しようという話を含んでいる。ここまでくると、確かに、かなり「動的」という感じは出てくる。逆に言えば、これくらいできないと、例えばLISPなどでは、オブジェクト指向の機構を利用する意味が感じられなかったのではないかと想像される。 抽象的論理平面で考えると、そのような個々のメソッドの束ね方の操作可能性は、1階要素同士の関係を操作しようとするものである。この点で、ここに至って初めて額面通りのセカンドオーダー領域が拓かれたともいえる。つまり、インスタンスは0階という認識のままである「アカデミックな」オブジェクト指向理論では、クラスは中途半端な第2階に止まってしまうので、MOP云々で初めてキッチリ第2階といえるレベルが導入された、ということになるのである。 それでも、ここまでは、ファーストオーダーのオブジェクト指向の発想の中に止まっていてもできる。 クラスないしタイプを経由した、ファーストオーダーのデータとしてのメソッドの結合関係を前提としつつ、その組を対象単位として、組同士を関連づける機構は、セカンドオーダーといってよいと思われる。そのような機構を操作してどうするかを考えるのがセカンドオーダーのオブジェクト指向、というわけである。 言い方が抽象的になってしまったが、セカンドオーダーOOのための機構といえる最も馴染みのあるものは、実は、継承(Inheritance)であることに気づく。継承は、クラスとクラスの関係を操作するものである。その意味で継承はもっとも古典的な第3階要素である。その内容は、内部構造の複製と追加的変形修正である。 Second Order OO System けれども、継承はもともと静的な秩序を指向する制約的な手段である。その本質上、窮屈なのである。その結果、上に書いたような「オブジェクト=属性データ」思考では、継承はクラスの構成にめり込んでしまい、より高い抽象度の操作性を持つことができないのである。 そこで、もっとカジュアルに使える第3階要素が求められるわけだが、ここに、ちょっと、その歴史的展開に関する話を挿入してみたい。 構造思考脱落の歴史 継承の制約 継承はこれまでにないプログラム操作の手段を与えたものなわけで、初期のオブジェクト指向プログラムの関心が、継承の機能に集中していたように見えるのも、無理もないことなのである。ところが、そこに落とし穴があったことは、多分、今では誰でも知っている話である。その穴を埋めようとした結果として、新機能が続々と出てきて追加されることになったわけである。この過程で、継承、特に多重継承は悪玉に仕立てられてしまった。けれども実際に問題だったのは、継承が発生してきた背景をすっ飛ばして、売りのための「高度なfeature」だけを追求する姿勢だったのだと思う。 継承からの逸脱、そして離脱 継承は階層構造を構成する。それは、静的なデータ構造と序列関係を基礎としている。あるクラスが他のクラスを継承するとすれば、それは核部分に同じ静的構造を持っているからである。そのことがデータ処理の効率をも高める。そのように、継承はその由来から見ても、静的でカッチリと固まった構造を設計する思考を伴うはずのものである。柔軟で動的な処理を支える堅固な骨格のような。 ところが、複数の関数を束ね合わせるための方法が継承ぐらいしかなかったため、「便利な機能を他所から持ってくる」というだけの発想で継承が扱われ始めた。あれもこれもと、便利そうなメソッドを獲得するために多重継承、という話になった。けれども、継承はもともとそんなものではなかった。特に多重継承は構造が複雑になるのだから、予め静的に設計した上で統合するべきものである。だから、あれもこれもというご都合主義発想に向かないのは当然である。(逆にキチンと設計すれば大したことではなく、多重継承の難点などというのは架空の抽象論でしかないのだが、プログラマーは行き当たりばったり人種なのである。そしてformal指向のアカデミズムは「任意に選択した — つまりデタラメの — 場合の問題」を真剣に論ずる。結果、真面目な人ほど「原理的に」騙される。) もっとも、データ構造に関しても元々動的で緩い種類の言語では、継承も、初めから機能を引っ張ってくるということでしかなかったのだろう。 とはいうものの、異なるタイプ間でメソッドを結合する方法は継承しかなかった。そんなわけで、オブジェクト指向の「新機能」は、当初は「継承を迂回する方法」という体裁で主張されることが多かったのだろう。 delegateでさえ「継承を回避することができる」とかいわれるらしい。継承が負担過剰だったことは明らかである。 継承経由でなく、例えば、友だち同士ならば使えるメソッドをつくるとか、逆に、下位クラスにも使わせないメソッドをつくるとか、あれこれ方法はあった。けれども、決定的だったのは、多分、mix-inであろうと思う。 mixin,Traits etc. mixinは、自分の理解する所によれば、継承関係にないクラスを横から持ってきて、そのクラスのメソッドも混ぜて1つにまとめてしまう方法である。謳い文句は「多重継承なしでも他クラスのメソッドが使える」。実際、そこでの問題は、機能的なまとまりを構成する関数とデータを束ねること、であって、整合的な構造系列の構築などではないのである。だから必要な処理手続を横から借りてきて集めるという方法が、もっとも直接的な問題の解法であるように思われる。 けれども、mixinは横から借りてきたメソッドも、筒抜けに利用できるようにするものである。すると、メソッド名の衝突をどう解決するかという問題が生ずる。同じ名前のメソッドが、上位クラスから継承されたものにも、mixinされた複数のクラスにも、また、当のクラスでオーバーライドされたものとしても存在する、ということがあり得る。そこは、まあ、常識的に優先順位はつくように思うが、メッセージを送るコードを書く側から見ると、ちょっと不安である。デフォルト順位をかいくぐる方法とかも考えると、かなりややこしい。とすれば、mixinしたクラスのメソッドは筒抜けにはせず、なにか特別に符牒を付けてアクセスする方が、多少、文字数は増えても、読み書きの際に何をしているのか分り易く、メンテナンスも容易なのではないか、とも思えてくる。 それはともあれ、必要なメソッドを継承関係の無い脇道から引いてくるというのは、アスペクトがナンタラという考え方に繋がっていると思われる。 Mopsのインスタンス変数特性 上のような展開と対比して初めて気づいたことなのだが、Mopsのインスタンス変数の性格は、プログラミング上に特異な効果をもたらしている。インスタンス変数は、普通は、クラスインスタンスの内部データの1つ1つを指す。Mopsでもこの点に違いはないのだが、そのインスタンス変数は、単なるデータではなくて、他のクラスのインスタンスなのである。呼び名としてはインスタンス変数というものの、NEWされたオブジェクトのレファレンスを格納する変数ではない。名前で特定されるインスタンスそれ自体が埋め込まれているのである。したがって、継承系列外のクラスのインスタンス変数を追加するだけで、その外部クラスのメソッドが当クラスの機能に追加されるのである。インスタンス変数へのメソッド束縛は原則として静的であるから、実行速度のペナルティーもない。したがって、インスタンス変数を宣言することは、クラスの中に他のクラスの機能を埋め込むことであり、クラスインスタンスにとっては、その中に別のクラスのインスタンスの機能を埋め込むことになるのである。 ただし、インスタンス変数のメソッドはmix-inの場合ように筒抜けにはならない。クラスのメソッド定義から、インスタンス変数にメッセージを送ることで、その機能を利用するのである。したがって、定義クラスがインスタンス変数のクラスの特性を持つようになるのではなく、インスタンス変数のクラスの機能が定義クラスのプライベートな内部機能として追加される、ということである。インスタンス変数は、全く独立に動作できるインスタンスではあるが、存在としては当のクラスの内部的機能にはめ込まれている。クラス定義が、次第にハイレベル機能のモジュール作成という特性を強めてくる。これは、アスペクト指向とかいわれているものの基本であるように思われる。この機能の実装は1980年代の初め頃から存在することになるわけだが、あまりそういう観点から見られることはなかったようである。 一般論では、現在でも、クラスのインスタンス変数宣言部分はベタなデータの格納庫づくりとして捉えられ、結果、インスタンスも実態は付属データの塊とされ、関数部分であるメソッドの操作のところにだけ、何かハイレベルな特性を求めようとする発想が、まだ主流ではないかと思われる。いずれにせよ、Mopsのオブジェクト指向の強みは、その発想を超えた所にある。標語的にいえばコンポジションによるモジュラーなコーディングである。インスタンス化は、そのモジュールを現実に生産することである。 これはオブジェクト指向思想の基本であったと思われるが、現実には、そこに到達しているものは以前は乏しかったのかも知れない。 それがいつまでも怪しいOO教説本が尽きない理由かも知れない。商業的宣伝と技術的解明は区別されなければならないはずのものと思うが、 電子技術系での混同傾向は昔から強く、近年は特に甚だしいように思われる。 さて、このような機能を考えると、各構成素の論理的位階が若干変わってくる。 クラスインスタンスは、属性データの塊としての0階要素から、文字通り処理機能を兼ね備えた具体的動作主として、1階要素に持ち上がる。すると、メソッドとインスタンスを関連づけるクラスは、1階要素を対象として操作するという意味で正式に2階要素と見ることができるようになる。 加えて、クラス内で行われるインスタンス変数のコンポジションは、クラス機能同士を束ねるという意味で、第3階要素と見ることができる。 構成素(Objects) 位階(Logical Order) データワード(Variable, Value, Array etc.) 0階(the 0th order) 実行ワード(Executable words (colon-definition etc.) ) 1階(the first order) クラスインスタンス(Class instances) 1階(the 1st order) メソッド(methods) 1階(the first order) クラス(Class (type)) 2階(the second order) クラス -- インスタンス変数宣言(Ivars declaration) 3階(the third order) 継承(inheritance) 3階ないし3.5階?(the third or 3.5th order) このとき、継承は、合成されたインスタンス変数機能を引き継ぎ操作するのであるから、第4階といえないこともないが、構造的設計が必要であることを考えれば、「操作」といえるほどのものでもない。 つまり主張の要点は、Mopsでは、クラス定義がある種のメタクラス定義の特性を持つということである。もっとも、例えば、Rubyなどの新しいオブジェクト指向言語には、多分、同じように解釈できる機構が備わっているであろう。今ではおそらく、特別に先進的な機能ではないだろう。しかし、逆に言えば、MopsのOOシステムの意味が理解される条件が今やっと整ったといえるのではなかろうか。 「背景思考」と実際のコーディング 便利な機能を強調する宣伝思考では、オブジェクトの見方などはどうでもよい話のように思われるだろう。ところが、人様の話を読んだり聞いたりしていると、意外にそうでもないらしいことが分るのである。 継承系列 まずは、実証的な方向から述べてみよう。 Mopsのオブジェクトシステムでコードを書いていると、継承を使う場面とインスタンス変数を使う場面を使い分けることを考えるようになる。インスタンス変数が文字通りインスタンスが持つことになる変数フィールドでしかない言語仕様では、継承とインスタンス変数が機能的に重なるという意識を持つことはないのではあるまいか。 「継承」の原語は「Inheritance」である。系譜学(Genealogy)風の用語であり、「何かが引き継がれる」イメージで理解される傾向にあるように思われる。それで間違いということはないのであるが、クラスを用いて構造的に定義していく仕様では、実はむしろ階層的類別に近いものと考えるべきであろう。クラスの系譜を下ることは、むしろ一般から特殊へと降りてくることであって、親から子へ代々受け継がれる属性というのとは微妙に異なるのである。後者は、むしろ、プロトタイプ-クローン型のオブジェクト指向の発想であろう。もっとも「既存の便利な機能をあれこれ借りてくる」という発想は、どちらとも完全には適合できない。 そのようなわけで、Mopsのオブジェクトシステムでプログラミングする場合、継承は、下位クラスが上位クラスの機能的特殊化であるといえる場合に採用されることになる。機能の豊富化ではないのである。機能の豊富化にはインスタンス変数の追加が利用される。これはいわば異化作用である。 その結果の一つとして、やたらと長い継承系列が無くなる。必要なくなるのである。 小さな変異なら、同じクラス内でも扱える。それはforthの機能を用いて容易にできる。 他のオブジェクト指向言語でも、おそらく、mixin機能がついてきたところで、継承の負担軽減が現実に可能になったのではないかと憶測される。(そして、「継承を使うのはヘタクソ」みたいなスローガンが作られたであろうことは想像に難くない(実際は知らないが)。) ともかく、上の段に書いたような一般的基準は、コードの構成を考える上でかなり明確な手掛かりになる。 例えば、FILEというようなクラスがあったとして、新しく定義しようとするクラスがファイルを扱う機能を持つとする。そのとき、新しいクラスのインスタンスは、何かファイルといえるようなモノ(対象)であるかどうか、が問題となる。それがある種のファイルであるという場合には、継承すればよい。そうではなくて、別のものだがファイルと密接に関わるものであるというなら、インスタンス変数としてFileを持てばよいのである。 Mopsでは経験からごく当たり前のことである。実際には自分はオブジェクト指向云々を学校とか本とかでキチンと勉強したことなどない。ごく断片的な話と実地でどう考えるかとの組み合わせで思ったことを書いているのだが、お勉強方面でも基本は同じ議論をしているようにも見える。しかも、どうも一般にはかなり応用に入り込んだ話で、理論として勉強して初めてそこに到るものであるらしい。いや、まあ、それは人にもよるのだろうが。それに、自分の見方が全く根本的に間違っているという可能性も捨て切れない。そこは読者諸氏の賢明な判断に委ねざるを得ないわけであるが。 オブジェクトのCompositionという発想 オブジェクト指向の死から Mopsのプログラミングに慣れると、オブジェクトの合成(Composition)という見方を自然にするようになる。いつも必要になるわけではないが、プログラムでインターフェイスになるような最終生産物的対象は、大抵、そんな感じになる。 ところが、一般に流れている話を見ると違和感を覚えるのは、その合成の発想が、オブジェクトではなく、メソッドのcompositionであるということなのである。つまり関数指向、あるいは、プロシージャー指向である。有意義な作用をするのはいつもプロシージャーであってデータではないからでもあろうし、アカデミクス方面での主流が関数型思考だからでもあろう。しかし、これは、オブジェクト指向の死でもある。 というのは、オブジェクト指向の基礎的な考え方は、次のような表式で表されているはずだからである: データ構造+アルゴリズム=プログラム(モジュール)=オブジェクト; プロシジャー指向は、データ構造をすっ飛ばして、処理アルゴリズムだけを考えるコマンド型モデルへの回帰である。モジュラーとか構造型とかいう話の以前の、最古のプログラミング観への退行である。 もっとも、データ構造というのは、コンピューターという機械の機構から出てくる観念である。つまり、計算理論も含めて数学とは無縁のものである。私見としては、そこにソフトウェア科学の工学としての重要な1側面があったと考えるが、数学で数値計算だけを考えると、確かに、データ構造って何?という話になる。邪魔になるだけであるのならば、データ構造の発想など捨ててもかまわない、ということになる。それを捨てても、「手数(てかず)を減らす」という発想は工学的な部分として残るから、学域としての独自性は保つことができる(多分)、と。すると、プログラムは、パブリックとかプライベートとか符牒をつけるだけで区別されたことになるコマンドの集まりを、適宜束ねて扱うものとなる。結局、総体が手続型のモジュール形成、例えば、動的ライブラリの構築とかに還元されてしまう。オブジェクト指向の死である。最も旧式の手続指向が自分たちこそ「最新鋭の」オブジェクト指向だと主張することも可能になっている。プログラミングの歴史は手続指向の圧勝である、ということにでもなるのだろうか。 実際、オブジェクト指向というとき一般に考えられているのはオブジェクトライブラリーの提供である。 そのようなオブジェクト指向は、プログラミングの方法であるというより、プログラミングしないで済ます方法である。生産的手段というより消費材である。 確かに便利だが、そのような便宜提供にはオブジェクトは不要である。マシンのプログラムを学ぶためには、むしろ有害であろう。 機械の仕組みはこの数十年基本的に変わっていない。にもかかわらず、データ構造という概念が捨象できるようになった理由は、おそらく、データの低廉化だろう。それはメモリーが安価になったという量的な意味で低廉化と同時に読み書きの高速化という処理時間的な低廉化が同時進行したことである。そこで起こったのは、データ構造の抽象ではなく捨象である。データの形の流動化、あるいは不定形化である。もちろん、機械に落とす所では不定形なままでは処理できないから、プログラム構成の段階で不定形なデータは、コンパイル時か実行時か、何処かの段階で決まった形を与えないといけない。それがかつては大変な手間であったのが、今では、実行時にそれをしても、体感上は特に問題が無いほどになってしまった。もっとも、本体の処理量が膨大で、ともかく高速で直接的な処理が必要になる場合には、実行時の特定というのは問題にならない。するとコンパイルには膨大な時間がかかることが多いが、それは一回きりなので、よいのである。 このメモリーの低廉化と処理速度向上の話は、プロシージャーの意味での「動的」処理の実用化という話に限定して語られがちであるが、そこで得られた実際の成果というのは、むしろ、データ構造という思考の破砕であると思われる。 形式論理との対応を常に意識していた関数型言語では当初からデータ構造の流動化を指向していたように見えるのは興味深い論点だが、 ここではあまり関係ないのでやめておくことにする。 とはいえ、機械の動作にはデータ構造の思考がなお有効なのである。そして、よく考えれば、人の思考、とくに科学的というか学問的な水準でキッチリと考えようとすると、何かを名指すものの形式構造について意識する必要があることが多いのである(タイプ論はその(やや表面的な)複製である)。素人の物知りと本格的な研究者とを分けているのは大体その点であり、構造無視のゆえに、知識が豊富でもトンデモナイ話に引っ掛かったり、素っ頓狂な話を信じて主張したりすることが多いのである(この危険は、現状では専門家とか学識経験者にまである)。これは機械の構造とは違うものだが、現実に基づくという際のインターフェイス部分の問題として何か象徴的な連関が感じられるのである。計算理論方面では、データは所詮は数値と言うことで均質で不定形なデータを扱うことで済んでいるのではあるが。 ソフトウェアというのが、機械と人とをつないで人が機械を簡潔かつ的確にコントロールできるようにすることを課題としているものだと考えれば、多様な要請に対して機械をキチンと誤りなく制御するためには、データ構造という思考自体は、今も不可欠であると思う。iMopsのドキュメントに、「ExactでRobustな処理のためには構造的思考は今も必要だ」と書いたのは、だいたいそういう趣旨である。だから私見としては、オブジェクト指向、つまり、データ構造とアルゴリズムをきっちりと組み合わせたプログラムをモジュール化したものとしてのオブジェクト、という考え方は、まだ死ぬべきではないと思うのである。...が、... オブジェクト参照変数との異質性 インスタンス変数は、他クラスのインスタンスでもあり得るべきである。そうすれば、新クラスはメタクラスのように機能できるのである。 (もっとも、基本がforthであることもまた、この作用のために重要な要素であると思われるが。) ところが、インスタンス変数を属性データの塊として規定してしまう思考からは、その意味が理解できないようである。「インスタンス変数はオブジェクトの参照を格納するポインタ変数であることもできるのだから、そんなことは当然できる」というのである。加えて、そのような参照はランタイムに入れ替えることもできるのだから、より動的であって優れている、と。Forthプログラマーでさえも概してそう思うようである。 「動的(ダイナミック)」云々はナントカの一つ覚え的で、何でも動的ならば良いというものでもなかろうが、それは別としても、確かに、オブジェクト参照をインスタンス変数として用いることで、少なくとも機能的には同じ結果が得られるようにも思われる。 しかし、オブジェクト参照をインスタンス変数にできないオブジェクト指向言語は存在するのだろうか?多分、大抵のものでは可能なのではないかと思う。では、なぜ、mixinのような特殊機能が歓迎されたのだろうか? かつて、SmalltalkとMopsの双方に詳しい知人に尋ねてみたことがある。すると、インスタンス変数は基本的にオブジェクト自体というよりその参照変数であり、基本データ以外のクラスのインスタンス変数では長いメッセージ系列には実行速度の点でペナルティーがあるなど、あまり便利ではないということであった。ひょっとすると、いちいちインスタンス変数にコンストラクタを呼ばないといけないのかもしれない(良く知らない)。 しかし、思うに、これは、システムの機能というかfacultyやfeatureの問題ではないのである。プログラム構成の基本思想の問題なのである。 オブジェクト参照の変数としてのインスタンス変数という発想からは、クラス定義が諸クラスのバンドルとコンポジションになりうるという考えが、多分、出てこないのである。インスタンスのデータフィールドあるいはスロットには他クラスのオブジェクトの参照も格納できる、というだけでは、まだ何か違った観点に立っているのである。 Mopsにもオブジェクト参照という特別なオブジェクトがある。これは、通常は他所で生成されたインスタンスのベースアドレスを格納する。インスタンス変数にすることもできるが、その場合も、外部からインスタンスを格納するか、特別にNEWしないと、コンテンツが欠けた状態に止まる。この機構は、メッセージを受けるオブジェクトを流動化しつつ無名オブジェクトの束縛を効率化するために事後に導入されたものだが、もし、初めからこれだけがインスタンス変数として許されていたならと想像すれば、確かに、インスタンス変数宣言がコンポジションの一翼を担うという考えは出てこなかったかも知れない、と思う。 すると、ごく部分的なものでしかない他クラスインスタンスの埋め込みというインスタンス変数宣言の仕組みが、プログラムの構成の仕方や言語の総合的セマンティクスを転換する効果を持った、ということかも知れない。 単純に言語の断片的機能や能力の一つとしてみれば、確かに大したことではないのである。 実際にMopsでコードを書いていても、必ずしもコンポジションとしては考えない人もいるようではある。 これはしかし、ある程度の経験というか、その変容を自分の感覚で感じ取る機会がないと、なかなかわからないようなのである。 あるいは、政治的な理由でわからないふりをしているだけかも知れないが。 結語 インスタンスを属性の塊にとどめてメタ方向に延ばしていこうとはせず、プロシジャーないし関数としてのメソッドの動的組み合わせ可能性に集中するオブジェクト観では、インスタンスは、単に、メソッドを選択するコンテキストでしかなくなる。もっといえば、インスタンスは、vtableの切り替えスイッチでしかない。そして、どれだけ多くのタイミングでスイッチ切り替えの機会が与えられているか、ということが誇られるのである。見たまえ、ダイナミックだろ、と。 オブジェクト(と呼べるもの)があること、とか、各要素がオブジェクトであることが重要なのではない。そのような名目には何の価値もない。重要なのは、それがプログラミングにもたらす機能である。機能とは特定局面で使える道具的便宜に限られるものではない。とくにオブジェクト指向システムのような機構にとっては、プログラム構造的なレベルに、その主要な機能があるはずのものである。私見では、クラスシステムであろうがプロトタイプシステムであろうが、コンポジションによるモジュールの逐次的拡大ができないものは、オブジェクト指向システムと呼ぶに値しないし、そのような発想でプログラムを組み立てたことのない人は、オブジェクト指向プログラミングの経験はないのだというべきではないか、とさえ思う。 Mops言語の観点からは、まとまったモジュールの構成と、その構成の意味付けに関する抽象化の能力を高めることが、最重要の関心事である。ダイナミック云々は、モジュールの機能的完結性とコードの再利用可能性などの点から、必要に応じて対応できればそれでよい。実際、可変性や柔軟性の面では、コードをデータとして扱い、適宜実行できるforthの仕組みによって、既に十分に与えられているように思われるからだ。 小さく機能的にまとまったモジュールとしてのワードをキチンと組み上げていく、というのが、Mopsの基底言語であるforthの流儀であるとすれば、MopsのOOシステムは、機能単位としてのモジュールの意味的抽象化能力を一定方向に更に高めているという点で有効なのだ、と考えるのがMopsプログラマーとしての観点である、と思う。 これが、おそらく、他のページでも書いた、Mopsのオブジェクト指向が、forthの発想の自然な(ただしある特定方向へでしかないが)拡張のように感じられる根底にある思想なのだ。 結局、Mopsのオブジェクト指向は、forthが本来持っているモジュラリティーの思想を基に、より複雑な固有データ構造をモジュールに追加して組み合わせることを可能にし、結果として、機能的な意味単位としてのモジュールの抽象度を螺旋状に高めることを可能にしているのである。
https://w.atwiki.jp/objectivec/pages/14.html
オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方。 英語の object-oriented (直訳は、「対象物志向の」・「目的重視の」という意味の形容詞) の日本語訳。
https://w.atwiki.jp/abenben18/pages/27.html
デザインパターン 読み方 デザインパターン GoFデザインパターン 01 Abstract Factory 02 Adapter 03 Bridge 04 Builder 05 Chain Of Responsibility 06 Command 07 Composite 08 Decorator 09 Facade 10 Factory Method 11 Flyweight 12 Interpreter 13 Iterator 14 Mediator 15 Memento 16 Observer 17 Prototype 18 Proxy 19 Singleton 20 State 21 Strategy 22 Template Method 23 Visitor
https://w.atwiki.jp/alicecode12/pages/452.html
オブジェクト ヌル スペック表 正式名称 Object Null 分類 海上専用第二世代 用途 ジオタグ調整用恒久係留兵器 所属 『正統王国』『君主議会』 位置 『ギニア湾』『ヌル島』『緯度0度、経度0度』 全長 400m 最高速度 0km/h 推進機関 強化複合コンクリート 装甲 5cm厚×1000積層 電磁環流式結晶粒微細化極彩重金属結晶板 主砲 なし 副砲 なし 搭乗者 フラン=エンジェルズキッス その他 メインカラーリング: 解説 機体の約1/4以上がオニオン装甲であり、海上で不動であることが求められた異形。 『君主議会』が世界に威信を示すために建造した極彩色の結晶、巨大な宝石のように見えるオブジェクト。 装甲に採用された「電磁環流式結晶粒微細化極彩重金属結晶板」は一枚5cmの厚さの分厚い極彩色の金属結晶板。 ローレンクロイツ力によってオブジェクト主砲を逸らす電磁バリアと強力な電磁波によって周辺機器を悉く破壊する電磁装甲の両方を採用。 かつ基板プリント技術を問題なく稼働させるために電磁環流式を採用。これによって軽く触れれば金属でも吹き飛ぶほどのエネルギーを常に装甲に流している。 これを可能にしたのは重金属粒子を粒微細化して一枚でも戦車砲を弾く硬さを獲得し、執拗なまでにそれを重ねたもの。 おかげで「もし、彗星が直撃しても中のエリートに傷1つつかない」と堂々と豪語可能な防御力を有する。 電磁的な世界最高峰の装甲にして規格外オニオン装甲であり、加えて50メートルの分厚さによって一切の電子干渉は不可能。 正直、王室直属の技術者達を悩ませたのは「虹色」で「結晶質」であるという部分の話だが詳細は不明。 勿論、永遠の宝石であるだけのオブジェクトではなく機能的な面も保持している。 海上で不動である位置は本初子午線と赤道が公差する「経度0」「緯度0」の箇所に存在する。 そのため地図ソフトで座標指定エラーが発生した時などに統計処理に支障が出ないようにする陸地の役割を担う。 世界のあらゆる勢力が必ず基準にしなくてはいけない箇所に、王族の巨大な宝石を鎮座させる。 『正統王国』の『君主議会』の影響力の強さを象徴するオブジェクトである。 また世界の中心(緯度経度的な意味で)に存在するオブジェクトであるため世界的な知名度はトップ。 ギニア湾のこのオブジェクト周辺海域自体が広い範囲で『君主議会』直轄領であることからも象徴的な価値は高いのだろう。 コンセプト 実在する架空島のヌル島のソウルブイのオブジェクト版、そして『君主議会』のレガリア 特徴 極彩色に輝く水晶で出来たオブジェクト 弱点 地球把握と王族の顕示欲のオブジェクトのため武装が存在しない。 →警告 この先は『君主議会』のいと清らなる金星花計画協賛の王室現王で有らせられる御方のみ御通りください
https://w.atwiki.jp/socup/pages/172.html
デザインパターン/FacrtoryMethod デザインパターン/Builder デザインパターン/AbstructFactoryMethod 疎結合にするテクSingletonはグロバール変数なので後々問題が起こる可能性あり デザインパターンの基本戦略 テンプレート 戦略パターン戦略パターン適用前 これを戦略パターンで作るなら Visitorパターン イテレータ(繰り返し)パターンイテレータ適用前 イテレータ適用後 アダプターパターン継承型 委譲型 Ab Fcパターン プロトタイプパターン ビルダーパターン Compositパターン Flyweightパターン Bridgeパターン デコレータ Facadeパターン Commandパターン Interpreter パターン Mediator パターン Memento パターン Observer パターン Stateパターン デザインパターン/FacrtoryMethod デザインパターン/Builder デザインパターン/AbstructFactoryMethod 疎結合にするテク 単方向依存にする インターフェイスで最小限タッチさせる クラスの分割で責任範囲を制限 継承より委譲 Singletonはグロバール変数なので後々問題が起こる可能性あり デザインパターンの基本戦略 具体的な部分は後で取り替えられるようにしておく テンプレート 処理の流れを抽象化しておく 作業行程(テンプレート) 内部で行う作業 1 "材料を用いてAをする" 2 "材料を用いてBをする" 3 "材料を用いてCをする" 4 "材料を用いてDをする" 依頼可能文 ”材料指定して作業する” 材料指定して作業するとは 作業1~4を行うこと。 作業工程の系列 具体的作業行程A A~Dが具体的に何をするのか決めてある。 戦略パターン 戦略 戦略A 戦略B ユーザーが条件αでやれ、 というと、αに応じて戦略Aか戦略Bかを決める。 変化する可能性の高いアルゴリズム(if文分岐など)を(クラスで)分割する 戦略パターン適用前 人間 比較屋 タイプを決める 次の指定タイプを比較する 年齢、身長 比較する 二人の人間を指定タイプで比較する。 実行 人間としてA氏、B氏を取る 比較屋が比較するタイプとして年齢で比較する事にする 比較屋にA氏とB氏の比較を依頼する これを戦略パターンで作るなら 比較屋 比較が依頼できる存在 比較屋の系列 年齢比較屋 身長比較屋 作業者 頼める比較屋がいる。 比較する 頼める比較屋に比較を依頼する この作業者の頼める比較屋は年齢比較屋である。 この作業者に比較を依頼する (作業者は、年齢比較屋に比較を依頼する 年齢比較屋は年齢で比較を行う) Visitorパターン 訪問者 ある調査対象クラスを渡して処理を依頼する 調査対象 訪問者の調査対象 調査対象は以下の依頼ができる 依頼 ”私が訪問者です” 調査対象者であるA 依頼 ”私が訪問者です”というメッセージを受けたら 訪問者に”掃除してください”と言う イテレータ(繰り返し)パターン イテレータ適用前 学生 聞き取れるメッセージ 年齢を教えて 性別を教えて あなたの名前と性別は**です。 学生リスト 聞き取れるメッセージ 学生を加えて *番目の学生は誰ですか 全部で何人ですか 先生 先生は学生リストを持つ 聞き取れるメッセージ 学生リストを作成して 学生を点呼して 「学生リストを作成して」と言われたときは 学生リストにA君を追加 学生リストにB君を追加 「学生を点呼して」と言われたときは 学生リストから学生の数を把握して 1番から最後まで学生の名前を呼ぶ イテレータ適用後 イテレータ作成機能 「イテレータ作ってください」 イテレータ 「次はありますか?」 「次を下さい」 私の学生リスト 学生リストの一種。イテレータの作成機能を持つ。 先生 「学生を点呼して」と言われたときは 学生リストからイテレータを取り出して イテレータが次があると言ってる間は イテレータから学生を取り出して学生の名前を呼ぶ アダプターパターン 継承型 価格要求機能 「価格を教えろ」 商品 「コストを教えろ」 洗剤(アダプター) 商品の一種 価格要求機能を持つ 「価格を教えろ」と言われたら 「コストを教えろ」と言われたのだと思う 委譲型 価格要求機能 「価格を教えろ」 洗剤(アダプター) 価格要求機能を持つ 属性 商品 「価格を教えろ」と言われたら 洗剤の持っている商品属性に「コストを教えろ」と言う。 生産者が生産物を作る 生産者 「生産物を作れ」 具体的生産者 生産者の一種である 「生産物を作れ」と言われたら 具体的生産物を作る Ab Fcパターン 生産者 「生産物Aを作れ」 「生産物Bを作れ」 プロトタイプパターン クローン作成機能 「クローンを作れ」 ビルダーパターン 作成者 「骨組みを作れ」 「外装を作れ」 「作成したものをよこせ」 指揮者 「作成者は**である。」 「作成しろ」 「作成しろ」と言われたら 作成者に「骨組みを作れ」「外装を作れ」「作成したものをよこせ」 という。 Compositパターン リスト 「実行しろ」 「加えろ」 「除け」 「リストをよこせ」 「実行しろ」と言われたら **をし リスト内の要素すべてに「実行しろ」という Flyweightパターン 貸し出し屋 「貸して」 「貸して」と言われたら 指定した貸し出し物を渡す。なければ作る。 Bridgeパターン 食器 皿 食器の一種 ボウル 食器の一種 木の皿 皿の一種 ガラスボウル ボウルの一種 食器 (皿、ボウル) 材質という属性を持つ 材質 (木、ガラス) デコレータ A 「実行しろ」 B Aの一種 「実行しろ」と言われたら **をやったうえでAの実行をする Facadeパターン 実行者 「実行しろ」 「実行しろ」と言われたら A、B、Cに対し Aへ「作れ」 Bに「作れ」 Cに「出せ」 という。 実行者を通して、A,B,Cを用いる。 Commandパターン 命令 環境を持つ 「実行せよ」 Interpreter パターン Interpreterパターン Mediator パターン クラスが多すぎてメッセージのやり取りが複雑化 クラスが通信媒介者を通して通信しあう Memento パターン 動作を記憶しておく Observer パターン 観測対象 観測者のリスト 「通知せよ」 「通知せよ」と言われたら リストに載っている観測者に通知する 観測者 「通知です」 「通知です」と言われたら 通知内容に従って何かする。 Stateパターン 実行したら次の状態を渡す 状態機能 「実行して次の状態を返せ」 状態A 状態機能を持つ 「実行して次の状態を返せ」と言われたら 実行して、状態Bを渡す 状態B 状態機能を持つ 「実行して次の状態を返せ」と言われたら 実行して、「なんにもない」を渡す 実行者 状態Aに「実行して次の状態を返せ」といい、 状態が受け取れたらその状態に同じメッセージを繰り返す。
https://w.atwiki.jp/memomem/pages/12.html
ここにデザインパターン関連の記事を書きます デザインパターンを学ぶメリット Singleton Singletonの破棄 TOPへ戻る