約 5,345,804 件
https://w.atwiki.jp/perlref/pages/101.html
オブジェクト指向 【用語】 【説明】 プログラムの書き方の一つ(とか言って、コレ一つしか紹介しない)。 プログラムを、実体のある一つの物体としてプログラミングする考え。 色々なたとえがあります(車だったり、たい焼きだったり)が、人間で例えたほうが一番わかりやすい(物ではありませんが)。 基本的な型だけを作り、後で継承して使うのが一般的な書籍の説明。 コレについては、Javaを勉強したほうが速そうだけど、JavaとPerlでは書き方が全く違うといっても過言ではないです。 【解説】 以下は、使う言語がPerlであることを前提です。 一つの物体の定義をクラスと言い、packageで定義します。 そのクラスの中で定義された変数を、メンバ変数やフィールドといったりします。 そのクラスの中で定義された関数を、メンバ関数やメソッドといったりします。 そのクラスの中で定義された、最初に呼び出すべき関数(大体はnew)を、コンストラクタと言います。 クラスの定義は、あくまで定義しただけです。実際に使う場合は、その定義された物体の実体を作らなければなりません。その実体を作ることを、インスタンス化と呼びます。 基本的には、そのクラスの中で定義された変数(フィールド)に直接に値を代入してはいけませんし、値を呼び出したりすることもいけません。 基本的には、以下のような書き方。 [[package]] TestObject; [[sub]] new { my $self = shift; my @args = @_; bless { }, $self; [[return]]; } ------------------------------------- # インスタンス化 my $inst = new TestObject(); 以上、わかりづらい解説でした。 習うより慣れろです。 【関連事項】 サブルーチン 連想配列 package bless new
https://w.atwiki.jp/fsharpmaster/pages/20.html
オブジェクト指向フレームワークとワークフロー（モナド） 今現在、Javaでフレームワークを設計する仕事をしている以上、今作っているようなものをどのような形にすればF#に持ち込むことができるのか、ということには当然興味の焦点のひとつになってしまいます。 以前、Javaでやっているライブラリを移植しようとあれこれ考えているうちに、結局F#でもオブジェクト指向に走ってしまい、結局プログラムの枠組みが変わらない、そのまま移植したようなプログラムになってしまったことがあります。オブジェクト指向で作っていると、ある程度は破壊的代入を前提としたクラスを作らざるを得ず、「これならC#でもいいじゃないか」と自分で思ってしまうようなプログラムでした。 こういう選択肢を取れることもF#（OCaml）の強みなのかも知れませんが、できることならF#なりのプログラムの形を追及してみたいところです。 ポリモルフィズムを考える オブジェクト指向フレームワークで使われる手法の代表格、ポリモルフィズム（多態性）ですが、この多態性には使い方ベースで二つの分類があることに気づかれているでしょうか？一つは「外側からの多態性」で、もう一つが「内側からの多態性」です。と言う言葉は僕が勝手に使っているもので、他でどう読んでいるかは実はよく知りません。しかしオブジェクト指向でメシを食っている人は、多かれ少なかれ両方を日常的に使いこなしているはずです。 外側からのポリモルフィズム 最も分かりやすく、一般的な使われ方の多態性です。もうサンプルなど乗せる必要もないと思いますが、「外側から」がイメージできるように簡単なものを載せておきます。 using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace OOPSample { abstract class Animal { abstract public String Bark(); } class Dog Animal { override public String Bark() { return "Bow-wow!"; } } class Coq Animal { override public String Bark() { return "cock-a-doodle-doo!"; } } class Program { static void Main(string[] args) { Animal[] animals = {new Dog(), new Coq()}; foreach (Animal animal in animals) { Console.WriteLine(animal.Bark()); } } } } こうやってC#のコードを貼ると、F#のソースがどれだけ簡潔なものになっているかはっきりと分かりますね。上のコードについては解説するほどのものでもないと思いますが、Mainメソッドの中を見ると、animal.Bark()という風に、仮想関数をオブジェクトの外からCallしているところから、「外からのポリモルフィズム」と呼んでいます。単純明快なので、先に身に付けるポリモルフィズムは普通こちらだと思います。 内側からのポリモルフィズム 今度のポリモルフィズムは、仮想関数を基底クラスから呼び出すものです。 using System; using System.Collections.Generic; using System.Text; namespace OOPSample { abstract class Animal { abstract protected String Bark(); abstract protected int Legs(); public void BarkOperation() { Console.WriteLine(Bark()); Console.WriteLine("I have {0} legs\n", Legs() .ToString()); } } class Dog Animal { override protected String Bark() { return "Bow-wow!"; } override protected int Legs() { return 4; } } class Coq Animal { override protected String Bark() { return "cock-a-doodle-doo!"; } override protected int Legs() { return 2; } } class Program { static void Main(string[] args) { Dog dog = new Dog(); dog.BarkOperation(); Coq coq = new Coq(); coq.BarkOperation(); } } } 長っ！こういう括弧の付け方を強要する言語ってあんまり好きになれないなぁ・・・。 こういうポリモルフィズムは、以下のような状況で使われます。 プログラムの全体の流れは決まっているが、その中の一部の処理だけが処理によって異なる、または決まっていない。 そういうケースで、全体の流れを基底クラスのメソッドで実装し、処理が異なる一部の処理を純粋仮想関数で定義しておく（フレームワーク実装者の仕事）。 派生クラスで純粋仮想関数を実装することで、プログラム全体の定義を完了する（業務実装者の仕事）。 MFCみたいな古典的なフレームワークはこんな作りになってることが多いです。 ちなみに、この基底クラスで実装されているBarkOperationメソッドを別のクラスで実装し、派生クラスのオブジェクトを外から与えるようにしたのがBuilderパターンと言えます。依存性云々の関係でで最近はこっち（Builderパターン）のほうが主流になっているみたいですね。僕は個人的にあんまり好きではないのですが（業務側ソースの絵面がごちゃごちゃするので）。 どっちにしても、なんだかこれはワークフローで書き換えられそうな気がしてきます。 上のAnimalクラスをワークフローに書き直してみましょう。 F#で書き換えたコード type OopTransType = Bark of string | Legs of int | Terminate type OopTransBuilder () = member this.Bind (res OopTransType , cont unit - OopTransType) = match res with | Bark x - printfn "%s" x cont () | Legs x - printfn "I have %d legs" x cont () | Terminate - Terminate member this.Return(x a) = Terminate member this.Delay(restOfComputation unit - OopTransType) = fun () - restOfComputation () let ooplike = OopTransBuilder() let dog = ooplike { do! Bark "bow-wow" do! Legs 4 } let coq = ooplike { do! Bark "cock-a-doodle-doo!" do! Legs 2 } 実行結果 dog ();; bow-wow I have 4 legs val it OopTransType = Terminate 構造的に、サブクラスでオーバーライドされていた部分が後半のooplike{}の中にまとめられ、基底クラスのBarkOperationで実装されていたものがBindに移されたような状況です。 こうしてみると、業務側の記述はオブジェクト指向と比較してずいぶんすっきりしますね。ただ、オブジェクト指向でも抽象化が進んだフレームワークではずいぶん「業務をこのように書くと裏の仕組みがどうなってて動くのか分かりにくい」と言われたものですが、ワークフローではそれに拍車がかかった感じがしないでもありません。ただ、OOPのほうは、仮想関数を実装してもそれがどの順で実行されるのか、基底クラスやDirectorクラスを見ないと分かりませんでしたが、ワークフローではそのあたりが業務側に安心感を感じさせてくれる記述になっている気がします。 プログラムの構造とその変化 「内側からのポリモルフィズム」にしろ「Builderパターン」にしろ「ワークフロー」にしろ、やろうとしていることの元々の形は以下のものです。 業務ごとに処理は異なるが、出力の型は共通している処理Ａ（業務処理Ａ） 業務処理Ａの結果Ａを受け取り、水面下で行われるべき処理ａ（共通処理ａ） 共通処理ａの結果ａもしくは業務処理Ａの結果がパススルーされたもの）を受け取る（もしくはなにも受け取らずに処理する）、業務ごとに処理は異なるが、出力の型は共通している処理Ｂ（業務処理Ｂ） 業務処理Ｂの結果Ｂを受け取り、水面下で行われるべき処理ｂ（共通処理ｂ） このようなプログラムは、まるで刺繍糸が布の表と裏を行き来しながら縫い目のきれいな表面だけを見せるように、イルカが水面を時折ジャンプしながら泳ぐように、見えているこちら側の美意識を守るため、向こう側の処理をあえて見えないようにしておくような構造を持っています。 他の人はどうか知りませんが、僕はなんとなく以下のようなイメージでいつもコーディングしています。作るべきもの全体を見渡して、大きな流れで共通するものを探し、どうしても共通化できない部分をモチのようにつかみ出して水面上に出し、その部分だけインターフェースを書いて業務の人に実装をお願いするイメージです。 オブジェクト指向の場合は上の絵を頭に浮かべてそれでうまくいっていたのですが、ワークフローの場合はこの絵がBindの持つ多重性と全体の再帰的な構造のため奇妙にねじれてしまうのです。まるでクラインの壺のごとく。それのよじれ感をうまく図にしたいのですが。 構造的な変化は大きく分けて二つあると思います。 ビルダーメソッドの重層化 OOPでは、業務と業務の間に水面下で行われる実装は、先ほどの図のようにビルダーメソッドで仮想関数呼び出しの間に記述されていました。 しかし、ワークフローのビルダークラスでは、これがBindメソッドのmatchの中に押し込められます。 この二つの違いは、業務側の実装自由度に現れてきます。OOPでは、業務側の記述がいつどの順番で実行されるかは完全にフレームワークの実装に依存していて、業務側で変更できないようになっていましたが（BuilderパターンにすればDirectorクラスの実装を変えることで対応できますが、水面下の実装はDirecotorクラスに記述されることになるので、このクラスは業務側で書くべきものではないはずです）、ワークフローでは前の関数の戻り値と次の行の引数のつじつまが合えばDSLのようにある程度自由な記述が可能となります。 例えば上のdogコンピュテーション式は let dog = ooplike { do! Legs 4 do! Bark "bow-wow" } のように書き換えても動きますが、「内側からのポリモルフィズム」ではこのような変更を許すことができませんし、BuilderパターンではDirectorクラスの修正が必要になります。 コンピュテーション式の行と行の間でBindの中のどの処理が実行されるかは、前の行が判別共用体のどの型を返すかによって決まります。上の例では「Legs 4」は「Legs of int」を返すので、 | Legs x - printfn "I have %d legs" x cont () にmatchしてこの行が実行されることになります。 Bindメソッドの再帰構造 あまり意識するようなものでもないのかもしれませんが、OOPでは 業務処理Ａ 共通勝利ａ 業務処理Ｂ 共通勝利ｂ のようにベタッと書かれていたものが、ワークフローを使うと 業務処理Ａ 共通勝利ａ 業務処理Ｂ 共通勝利ｂ のように自動的に入れ子構造に展開されます。しかしまぁこれは、OOPでも入れ子構造に書けないことはないのでたいした違いはないかもしれませんが、入れ子（再帰）構造のコードは決して読みやすいものではないので、ベタッと書けば勝手に入れ子にしてくれるのは、コードの保守性という意味ではありがたいと言えるかもしれません。ただ、Bindが入れ子に展開されるということが実装者に分かっていないと、デバッグのときなどに何が起こっているのかわからない、ということになりかねませんが。 とにかくこのような構造を先ほどの図に組み込むと、こんな感じになります。図的な理解と合わせて読んでいただけるとより理解しやすいかもしれません。 この再帰的な構造がイメージしていただけるでしょうか。この図に描ききれていないのですが、一つ重要なことがあります。この図に表れる（青い四角で囲まれた）二つのBindと一つのReturnは、同じオブジェクトのメソッドになります。Bindで呼び出した継続処理の中で、もう一度自分が中から呼ばれているようなちょっと不思議な構造です。業務処理はベタッと縦に並べて書かれていても、実はこのように再帰的な呼ばれ方をしているのです。 まとめ 少なくとも、オブジェクト指向でBuilderパターンと呼ばれているような構造は、ワークフローで書き直せることが分かりました。しかし、業務側にDSL的な自由度を許す必要がない場合は、普通にBuilderパターンや内側からのポリモルフィズムを利用したほうが、プログラムはずっとわかりやすく、メンテしやすくなるでしょう。 しかし、業務側が業務内容に応じてfsxスクリプトで書いて実行するような、業務側に高い自由度と安全性が求められる場合には、ワークフローは非常に強力な手段になり得ます。F#ではこういう手法が取れることを常に頭の隅に置いておき、適切なときにこの仕組みを利用できれば、F#使いの面目躍如といったところです。 （文責：片山 功士 2012/01/10） 今日： - 人 昨日： - 人 トータル： - 人
https://w.atwiki.jp/chiffon/pages/9.html
UML デザインパターン
https://w.atwiki.jp/amakozen/pages/5.html
変化する部分をカプセル化する 継承よりコンポジションを好む 実装に対してではなく、インターフェースに対してプログラミングする クラスは拡張に対しては開かれた状態であるべきであるが、変更に対しては閉じた状態であるべきである（Open-Closed Principle：開放／閉鎖原則）
https://w.atwiki.jp/keiplus/pages/217.html
オブジェクト指向（OOP） OOP 本項は書きたての記事です。正確な情報は公式サイト、公式ドキュメント、記載の参照サイトでご確認ください。 目次 + 読む オブジェクト指向（OOP）目次 content content + 読む 手続き型プログラミング オブジェクト指向 対応言語 Fortran、C、COBOL、JavaScript、PHP 対応言語 C++、C#、Java、Python、Swift、Ruby、TypeScript、PHP５以降 主な仕様 変数 主な仕様 オブジェクト 条件分岐 クラス ループ処理 プロパティ メソッド 名前空間 クラス内定数 クラス変数 統一コンストラクタ デストラクタ アクセサ カプセル化 ポリモーフィズム サブタイプ ある型を引数や戻り値にとる関数が、その型の部分型（サブタイプ、派生型とも言う）も引数や戻り値に取ることができる性質 パラメータ 関数の引数や戻り値の型情報の一部をパラメータ化して外部から与えることができる関数、あるいは、合成型の定義に含まれる型情報の一部をパラメータ化して外部から与えることができる型の性質 アドホック 型システム上は関連性のない複数の型を引数や戻り値にとることができる関数（メソッドや演算子を含む）の性質 継承
https://w.atwiki.jp/mopsprogramming/pages/95.html
オブジェクト指向関係の言葉を整理しておきます。 クラスは、データ構造をメソッドを定める抽象的な分類概念(変数型に似ている)ですが、それに属する具体的エンティティーは、オブジェクトという場合と、インスタンスという場合があります。特にクラスで決められた構造の具体化であるという趣旨が強い文脈ではインスタンスと呼び，普通はオブジェクトと呼ぶことにします。Mopsマニュアルでは、クラスとオブジェクトで通しているようです。 オブジェクトの実体は、一般にはもっと小さいデータオブジェクトの集まりです。ひとつのオブジェクトの構成部分となっているオブジェクトはインスタンス変数といいます。IVARと略されます。 オブジェクトに対して、適当な働きを要求するのがメッセージです。メッセージは、入力としてのパラメタとメソッドを特定するためのセレクタから成り立っています。これに対応して、実際に行われる処理がメソッドです。パラメタはメソッドへの入力となるわけです。セレクタとしては、メソッド名が使われます。メソッド名(つまりセレクタも)は、コロン" "で終わっている必要があります。 メッセージ=パラメタ＋セレクタ セレクタ=メソッド名 --- で終わらなければならない オブジェクトに対するメッセージを特定のメソッドと結びつけて、オブジェクトの"属性"であるデータに関連づけたりすることを、バインド(束縛、結合)といいます。コードを読み込んだときに既にそれを実施してしまうやり方は静的束縛、実際にコードが実行されるときになってからそれを実施するやり方は動的束縛といいます。 Mopsでは、動的束縛を利用するには、メッセージの送付をそのような構文で書けば十分で、"バーチャル"などのような特別なダミーを用意する必要はありません。別々のクラスのオブジェクトに同じメッセージを送り、クラスに応じて具体的な処理内容を違えることができることを多態性(Polymorphism)をもつといいます。Mopsでは、パラメタと戻り値(出力)の性質を合わせた同じ名前のメソッドを別々のクラスに定義し、動的束縛を行うだけで実現できます。 Mopsにはクラスメソッドという観念はありません。ですから、オブジェクトの特定なしに、クラス自体にメッセージを送ることは通常考える必要はありません。 オブジェクトが生成されるときに、その属性としてのデータの値を初期化する関数はコンストラクタと呼ばれ、特別視されます。MopsではCLASSINIT というメソッドを書くことによってそれが実装されます。このメソッドはオブジェクトの生成時に自動的に送られます。 他にもありますが、それらはもっと後述べます。 関連項目： クラスとは何か メッセージとバインド オブジェクト宣言 トップページへ 目次へ
https://w.atwiki.jp/sklab/pages/40.html
参考 デザインパターン(http //www.rarestyle.net/main/patterns/patterns.aspx) カプセル化 単なるデータ隠蔽ではなく、あらゆる種類の隠蔽を含んでいる。 必要な機能のみを持たせ、外からの変更を完全に遮断するためにprivateがある。 クラス図 is-a関係：あるクラスが他のクラスの「一種」である has-a関係：あるクラスが他のクラスを「保持」している uses-a関係：あるクラスが他のクラスを「使用」している Facade(建物の正面) メソッド呼出しを使用してより簡潔なインタフェースを提供する目的と、クライアントとオブジェクト間のやり取りを削減する目的を持つ。 システムを隠蔽する、もしくはカプセル化するためにも使用される。 どんなときに使うか 複雑なシステムがあり、その全機能を使用する必要がなく、かつシステムの利用規則を全て取り込んだ新規クラスを生成できる場合。 必要な機能が既存システムの部分集合である場合、新規クラスのAPIはそのシステムのAPIよりもずっと簡単になる。 既存システムをカプセル化、あるいは隠蔽化したい場合。 Adapter 異なるインタフェースを持つクラスを繋げる。
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 オブジェクト間の１対多の依存関係を定義し、あるオブジェクトの状態が変化すると、それに依存しているすべてのオブジェクトが自動的に通知され更新られるようにする put型とpull型がある