約 5,853,681 件
https://w.atwiki.jp/memomem/pages/21.html
オブジェクト指向パラダイムでは、オブジェクトという概念を中心に据えたものの考え方です。 このためオブジェクトという観点からすべての物事を見ることになります。つまり、 問題領域を機能に分解していくのではなく、オブジェクトに分解していくわけです。 オブジェクトとは「データ＋操作」ではありません。決して「賢いデータ」程度の物ではないのです。これは実装の観点からしか見ていない、狭いものの見方です。なおオブジェクトが保持するデータには、数値や文字列のような単純なものから、他のオブジェクトまで、さまざまなものがあります。 "オブジェクトを使用することで責任を局所化する" オブジェクトを使用する利点は、オブジェクト自体に責任を持たせて物事を定義できるという点です。 オブジェクトには責任が課され、自らのことについて責任を持つことになるため、やって欲しいことを他のオブジェクトに伝える方法が必要となります。ここでオブジェクトには自らに関するデータ、および、要求された機能を実装するためのメソッドがあったことを思い出してください。オブジェクトが用意するメソッドの多くは、他のオブジェクトからも呼び出し可能になります。こういったメソッドの集合を、オブジェクトの公開インターフェイスといいます。 "オブジェクトには他のオブジェクトが使用するためのインターフェイスがある" それではオブジェクトとは何か。オブジェクトとは「責任」です。責務を備えた実体です。そして、それは先の「概念レベル」「仕様レベル」から考察した結果導き出されるものです。実装レベルを混ぜてはいけません。「オブジェクトがどう実装されるか」ではなく「オブジェクトが何を実行するのか」に着目しなければならないのです。 開発の手順 オブジェクト指向に沿ったソフトウェア開発の手順はこうなります。 1. 詳細をすべて考慮することなく、予備的な設計を行う 2. その設計を実装する つまり、まず概念レベル（＝責任）で考えることになります。そして、責任を果たすために、他のオブジェクトが使用するためのインターフェイスを考えます。これを「公開インターフェイス」といいます。実装をそのインターフェイスの背後に隠蔽することで、実装とそれを使用するオブジェクトを分離しているのです。 実装レベルで考えているだけだと、結局機能分解の時と同じ問題が発生します。つまり、変更から守られないということです。差分プログラミング的な、誤解されたオブジェクト指向もこの範疇に入ります。 一方、概念レベルでコミュニケーションをはかり、別のレベルで（実装）要求を遂行する、という風に分けて考えると、リクエストする側は何が起こるかの概略だけ知っていればよいことになります。つまり、その概略（責任・インターフェイス）をそのままに、実装詳細の変更から、リクエスト側を守ることができるということです。 なんかコピペしても伝えたいことをうまく伝えられねぇ…。 素直に「-デザインパターンとともに学ぶ-オブジェクト指向のこころ」を読んで欲しいなぁ。 参照元オブジェクト指向パラダイム オブジェクト指向とは
https://w.atwiki.jp/kit-ic/pages/18.html
オブジェクト指向プログラミング(Object Oriented Programming)。 プログラミングパラダイムの一種。 Pascal, C++, Java, JavaScriptなど多数のプログラミング言語でサポートされている。 構造体のようなデータのまとまりを"オブジェクト"と呼ぶ。 「オブジェクトが持つデータ」や「オブジェクトに対する操作」を主体に考えるスタイルの設計様式。 一般にデータを「フィールド」、操作を「メソッド」と呼ぶ。 C++などでクラス又は構造体を用いて行うOOPでは特に、データを「メンバ変数」、操作を「メンバ関数」と呼ぶ。 言語などによって定義が大きく変わるが、フィールド(あるいはフィールドに近い性質を持つモジュール)をプロパティと呼ぶこともある。 クラスベースのオブジェクト指向では、オブジェクトが持つデータの形式や操作の集合だけ定義したものをクラスと呼び、クラスに基づいて実体化したオブジェクトをインスタンスと呼ぶ。
https://w.atwiki.jp/memomem/pages/14.html
ここにオブジェクト指向に関連する記事を書きます オブジェクト指向とは 共通性/可変性分析 単一責任の原則（SRP） オープン・クローズドの原則（OCP） リスコフの置換原則（LSP） 依存関係逆転の原則（DIP） インターフェイス分離の原則（ISP） コマンド/クエリ分離の原則 (CQS) Topへ戻る
https://w.atwiki.jp/bogard/pages/41.html
オブジェクト指向、というプログラミングパラダイムが現れて久しいわけですが、いまだに「オブジェクト指向」って根付いていない気がするんですよね。 JavaやC++/C#が使えたらオブジェクト指向でプログラミング出来ているか、というとそうでもないし。それらの言語はオブジェクト指向な「書き方が出来る」言語であって、それらを使えば自動的にオブジェクト指向のプログラミングが出来るわけではないし、逆にC言語やアセンブラではオブジェクト指向プログラミングが出来ないかといわれると、そうでもないと思うのです。 「オブジェクト指向」とは、あくまで、プログラミングパラダイムの一種だ、ということです。 オブジェクト指向というのがどういう考え方か、なんていうのは世にいろんな本が出ているわけで、いまさらここで私が述べるべきことってないと思います。ただ私がひとつだけいえるのはあくまでそれはプログラミングの方法論であって、例えばそれまでの構造化プログラミングと比べて優れている、などということはない、ということです。 確かに、オブジェクト指向プログラミングには、さまざまな利点があります。大まかに言うと ①プログラムの構造が把握しやすい（図示などが容易） ②コードの拡張性・再利用性が高い あたりが大きいのではないでしょうか。 これらは確かに大きな利点ではあるのですが、これらの利点が生かされる局面というのは大規模な開発に限定されると思うのです。小規模な開発においては、オブジェクトという抽象的名概念によって余計にシステム全体の見通しが悪くなったりしてしまいます。 つまり、オブジェクト指向プログラミングの使いどころとしては、具体的な処理をいちいち把握できないような大掛かりな場面において、抽象的な「オブジェクト」という単位で状態および機能を把握する、という使い方です。 何でもかんでも「オブジェクト指向だ」ではなく、ターゲットに応じたパラダイムの選択肢の一つ、と考えたほうが正しいと私は思います。
https://w.atwiki.jp/memomem/pages/22.html
オブジェクト指向の「見方」はわかりました。次はどうやって実現するかの「手段」部分です。これにはオブジェクト指向で提供されている様々な技術を使います。 クラスとは オブジェクトの共通する作業やデータをオブジェクト毎に持たせるのは効率的ではありません。そこで「クラス」を使用します。クラスには以下の要素が含まれています。 * オブジェクトが保持するデータ項目 * オブジェクトが実行出来るメソッド * データ項目やメソッドにアクセスするための方法 型としてのクラス クラスは「抽象データ型（abstract data type ADT)」の機能を持っています。抽象データ型の表現方法がクラスといってもいいかもしれません。「オブジェクト指向プログラミング入門」によると、抽象データ型は以下の特徴をもっています。 * 型定義を公開できること。 o プログラマがデータ型を定義。 * インスタンスに対する操作が利用出来ること。 o 「do(data)」ではなく「data.do()」。 * 内部のデータを保護し、上記の操作のみがアクセス出来ること。 o 情報隠蔽。 * 複数のインスタンスを作れること。 o マルチプルインスタンス。 継承の用途 型が定義できるようになっても、まだ問題があります。例えば様々な種類の学生型をコレクションで保持したい場合などです。この種類のバリエーションから、ある型のグループを包含するような汎用の型、つまり抽象型の必要性がでてきます。これがいわゆる抽象クラス（基底クラス）と呼ばれるもので、それを継承しているそれぞれの型は具象クラスと呼ばれます。 抽象クラスは実体化できないというだけのクラスではありません。これは実装レベルで考えた狭い考えで、概念レベルから見ないと本当の理解はできません。抽象クラスは、それが表現している概念を具体化したクラスの実装を格納するための場所を提供する、という意味です。つまり、抽象クラスによって関連のあるクラス群に名前を割り当てる方法が与えられ、関連のあるクラス群を１つの概念として扱えるようになるわけです。継承はこのように「オブジェクトの分類」に使用します。 継承の問題点 「継承は特殊化と再利用の手段である」というのは本質ではありません。濫用すると問題があります。 例をあげます。図形で5角形を表現するPentagonクラスがあるとします。ここで継承を使って「縁」機能を持つPentagonBorderを作成します。すると、以下のような不具合が発生します。 * 凝集度が低下する可能性がある o Pentagonの責任にBorderは関係ない。 * 再利用の可能性が低下する o 縁機能ロジックが他の図形で再利用出来ない。 * 変化に追随できない o 違った観点の変更に対応出来ない。 o 次に「網掛け」機能が必要になったら、クラスの組合わせが爆発してくる。 継承はかつて実装的側面で語られることが多かったといいます。しかし、いわゆる「差分プログラミング」と称して推奨された特化の継承にはこのような問題点もあったわけです。これ以外にも、継承に関して多くの問題点が指摘されています。そのキーはやはり「責任」という概念だと思います。オブジェクトは「責任」であり、さらに責任とは「責任をもった者同士の委譲である」といいます。継承は同じ責任内で働くため、委譲をうまく取り扱えません。 カプセル化とは カプセル化は、オブジェクトが自らのことに対して責任を持ち、必要のない物は見せない、という事です。単純なメンバデータの隠蔽的な意味で使われることがありますが、これは誤解です。カプセル化はあらゆる種類の隠蔽を意味しています。枚挙にいとまはありませんが、例えば以下のようなことも含んでいます。 * 派生クラス o ポリモーフィズムにより、実際の具象クラスを知らなくても良い。 o 「型のカプセル化」（抽象が具象を隠してる）といえる。 * 実装 o 実装する側は、インターフェイスが決まっているので、呼び出し側を気にしないで変更出来る。 o 「メソッド（実装）のカプセル化」（メソッドの実装を隠せる）といえる。 * 設計の詳細 o 使用する方から、その詳細を気にしなくても良いようにする。 o 「メソッド（使用）のカプセル化」（メソッドの実装を気にしない）といえる。 * 実体化の規則 o 別途実体化専門の役割がいて、使用する側は気にしなくても良い。 o 「生成のカプセル化」といえる。 * サービス o アダプタオブジェクトの背後の何かを隠し、実際に動作しているサービスクラスを使用する側は気にしなくて良い。 o 「オブジェクトのカプセル化」といえる。 オブジェクト指向技術の目的 オブジェクト指向技術を使うとき重要なのは「変更に強いソフトウェアを作る」という目的意識です。実装に便利な仕組みが提供されているため、意識しないとすぐに実装よりの考え方に陥ってしまいます。 「変更に強いソフトウェアを作る」には、流動的要素をカプセル化します。これにより、システムの変化を特定部分に封じ込めると、そこ以外の部分を再利用することができます。つまり流動的要素を見つけ出し、それをオブジェクト指向の技術を利用してカプセル化することが「変更に強い再利用可能なソフトウェア」を作ることになるのです。 参照元オブジェクト指向技術 オブジェクト指向とは
https://w.atwiki.jp/wonder_kichijoji/pages/36.html
オブジェクト指向とは 「世の中ぜーんぶオブジェクトだよね！」って考えの基に作られた指向． オブジェクト=データ+処理(メソッド) クラス＝オブジェクトの設計図 例えばクラス「車」(車の設計書)を作っておけば，クラスを基に実物を作るだけで車をたくさん作れる！ インスタンス＝あるクラスから作られた実物 例えばクラス「車」(車の設計書)を基に，インスタンスA,B,C（実際の車A,B,C）を作ることができる コンストラクタ/デストラクタ＝あるクラスに存在するインスタンスの生成処理/削除処理 例えばクラス「車」(車の設計書)のコンストラクタでインスタンス(実際の車)Aを作れる 既存のクラスを基に他のクラスを作成することが可能！ 刀の設計図(クラス)を使えば，刀を持ったプレイヤーの設計図(クラス)を作れる プレイヤー has a 武器has-a関係 刀の設計図(クラス)を基に，包丁の設計図(クラス)を作れる刀 is a 包丁is-a関係 クラス設計は抽象化が重要 細かい処理は表面に出さず，抽象化して使わせる コンビニで客もレジ打ちする？ →No，コンビニでは商品を渡すと自動で金額を知らせてくれるし，金を渡せば自動でお釣りをくれる 隠蔽化も大事！ 大事なデータは隠そう！ユーザーが触れていい場所を減らそう！ コンビニで客もレジ打ちする？ →No，大事なデータ(レジの中の金)には触れさせない！ ポリモーフィズム（多様化） 「人間の解釈/表現は多様である」ってことで，異なる処理も同じ呼び方で実行したいよね！ iPhoneだろうがPCだろうが「音楽”＊＊＊”を聞く」って命令で音楽を聞きたい実際は立ち上げるソフトや操作も違うが，ユーザーには意識させない 肉だろうが魚だろうが，「食べる」って処理で胃に入れたい実際は肉と魚では骨を退ける動作が異なるけど，ユーザーに意識させない オーバーロード：ポリモーフィズムに対応する手法の1つ デザインパターン：規格化した設計方針/ルール 世の中にはいろんな設計者がいる 先駆者の知恵をもとにデザインパターンまとめれば，より良い設計が簡単に統一して作れるはず 例：GoF
https://w.atwiki.jp/hurutati-project/pages/68.html
用語説明 クラス 構造体と違う点はメンバ関数を持てる点であり、つまりデータと関数が共存できる データの中に関数を埋め込む。 Cの様に独立した関数を作成するということはしない 宣言はヘッダーファイルで行い、実装は.ccファイルで行う オブジェクト指向開発の手順 システム分析 システム設計 実装 静的モデリング システム対象領域がどのようなオブジェクトで構成されているのかを分析→.hファイル 動的モデリング システム内でどのようにオブジェクトが動作するのかを分析→.ccファイル クラス名前 属性 そのクラスの成り立ちをあわらすデータ 操作 クラスに用意されたクラスに対する命令の受付窓口
https://w.atwiki.jp/bogard/pages/44.html
グダグダ言っていてもしょうがないので、まじめにオブジェクト指向なお話。 オブジェクト指向の使いどころと学び方について。 オブジェクト指向とは、従来の構造化言語（C言語など）と異なって、「オブジェクト」という単位で考えよう、ということだ。 なんて簡単に済ませてしまうと怒られそう。。 でも、オブジェクト指向の話なんて、本屋に言ったらいっぱいあるから、あえてここで私が述べる必要のあることってあまりない。ほんとに。 ただ、「オブジェクト指向」というパラダイムと「オブジェクト指向言語」と「UML」は、区別したほうがいいと思う。どうも、ごっちゃになっている（あるいは故意にごっちゃにしている）本が多いような。。 前にも書いたけど、C言語でだってアセンブラでだってオブジェクト指向なプログラミングはできる。 JavaやC++は、オブジェクト指向でプログラミング「しやすい」言語でしかない。 結局のところ「オブジェクト指向」というのはプログラミングの際の考え方の一つに過ぎない。 犬小屋をつくるのと、ビルを建てるのとでは設計から施工までの工程と方法論が違うのと、それは似ている 犬小屋をつくるときはその処理の全てを見通すことができるし、屋根から作っても壁から作ってもかまわない。 ビルを建てる時には、犬小屋を作るときみたいに細かい材料の寸法や材質も重要だけど、それらをあるていどひとまとめにして抽象的に捉える必要がある。まず全体の構成やコンセプトを決めて、その後で細かい部分の検討に入る。 そういう風な方法論の違いが、「構造化プログラミング」と「オブジェクト指向プログラミング」なのである。どっちがいい悪いというものではないと思う。 てなわけで、方法論そのものが違うのでオブジェクト指向プログラミングはやっかい。学習する際にはC言語などの手続き型言語とは一線を画して考える必要がある。 その意味で、C++という言語は罪作りな言語だと思う。C言語を使っていた人が移行しやすいのは確かなんだけど、そのままC言語の書き方でもプログラムを作れてしまう。 これだとプログラムの「考え方」「作り方」の移行が難しい。従来どおりの手続き型の記述を廃したJavaやC#のほうが、素直にオブジェクト指向の考え方に入っていけるとはおもう。 だけど、上のほうで書いたとおり、作るプログラムによってオブジェクト指向を使ったほうがいい場合とそうでない場合がある。 その意味では、その時々でどちらの書き方もできるC++という言語は、案外優れているのかもしれない。
https://w.atwiki.jp/bogard/pages/47.html
さて（何がさて、なのか）、オブジェクト指向な言語ですが現在有名なところでは C++とJavaあたりがよく使われているのでしょうか。あとC#くらいかな？ これらの言語で何が気に入らないかというと、「基本データ型」と「クラス」を 別のものとして扱っていること。 実用的にはともかくとして、思想として美しくないと思うんですよね。 intやbyteとかも、オブジェクトじゃないの？？ 特にJavaの場合は、扱いに注意しないといけないような気がする。 だって、クラスのインスタンスって、これ要はポインタじゃないですか。 MyClass hoge; MyClass piyo; hoge = new MyClass(); piyo = hoge; なんてした後、hogeの状態に変更を加えるとpiyoの状態も変化する。これってC++で書くなら MyClass* hoge; MyClass* piyo; hoge = new MyClass; piyo = hoge; ってことでしょ？ コードもほとんど同じだし。 でも、基本データ型では、また挙動が違ってくる。 int X, Y; X = 100; Y = X; X = 200; としたら、ちゃんとXに200、Yに100が入っている。 オブジェクト指向だって言うなら基本データ型だって同じように オブジェクトとして扱えるべきだ。 int X = new int(100); X.tostring(); 見たいな感じであつかってあげるべきなんじゃないのか？？意味があるかどうかは別にして。 これはあくまで例だし。 現在のJavaの仕様のほうが、特に基本データ型なんかはよく使うわけだから使いやすいのはわかるんだけど。 私が言いたいのは、そこが不親切というか、扱いが異なるのであれば明示的にわかるような文法にしてほしかったなあということ。 C言語/C++なんかではポインタが初心者のひとつの壁だと言われてるから、それをSUNが嫌がったのかな？ でもこんな調子では、昔よく言われていた「Javaにはポインタがない」という言葉はやっぱり欺瞞だったんだなあ。 どうせオブジェクト指向言語というなら、SmallTalkくらい潔くてもいいかも、 ･･･なんてことを言うと極端すぎるかな？
https://w.atwiki.jp/memomem/pages/18.html
1.機能分解 2.オブジェクト指向の誤解 3.ソフトウェア開発プロセスの観点 4.オブジェクト指向パラダイム 5.オブジェクト指向技術 6.オブジェクト指向用語 オブジェクト指向