約 5,827,604 件
https://w.atwiki.jp/lliiorziill/pages/19.html
UML を用いた分析・設計書の表記 ユースケース図 システムの機能や、外部関係者との相互関係を表す。 クラス図 概念や静的なクラス間の相互関係を表す。 オブジェクト図 クラス図で表現されたオブジェクト関係のある時点でのスナップショット シーケンス図 オブジェクト間のメッセージ交換を時系列に表す。 ステートマシン図(ステートチャート図) オブジェクトの取りうる状態や遷移を表す。 アクティビティ図 システムの動作の流れやアルゴリズムを表す。 コンポーネント図 システムを構成する実行可能モジュールやソースコードの物理的構造を表す。 配置図 システムを構成するマシンや装置の配置を表す。 コミュニケーション図(コラボレーション図) オブジェクトの集団の協調動作を表す。 ステレオタイプ (型の拡張) 定義した種類で書ききれない場合に用いる。 制御型 境界型 存在型 アクターはシステムの外部 境界線の中のみが開発対象 汎化 対象を包括する上位概念であることを示す。 オブジェクト指向による分析・設計 システム開発作業の概要 要求分析
https://w.atwiki.jp/sawawra_bunkakai/pages/16.html
ここはオブジェクト指向チームのトップページです。 ＜活動内容＞ ・オブジェクト指向についての情報まとめ →オブジェクト指向の特徴、構造化手法との差分(メリット/デメリット) ・UMLを使ってオブジェクト指向設計 ＜2009年度末までの到達目標＞ ・オブジェクト指向のメリット/デメリットを説明できる資料作成 ※ 現状メンバが木内一人のため勝手に決めてますが、どなたか参加される方がいらっしゃれば調整します。 ※ wikiの使い方を理解できたら、構成を見直します。(分割して新規ページを立てるなど)
https://w.atwiki.jp/asato/pages/109.html
デザインパターン 論文・記事進化 品質 Visitorパターン Iteratorパターン セキュリティ リンク 他のページ デザインパターン Unfortunatery, many readers missed the connection between design patterns and refactoring. They thought of patterns as entirely related to design, not to code. I suppose that the name might have misled them, but the fact that the book was mostly C++ code should have indicated that patterns are about code as well as design, and adding a pattern usually requires changing code. Refactoring to Patterns, p. xv 本書で扱うデザインパターンとは、”種々の状況における設計上の一般的な問題の解決に適用できるよう、オブジェクトやクラス間の通信を記述したもの”である。 オブジェクト指向における再利用のためのデザインパターン, p.15 デザインパターンは、一般的な設計構造のキーとなる側面に名前を付け、抽象化、識別化し、再利用可能なオブジェクト指向設計を生み出すのに有用となるようにしたものである。また、デザインパターンはそれにかかわっているクラスやインスタンス、それらの役割や協調関係、責任の分担を規定する。そして、それぞれのデザインパターンは、オブジェクト指向設計における特定の問題や課題に焦点を絞っている。すなわち、そのパターンはいつ適用すべきか、設計上のその他の制約を考慮したうえでも適用できるかどうか、そのパターンを使うことによる結果、さらには使う場合と使わない場合のトレードオフを記述しているのである。設計は最終的には実装しなければならないので、デザインパターンは実装方法を明確にするためにC++(いくつかはSmalltalk)のコードを例示している。 オブジェクト指向における再利用のためのデザインパターン, p.15 本書では、設計パターンのうち最もよく知られているデザインパターンの多くが、アレグザンダーが意図した意味においてのパターンではなく、負の可変性を伴う共通性-可変性配置の特殊なケースであることも紹介しよう マルチパラダイムデザイン?, p.4 論文・記事 Design Patterns with AspectJ, generics, and reflective programming , ICSOFT 2010 Scalable System Design Patterns, InfoQ, 2010 Swing to SWT and Back Patterns for API Migration by Wrapping, ICSM 2010 Inversion-of-Control Layer, EuroPLoP 2010 Design Pattern Implementation in Object Teams, SAC 2010 Deprecating the Observer Pattern, TR 2010 Batching A Design Pattern for Efficient and Flexible Client/Server Interaction, TPLoP Design Pattern Density Defined, Onward! 2009 An Exploratory Study of CaesarJ Based on Implementations of the Gang-of-Four patterns, TR 2008 The Universal Design Pattern Automated Verification of Design Patterns with LePUS3, 2009 An Exploratory Study of the Impact of Antipatterns on Software Changeability, TR 2009 Playing Roles in Design Patterns An Empirical Descriptive and Analytic Study, TR 2009 An Approach for Structural Pattern Composition, SC 2007 An Empirical Study of the Relationships between Design Pattern Roles and Class Change Proneness, ICSM 2008 Activator, 2009 Virtual Component a Design Pattern for Memory-Constrained Embedded Applications, 2009 Design Decision Topology Model for Pattern Relationship Analysis, SPAQu 2008 An Extensible State Machine Pattern for Interactive Applications, ECOOP 2008 Metapatterns Design Patterns Explained Stefan Nägeli, Ownership in Design Patterns, Master Thesis Marc Bartsch, Rachel Harrison, Design Patterns with Aspects A case study, EuroPLoP 2007 Use of design patterns in analogy-based design 進化 A Classification of Design Pattern Evolutions, JOT 2007 品質 DEQUALITE Building Design-based Software Quality Models, SPAQu 2008 Visitorパターン Modular Visitor Components A Practical Solution to the Expression Families Problem, ECOOP 2009 The Visitor Pattern as a Reusable, Generic, Type-Safe Component, OOPSLA 2008 Genericity, extensibility and type-safety in the Visitor pattern, PhD Thesis, 2007 Iteratorパターン The Essence of The Iterator Pattern, Journal of Functional Programming, 2008 セキュリティ Secure Design Patterns, TR 2009 リンク Portland Pattern Repository 他のページ メモ/ソフトウェアパターン
https://w.atwiki.jp/memomem/pages/27.html
*解決策の再利用 すでに確立されている設計を再利用することで、問題解決に向けて幸先のよいスタートを切ることができ、 細々とした詳細を避けることができるようになります。他人の経験から学ぶことができるという利点もあります。 何度も繰り返されている問題の解決策を再発明する必要がなるなるのです。 *共通用語の確立 コミュニケーションを円滑にし、チームワークをよくするためには、問題にたいする共通のボキャブラリと共通の認識を持つ必要があります。 デザインパターンによって、プロジェクトの分析工程と設計工程における共通の基準点ができるのです。 *デザインパターンによって分析と設計に関する、より高い展望がもたらされる パターンによって問題領域、および設計工程やオブジェクト指向というものをより高いところから 見渡せるようになります。これにより早すぎる段階で詳細に捕らわれるようなことが避けられるのです。 *コードの修正可能性と保守性の向上 たいていのデザインパターンは、ソフトウェアをより修正しやすく、保守しやすいものにします。 その理由は、これらのデザインパターンが時間を掛けてテストされてきた解決策であるためです。 このため、思いつきで生まれた解決策よりも変化に強い構造となっているのです。 また、より理解しやすいコードとなっているため、保守しやすくもなっています。 *デザインパターンは基本的なオブジェクト指向原則を浮き彫りにする デザインパターンを正しく身につければ、基本的なオブジェクト指向設計原則の理解に大きく役立つはずです。 *パターンが存在しない場合でも、すぐれた戦略を採用できる GoFは優れたオブジェクト指向設計を生み出すための戦略を示唆しています。彼らが特に示唆しているのは以下のことです。 "インターフェイスを用いて設計する。" "クラス継承よりもオブジェクトの集約を多用する。" "流動的要素を見つけ出し、それをカプセル化する。" こういった戦略はデザインパターン(GOF)のほとんどに採用されています。 デザインパターン
https://w.atwiki.jp/mini98/pages/15.html
オブジェクト指向というものを定義するとき、なかなかヒトコトで表現する事は難しいのですが、「ソフトウェアで扱う事柄について、データと操作をまとめて１つのオブジェクトとして捉える」というソフトウェア開発を指向しているもの、と表現できます(オブジェクト指向超入門)。 VB6でデータというと、変数や定数ですが、クラスのはじめにで Private や Public で宣言している変数が上記定義中の「データ」です(Private と Public はアクセス修飾子ですが、メソッド内部の変数にはこのアクセス修飾子を付ける事ができません。これが関数内ローカル変数とオブジェクト指向でいう「データ」との違いです)。 言語に依存しない言い方をすると、オブジェクト指向ではこのデータの事を「フィールド」と呼びます(メンバ変数と呼ぶ事もあります)。 操作とは、クラス内部に存在する Sub や Function で宣言されるプロシージャの事です。 Sub はサブルーチン、Function は関数を指していますが、戻り値の無いものをサブルーチン、有るものを関数としています。Microsoftはこれらをまとめてプロシージャと呼んでいます。 言語に依存しない言い方をすると、オブジェクト指向ではこのサブルーチンや関数の事を「メソッド」と呼びます。 このフィールドとメソッドという呼び名はオブジェクト指向を解説した本やサイトでは共通です。 言語の解説本ではなく、オブジェクト指向そのものを解説した本も市販されています(丁寧にオブジェクト指向を解説すれば本一冊になります)。わかりやすい本が見つかればいずれ紹介します。 オブジェクト指向の利点 現在、世の中には大規模なシステムがたくさん稼働していますが、これもオブジェクト指向の普及が一役買っていると言えます。昔であれば大規模なシステムを開発するのは大変でした。オブジェクト指向の利点により、大規模な開発が容易になったからです。「オブジェクト指向の利点」で検索してみると多数のページがヒットします。それぞれ様々な解説があります。 再利用性 オブジェクト指向の様々な解説の中でも、いちばん共通する利点は「再利用性」だと思います。オブジェクト指向プログラミング(以下OOP)では、モジュールの単位が「クラス」です。OOPではクラスをどんどん再利用して開発していきます。 また、そういったクラスを集め、web開発であろうがデスクトップアプリケーションであろうが、その開発に向いたフレームワークが存在します。似たような処理をする部分でクラスによる骨組み(フレームワーク)を作成し、個別の部分についてはそのフレームワークに付け足していくだけ、というような構成になっています（残念ながらVB6でオープンソース的フレームワークは見当たりませんが）。 他に、デザインパターンの利用が挙げられます。ある種の設計を行う場合、このようなデザインを行うとスマートに実装できる、といったパターンが存在します。古くはGOFパターンと呼ばれるものがあります。VB6ではOOP機能の制限で、これらを全て適用する事はできませんが、それでも適用可能なパターンは存在します。 カプセル化 OOPの利点に隠蔽化(カプセル化)があります。クラス内部でクラス外に見せたくないものはアクセス修飾子をPrivateにします。こうする事で、より安全な設計ができるようになりました。昔のシステムであれば、巨大な構造体からなるグローバル変数が存在し、そのいずれも簡単にアクセスでき、変更可能でしたが、そのような設計はシステムを複雑にし、わかりにくいものにしていました。かつてプログラミングで「GOTOは悪」と言われましたが、現在では「グローバル変数は悪」と言えます。 VB6でオブジェクト指向開発する利点 VB6のオブジェクト指向には様々な制限があります。継承が無い、引数付きコンストラクタを生成できない等。しかしそれでもVB6でOOPする利点はあります。 利点 インスタンス生成により、初期化が保証されている 再利用性を向上する事ができる ポリモーフィズムにより、似たような処理を共通化しコード量を抑える事ができる その他 欠点 OOP理解に多少の時間がかかる VB6のOOP機能が他の言語と異なる部分があり、市販のOOP解説本の内容も噛み砕きながら読まなければならない 私なりのオブジェクト指向定義 私なりにオブジェクト指向というものを定義するならば…世の中には様々なモノ(オブジェクト)があります。モノには必ず構造と機能が備わっています。椅子という構造があるとき、座ることができる、という機能があります。心臓という構造があるとき、循環という機能が備わっています。非オブジェクト指向言語まででは、構造体というもので構造を表現できました。その構造体に機能（メソッド）を追加したものがオブジェクトです。構造と機能を備えたオブジェクトをオブジェクト同士の作用によってソフトを作成していく方法がオブジェクト指向です。 @
https://w.atwiki.jp/kurosuke_se_zi/pages/5.html
デザインパターンに関してのメモ 参考文献 Java デザインパターンプログラミングの実践 中川 隆 著 オブジェクト指向における再利用のためのデザインパターン(改訂版) GoF著(訳本ね) GoFによるとデザインパターンは目的別に３つの分類が行われる。 生成に関するパターン 構造に関するパターン 振る舞いに関するパターン ここでもこの分類でまとめる。 とりあえずGoFがの本には２３個のパターンが出ている。 (J2EEパターン等、増加中？) 生成に関するパターン Factory Method 構造に関するパターン 振る舞いに関するパターン
https://w.atwiki.jp/book193/pages/24.html
ロボットレースによる組込み技術者養成講座 オブジェクト指向のこころ なぜ、あなたはJavaでオブジェクト指向開発ができないのか ☆☆☆☆ オブジェクト指向の説明するのに、こんな本が欲しかったと思わせてくれた本。 もちろん、これだけでオブジェクト指向が理解できるわけではないが、実際にプログラムしながらオブジェクト指向を理解できる。 ただし、非オブジェクト指向のサンプルがあまりにもベタに書かれているので、構造化ぐらいして欲しいところだ。 サイトに行くとRubyやC#で書かれたサンプルもあるので、Javaにこだわらずに勉強できる。 図解UMLモデリング ☆☆☆☆ なぜか、アマゾンに登録が無い 組込みソフトウエア開発のためのオブジェクト指向モデリング ☆☆☆☆ 組み込み系にフォーカスして、オブジェクト指向設計の説明がされていて良い本です。 UMLの説明もあるので、これ１冊で一通りわかると思います。 ユースケース実践ガイド―効果的なユースケースの書き方 ☆☆ 残念ながら、内容が難しすぎて理解できていませんが、ユースケースを書く意味が理解できるだけでも良い本だと思います。
https://w.atwiki.jp/agile_game/pages/13.html
オブジェクト指向設計の原則 オブジェクト指向設計の原則とは？ オブジェクト指向におけるクラスなどのソースコードに変換する際の基本原則です。 オブジェクト指向設計の原則はどんなものがあるのか？ 単一責任の原則 ( SRP The Single Responsibility Principle ) クラスを変更する理由は一つ以上存在してはならない。 オープン・クローズドの原則 ( OCP The Open-Closed Principle ) ソフトウェアの構成要素( クラス、モジュール、関数など )は修正に対して閉じていて、拡張に対して開いてなければならない リスコフの置換原則 ( LSP The Liskov Substitution Principle ) 派生型はその基本型と置換可能でなければならない。 依存関係逆転の原則 ( DIP The Dependency Inversion Principle ) a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。 b. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。 インターフェース分離の原則 ( ISP The Interface Segregation Principle ) クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。
https://w.atwiki.jp/abwiki/pages/446.html
歴史的には、オブジェクト指向言語の源流は、Simula。それらを参考にEiffelやSmalltalkが 作られ、C++やらなんやらが作られはった。 オブジェクト指向の能書きは、シミュレーションの際に扱うデータの抽象化にあるんや。 たとえばやなあ、ウインドウを抽象的に扱う場合、座標をx,yと個々に変数を扱うより、 ウインドウちうオブジェクトのx,yちう抽象データ型があったほうが取り扱いやすいちうわけや。 プログラム中、変数を無数に無作為に定義するよりも、座標やベクトルちう構造を持って いたほうが理解しやすいやろ。 例えば、 dim x1 as integer dim y1 as integer ... という変数が、無数にあるよりも、 type axis x1 as integer y1 as integer end type という構造体の変数型を使って、 dim point1 as axis dim button as axis ちうような扱い方のほうが理解しやすいちうわけや。変数名が無数にあったら可読性にも難があるんや。 数学のスカラ変数とベクトルのように、現実の計算をする場合、スカラ変数を複数利用する よりも、あるまとまった数値としたほうが都合がええわけや。 二次元ベクトルを考えるとき、既存のBASIC言語には備わっておらへん変数型やけど、 type vector x as double y as double end type なんやらとするやろ、"ワイ(俺)"変数型が作れるちゅうワケや。このようなtype/end typeを使う変数定義は 構造体と呼ぶ。 使うときは、 dim p1 as vector p1.x=100 p1.y=120 等とする。 これらと同じ発想で、関数やメソッドについても同じレベルで扱えるとうれしおます。 構造体に関数やプロシージャを含めるゆう事。 大体において、そういった独自の変数型には、その型に対応するメソッドや関数が必要やからや。 ここでクラスちう能書きやステートメントが登場するちうわけや。クラスは日常用語のクラスやのうて 数学の世界の用語、階級とかランクとかいう意味や。 例あげたろか、たとえばやなあ構造体から進歩してクラスをabで使うと、 class c_test public var1 as integer sub hello() print "hello" end sub sub show() print var1 end sub end class dim a as c_test a.var1=123 a.show() a.hello() 等とするちうわけや。構造体とメソッドが一体化したクラスと呼ばれるもんとなるちうわけや。クラス内の変数var1 は構造体のように参照できて、関数やプロシージャもクラスとつよ結びついとる。 実際に使う際には、aちう変数はc_test型の変数ちう意味になり、 クラス内の各要素は"."ドット記号を使うてアクセスするちうわけや。こら構造体と同じや。 せやけど、構造体とちゃうんは、変数と関数/プロシージャもドットでアクセスできること。 オブジェクト指向言語では、 a.var1のようなクラス内にある変数を、メンバーとかプロパティちう。 クラス内の関数やプロシージャを、メソッドちう。 クラスが初期化されたときにじぇったい呼ばれるメソッドもあるちゅうワケや。また消去されるとき にじぇったい 呼ばれるメソッドもあるちゅうワケやそれらをコンストラクタ、デストラクタとよぶ。 ここまでの例は、クラスをつこうただけ。オブジェクトは関係してへん。 クラスだけでも色々なことが出来よるが、 今度はクラスに基づいてコンピュータ上にオブジェクトを作成してみるちうわけや。 class ctest public ary[100] as integer sub clear() dim i as integer for i=0 to 99 ary(i)=0 next i end sub end class dim obj as *ctest obj=new ctest() obj- ary(10)=123 obj- clear() print obj- ary(10) delete obj debug ここではクラスとしてctest型を定義してん。定義は前と同じ。ちゃう所は、dim文以降。 dim文(dim obj as *ctest)でクラスctestの型のポインタをobjとして作り、new演算子で コンピュータ内のメモリーにctest型のオブジェクトを動的に作成するちうわけや。 objは、そのオブジェクトの位置を示すアドレスが保存されるちうわけや。newされて動的にメモリが 確保されたオブジェクトを指し示してん。 こないな作ったオブジェクトは参照時にはアロー演算子"- "を使うわ。単にクラスに定義 されとったもんを参照する場合は、"."演算子でよかったがここではちゃう。 newしてクラスからオブジェクトを作る場合はアロー演算子を使うと覚えておきまひょ。 さらにオブジェクトはnewで作ったら、消さなあかん。作ったもんの責任で。 それがdelete objで、deleteされて始めてコンピュータ上から消えるちうわけや。 こうしてnewで動的に作成したオブジェクトは、インスタンス(実体)とも呼ぶ。 ここで作ったオブジェクトは配列機能を持つもんやけど、単に変数を配列として作るより 進化してん。 なんでやったら、配列データと手続き(clear)が一緒になってて一つのクラスとして定義されとる。 今回はclearちうプロシージャだけやけど、配列操作に便利ええ関数が他にもあれば便器...おっとちゃうわ、便利や。 newしてクラスからオブジェクトを作る行為は、動的にメモリを確保するmallocに近いとも 言えるちうわけや。 単にクラスを使う場合と、動的にクラスからオブジェクトを作る方法があんねんと覚えて おきまひょ。こら用途によって区別するちうわけや。 クラスについてもう少し考えてみよう。 例えば、整数型というクラスCIntがあったとして、 CInt.Maxsize CInt.to_double CInt.to_strings Dim obj As CInt(100) print obj.Maxsize print obj.to_double やらなんやらちうメンバーがあったら興味深いちうわけや。なんでやったら概念として、整数ちうクラスがあって、 それらのオブジェクトは、どないな整数値であっても最大値を知っとるし、文字列変換の 関数を知ってて、実数に変換する手段も知っとる。 機能は関数ライブラリではなく、整数ちうクラスが知っとるべきや、ちう訳や。 今までやと、変数ちう値と、手続きは別やった。文字列や実数への変換は、BASICの 標準関数から探す必要があるんや。こら抽象的に物事を扱いたいときにはひどく見通しが悪う 便利わるい。 アニメキャラクタの服を変えると言うたとき、obj.change()と書いたほうが現実をより上手く プログラム上で現してん。 ウインドウズやらなんやらのOSの例でも同じや。 CWindowちうクラスがあって、ウインドウを表示したり座標を知りたい場合、 obj.show() position=obj.x ちう書き方のほうが、便利や。いちいち別関数のwin_show(obj)やなんて書いとる必要はあらへん。 さらに、CWindowちうクラスによって、単なる数列の塊が、ウインドウちう存在に きわめて近い扱いを、プログラミング言語上で行えることに注目してほしおます。 もし、abにBASICのクラスがあれば、標準関数やのうてクラスを使えるちうわけや。 CInt,CDouble,CStringやらなんやらのクラスがあれば、使う側はBASICライブラリやのうて クラスを使えるちうわけや。そのとき、文字列は、 Dim str As CString("hello") str.length() ....ｲｺｰﾙ... "hello".length() とするやろ、ほしたら文字列自体がオブジェクトやから、自身の文字列の長さをオブジェクトが 答える事ができるようになるちうわけや。 継承 さらに、クラス間にはやや共通した側面があることにも気づく人もおるやろ。 例あげたろか、たとえばやなあ、コンピュータのウインドウやボタンやエディットボックスはみな画面に表示される が、座標系ちう共通した値を保持してん。 数値ちう能書きには、四則演算が共通してて、似とる。数の分類をクラスで表現できるんとちゃうか、ちうアイデアが生じるちうわけや。 CNumber ---- CInteger --- CIntArrayList +-- CLong +-- CDouble ---- CComplex +-- CVector こないなふうに、数とゆうグループがあって、整数/実数のほか、それらのええトコを含むベクトル とか複素数なんてグループ化が出来るちゅうワケや 時計の例なんてものも考えることが出来るちゅうワケや CObject --- CClock ----- CDigitalClock +-- CAnalogClock まるで進化の過程のようやけど、これらのグループ分けもクラスで可能で、それらを継承とか クラスの継承ちう。 ここでは、CNumberがクラスのホンマの基本機能しかいないちうわけや。これをスーパークラスちう。 子クラスはスーパークラスに機能を追加して作成されたもんや。 オブジェクト指向のクラスは、こうして機能の継承関係を使うて、重複した機能を実装する 必要なく、全体をどエライ上手くライブラリとして実装し、表現するっちうことができるちうわけや。 使う側も、CClockの基本メソッドを知っていれば、デジタルもアナログもクラスとしては まるっきし同じインターフェースで利用できる事になるちうわけや。 これらの図で示した継承ちう機能のツリーを継承ツリーと呼ぶ。 これらの継承図をダイアグラムで表現する方法は幾つも提案されており、Microsoftの エクセルやVC++をこーたら貰えた緑色のクラス図のポスターや、UMLやらなんやらが有名なんや。 他にも幾つもあるんや。自作するっちうことも可能や。 実際にabのクラスで継承を使うには、 class CSuper public var1 as integer sub test() end sub end class class CMyObj inherits CSuper public var2 as integer sub mymethod() end sub end class とする。ここではCSuperがスーパークラスで、それを継承してCMyObjが作られておるちゅうワケや CSuper --- CMyObj とゆう継承関係だちゅうワケや。 inheritsという箇所で、継承元のクラスを指定する。 このCMyObjはCSuperを継承しているので、当然CSuperとCMyObjの両方のメンバが利用できる。 つまり、 dim obj as CMyObj obj.var1=10 obj.test() obj.mymethod() が可能ちう訳や。逆にCSuperでは、var2やらなんやらのメンバーは無いので使うことはでけへん。 この関係を上手く利用してクラスを作ると、どエライ判りやすいちうわけや。 CSuperには仮想関数(VirtualFunction)ちうメソッドも定義できるちうわけや。こらスーパークラス であらかじめ定義しておき、継承後にメソッドを書き換えることが出来よる特別なメソッドや。 例あげたろか、たとえばやなあ、CClockで定義したメソッドのうち、CAnalogClock/CDigitalClockで異なる実装が 必要な場合、継承後、クラスの仮想関数を書き換えるちうわけや。 そうするっちうことで、クラスの継承を利用し、クラスの多様性を確保してん。 仮想関数ゆうものがあることも覚えておきまひょ。 クラスには継承ちう親子関係が存在し、それを利用するっちうことで、データ構造を あんじょう扱うことが出来よる。 こうして作成されたクラス群をクラスライブラリちう。使う側はクラスライブラリを 利用するだけで高機能なプログラミングが可能や。 あらかじめ目的によってクラスが用意されていれば使う側は楽でええ。 上に示したCNumberクラスも、クラスライブラリちう。 クラス設計 ここまでくると、プログラミングの作業は、クラスライブラリの設計如何にかかっとるというても 過言ではない。なんでやったら、クラスライブラリの設計は目的や現実のもん毎に基づいて設計されるため、 じぇったい、この設計段階が重要になるさかいや。 従来型のプログラミングと比較して、オブジェクト指向言語ではクラスライブラリの設計が大きな鍵を 握ることになる。 また、クラスライブラリを使うプログラミングの場合、利用者は頻繁に継承をつかうことは 避ける必要があるんや。 なんでやったら、本来、継承はクラスライブラリの設計が関係してん問題で、 プログラム段階で特別クラスが必要となる以外、頻繁に継承をする必要はあらへんからや。 混乱の元となる可能性も高なる。 オブジェクト指向の本に、りんごは赤く、丸いもん云々ちう説明があるんは、現実の世界の 特徴や側面に注目して、現実の物体をオブジェクトとして表現する際に、何に注目する必要が あるんかをぬかしておる。 ようけのオブジェクト指向プログラミング言語は、言語レベルでごっつう巨大なクラスライブラリ が作られとる。使う側はそれらを組み合わしたらよいちうわけや。 ab4ではクラスライブラリは存在せんが、自作プログラムの為にクラスライブラリを作る場合は、 目的に基づいてじぇったいクラスの設計をする必要があるんや。 コンポジション 今までクラスは継承ちう関係があり、それを利用して機能を持たせることが可能と書いたわけや。 この継承ちう関係は、クラスの親子関係が存在する場合に当てはまるもんや。 たとえばやなあ、アナログ時計ちうクラスを作った場合、時計ちう上位のクラスから継承するっちうことになるちうわけや。 これを言葉で言い表したら、”アナログ時計”は”時計”ですね、ちう文脈がなりたつ。 要は、継承ちう機能が使えるんは、こないな言葉で表現できる範囲のなかにあるクラスの関係であるちうことや。 CObject - CClock - CAnalogClock + CDigitalClock この例では、CAnalogClockはClockの仲間として分類できるさかい、こないな関係でクラスを継承ちう機能を 使うてまとめることが出来よる。 これに対して、べつの考え方があるんや。たとえばやなあ、 class CMyClock public sub setTime() dim obj as CDigitalClock() obj.time("00 00 00") end sub end class dim clockobj as CMyClock やらなんやらのクラスがあったとする。このクラスはわし(俺)クラスでオノレで作ったもんやけど、 こら継承を使わんといて、単に親クラスとなるCDigitalClockのクラスをsetTime()メソッド内で使うておる。 機能としては継承を使うておらへんが、まるっきし別のクラスちう訳とちゃうんや。なんでやったらメソッドsetTime()内部 で、CDigitalClockクラスを使うておるからや。こら継承と似た機能と考えられはる。 CObject - CClock - CAnalogClock + CDigitalClock +===== CMyClock こないな考え方も出来よるちうわけや。 こないな関係をコンポジションちう。こら継承を使わんといて、他のクラスを継承を使わず代替する方法の一つで、 言葉で言い表すと、"マイ時計クラス"は"時計"を持ちまんねん、ちう文脈になるちうわけや。継承せん代わりにクラス内で インスタンスやクラスを利用して、継承と似たような機能を実現できる訳や。こないな方法やと継承を 利用せんので,クラスライブラリの設計には影響せんが、逆に一見して記述から親クラスと強い継承関係にある ことがまるっきし判らんゆうデメリットもあるんや。 こないな違いを区別して使うには、一つの判断方法として、言葉の文脈が当てはまるか否かで判断する、ちう 考えかたもあるんや。クラスAをスーパークラス、クラスBを子クラスとして考えると、 クラスBは、クラスAの仲間です。又は、仲間ですか？ クラスBは、クラスAを含みます。又は、クラスAを使うだけですか？ ちう文脈が成り立つ。 上に当てはまるんやったら、継承を使えるし、後者やったらコンポジションが使えるちうわけや。 そないにしてクラスライブラリの設計やらなんやらを行うわ。 デリゲード デリゲードは日本語では委譲ちう。あんまりどシロウトレベルでは扱いまへん話やけど、そういった能書きがある ちう事だけ覚えておきまひょ。 簡単にデリゲードを考える事はそれほど難しない。たとえばやなあ,これまでクラスについてさまざまに考えてきたが、 このクラスは簡単に、もう一つの表現で言うたら、クラスは変数型ともいえるちうわけや。 変数型にはいくつもん型があるが、もしポインタやらなんやらの考え方が可能やったら、 VoidPtr型が存在するっちうことに気づくやろ。実際、abにはVoidPtrちう型があるんや。 ポインタやポインタのキャストになれた人やったら、例あげたろか、たとえばやなあ、Long型の変数を、VoidPtrで扱う事が、 それほどむつかしことではおまへん、ちう点に気づいとる。 実際、abのいくつもん変数型は、VoidPtrで指し示す事が出来よる。 これと同じ考えをクラスでも行えるちうわけや。 たとえばやなあ、CClockちうクラスは、実はVoidClassみたいな型で扱え、CClockちう型で、CAnalogClockや CDigitalClockのクラスやオブジェクトを扱えることになるちうわけや。 CAnalogClockはCClockの子やから、共通してんCClockの型としてのポインタでCDigitalClockが参照できても おかしくはあらへん。 これのメリットは、要は、クラスのキャストを使うて、まるっきし別のクラスのメソッドを呼び出せる(参照可能) ちう点にあるんや。 これが、委譲と呼ぶ意味や。 ちーとばかしええ加減やけど、 dim obj as *CClock() obj=new CDigitalClock() のようなことをして、型のキャストを使うて、別のCAnalogClock()のメソッドに、任せてしまおうゆう方法や。 (abでこないな風なことを出来よるか不明やけど) 実は、javaのインターフェースやab5のインターフェース文は、まさにこのデリゲード,委譲ちう方法を実現する 一つのメカニズムで、インターフェースちうキテレツなクラスに似たような機能を持ち、型として扱われることで、 クラスをキャストしてVoidPtrのような型として考え、他のクラスのメソッドを間接的に使うわ。それらの別クラス 実装に任せる事が出来よる訳や。 インターフェースちう構文は、そないな型のキャストのためにあるというてもええ。 ab4ではクラスのポインタのキャストが出来れあほのうやろし、ab5ではそもそも新しい機能としてインターフェースが 備わっとる。 クラスにはデリゲードちう考え方もあんねんと覚えておきまひょ。 オブジェクト指向の概念 ここまで、クラスとオブジェクトの関係がわかったトコロで、本来のオブジェクト指向言語 での能書きとの違いを理解しておく必要がある。 abのオブジェクト指向言語としての実装は、C++を参考に作られててクラスベースと なっとる。コンパイラとスクリプト言語等のインタプリタでは構造も異なるので それらの違いもあるんや。 オブジェクト指向の能書きはホンマはちごてて、 C++のオブジェクト指向が一つの方言であることを理解しておく必要があるんや。 本来、オブジェクト指向とは、さまざまなデータをカプセル化するっちうことによるメリットを 強調してん。 個々の変数を扱うよりも、クラスとほんで生成されたオブジェクトに備わった インターフェース機能を介す事で、中身を知ることなく、オブジェクトを使うわ。 そのほうが、楽なこともあるんや。 オブジェクト指向はカプセル化や隠蔽ちう手段としたかて利用できるゆうことや。 ユーザーは細かいソースコードまで目を配ることはあらへん訳や。 カプセル化のイメージは、データと手続きが一つのセルとして組み込まれた独立した単位 として捕らえる事が出来よる。 セルの中身には変数が保存されてて、わてたちが使う場合、変数を参照したり、セルに 含まれる関数を実行したりするちうわけや。セルは抽象的な丸い物体のようなもんと考えるちうわけや。 そこで、考え方を変える必要がある。 オブジェクト指向言語では、四則演算子の記号は、従来の言語と違って それはメソッドである。 1+1 これは式や。手続き型プログラミング言語では式として扱うわ。せやけどオブジェクト指向ではちゃう。 この式は、オブジェクト指向の世界では、１ちう数値オブジェクトが、+ちうメソッドを介して 1を扱っとる、と解釈するちうわけや。 こら従来型のプログラミング言語しかつこうたことのあらへん人にはどエライ大きな飛躍や。 メソッドにアクセスする演算子"."をわざと使うて表現したら、 1+1 1.+ 1 1.add 1 1.add(1) という事になる。これら意味はすべて等しい。 しかも、この処理は、1ちう式を扱っとるのやなく、メッセージ(文句)として扱っとる。 ゴチャゴチャゆうとる場合やあれへん、要は、1ちうオブジェクトに、メッセージ(文句)を与えとる、と解釈されるちうわけや。 オブジェクトと、オブジェクトの間を、文句を伝え合って処理をする、ちう概念が 本来のオブジェクト指向言語の基本の考えや。 こないなモデルをアクターモデルちう。 単に関数を呼ぶとか、実行する、事やのうて、オブジェクトは独立したもんで、それに メッセージを送ったり、受けたりする、といったほうが振る舞いとしてええ。 もしスレッドを知っていれば、オブジェクトがスレッドで実行されとったら、 コンピュータ内にはどエライようけのオブジェクトが動き、メッセージを処理してん と理解するっちうことも可能やろ。 こないな概念が本来のオブジェクト指向の持つ意味や。 obj.i=123 obj.clear() ちう式は、本来は、オブジェクトobjのメンバーiに123ちう値をメッセージ(文句)として渡し、 obj.clear()で、オブジェクトにメッセージ(文句)を出してん事と等しおます。 やから、言語によってはレシーバ等と表現する事もあるんや。 abのオブジェクト指向は、C++を参考にしとりC++にどエライ近いちうわけや。せやけどダンさん、従来型の記述が可能 やから、クラスのメソッドや関数について、それらをメッセージ（文句)として明示的に扱うことがあらへん。 本来はメッセージとして理解するんがホンマやと覚えておきまひょ。 ほんで、オブジェクト間の相互関係にも法則性があり、それらはコンピュータアルゴリスム のように一定のパターンが見出せるちうわけや。それがデザインパターンなんやし、 デザインパターンとは、オブジェクト間のやりとりの基本構成や機能をまとめた、アルゴリズム のパターン集のようなもんや。 歴史 元々、オブジェクト指向言語の歴史や発想はちーとばかし変わっとる。 アランケイちう人が、コンピュータの研究をするプロジェクトの過程において、simulaちう言語を使うていてそれらの経験が あった訳やけど、同時代の数学教育研究者の実験的プロジェクトにヒントを得ることになりよった。 それが、ロゴちう言語を作った人やったが、そのロゴちう言語は元々はロボットを使うてボウズ(子供)にプログラミング の要素を教える事を考えとった。 ロボットに命令を与えると、紙の上でモーターで動いて、ペンを操作して絵を書く。ロボットの中心でペンが上下するちうわけや。 この機能で紙の上に絵を書く事が出来よる。これがタートルグラフィックと呼ぶ機能の原点や。 今現在のプログラミング言語にもタートルグラフィックが可能な環境もあるが、まるっきし面白ない。なんでやったら、 ロゴちう言語は、ホンマはロボットを動かす為の言語やから、画面上で動いて絵を書く事が出来ても ハードウエアとしてのロボットがまるでシカトされとるさかい、まるっきし意味があらへん。 ロボット操作言語で教育する、ちう製作者の意図をまるでシカトしたかのような配布物やった。 教育言語としてやまとに紹介された時もゲームが作れんと判ってまるっきし相手にさられへんかった言語や。 処理系も入手しずらく動作するコンピュータもなく、モニタ上だけでタートルが動くそら、実際、つまらへんかった。 アランケイは、このロゴちう言語自体やのうて、ロゴを使うて、機械(ロボット)を操作する、ちう考え方に興味を持ったちうわけや。 ゴチャゴチャゆうとる場合やあれへん、要は、ロボットに命令を与える、ちう考え方自体に注目しとった。 命令を与えれば、ロボットは動く。複数のロボットが動く状況も同じ。機械に命令を与える方法として、アランケイは ごく自然にそれらを考えたちうわけや。 コンピュータに命令を与える際にも、同じことが言えへんか、この発想がオブジェクトモデルの原点や。 ちーとの間して、ある研究員が、この新しい発想にもとづいた代数を説明したちうわけや。なんちうか、 ようみなはんいわはるとこの、 1+1 1.+ 1 1.add 1 1.add(1) のようなもんやった。休暇中、これらを検証するために当時のBASIC言語で、簡単なモデルを作ってみて、 アランケイに見せてみたちうわけや。 ちーとの間して、この代数モデルが、ホンマに代数として機能するっちうことが判明し、新たな言語が開発される事となりよった。 アランケイは元々simulaをつこうた事があったさかい、そないなアイデアも参考にしたちうわけや。 その結果、スモールトークちうプログラミング言語がゼロックスで開発されたちうわけや。 この言語は、オブジェクト指向言語として、ホンマにロボットに絵を描かせる時のように、コンピュータに文句を伝えて 操作するちうわけや。手続き型プログラミング言語とはまるっきしちゃう。これが今のオブジェクト指向言語の大きな源流となっとる。 したがちう、オブジェクト指向言語では、オブジェクトに文句を与えるゆうアクターモデルとなっとる訳や。 不思議な事に、この言語は機能を拡張しやすい特徴を持ってて、直ぐにGUIの動作するコンピュータが 作られはる事になりよった。これがホンマに現在のマウスとウインドウやらなんやらを使うコンピュータの原点で、ゼロックスで 研究、開発が行われたアルトと呼ぶコンピュータや。 これらのコンピュータ向けに様々なソフトウエアが書かれたちうわけや。 このコンピュータを初めて見ていろたアップルコンピュータの人々が、のちにマッキントッシュと呼ばれるマシンを作るきっかけ となりよったちう一連の経緯はどエライ有名や。 マッキントッシュは、パーソナルコンピュータの世界で初めてマウスとGUIで操作するコンピュータになった。
https://w.atwiki.jp/memomem/pages/23.html
*抽象クラス(abstract class) 抽象クラスには、一連の関連クラスが行えることを定義します。 *クラス(class) オブジェクトの責任に基づき、該当オブジェクトの型を定義します。責任は振る舞い、および/または、状態に分割することができます。 こういった責任は、それぞれメソッド、および/または、データを用いて実装することができます。 *具象クラス(concrete class) 抽象クラスに対して特定の振舞いを実装したクラスのことです。具象クラスは、具体的かつ不変の概念を実装したものとなります。 *カプセル化(encapsulation) データ隠蔽として定義されるものが多いものの、あらゆるものの(型、実装、設計など)の隠蔽を指していると捉えるべきです。 *継承(inheritance) クラスが他クラスの持つ一部あるいはすべての性質を受け継ぐ場合、そのクラスから継承を行うことになります。この場合、 元となるクラスを基底クラス、スーパークラス、親クラス、汎化クラスなどと呼び、継承するクラスを派生クラス、サブクラス、 子クラス、特化クラスなどと呼びます。 *インスタンス(instance) クラスに属する具体的な実態のことです(常にオブジェクトとなります)。各オブジェクトには自らの状態が保持されているため、 同じ型(クラス)に属する複数のオブジェクトを使用できるようになります。 *実体化(instantiation) クラスのインスタンスを生成することです。 *インターフェイス(interface) インターフェイスはクラスとよく似ていますが、構成要素の使用のみを提供し、実装を提供するものではないという点が異なっています。 この点では、抽象メソッドのみで構成された抽象クラスと似ているでしょう。プログラミング時においては、共通する基底クラスを 持っていないクラス群に、特定の(抽象的な)性質を実装させたいという場合にインターフェイスを使用します。 *観点(perspective) オブジェクトを見極める場合、概念、使用、実装という3つの観点から捉える必要があります。これらの違いは、抽象クラスと その派生クラスの関係を理解する上で有効なものとなるのです。まず抽象クラスによって、物事を概念的に解決する方法が定義できます。 また、そこから派生したものを用いることで、通信を行うための仕様が定義できます。さらに、それらを用いることで、 必要となる特定の実装を導き出すことができるのです。 *ポリモーフィズム(polymorphism) あるクラスから派生したさまざまなクラスを同じ方法で参照しつつ、派生クラスごとに定義されている適切な振る舞いを引き出すことです。 参照元【-デザインパターンとともに学ぶ-オブジェクト指向のこころ】 オブジェクト指向とは