甲府方重信Blog

...Shigenobu Koufugatas Blog

  • Increase font size
  • Default font size
  • Decrease font size
Error
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
Home 業務日誌 Adaプログラミング Adaチュートリアル セクション18.2 - Smallのオブジェクト指向クラス階層

Adaチュートリアル セクション18.2 - Smallのオブジェクト指向クラス階層

E-mail Print PDF

セクション 18.2 - Smallのオブジェクト指向クラス階層

私たちは、まだ、パッケージ「Things」において何を取り扱うかを決めていません。また、それに関連するほかのパッケージについても決めていません。; これらは間違いなくもっとも重要なパッケージです。世の中には、たくさんの異なったものが存在しうるのであり、ものはそれ以外のものを含むことが出来ます。通常、アドベンチャーゲームはプレイヤーが行くことができる「部屋」を持っています。また、取り上げることが出来るアイテム、出会う可能性のあるモンスターなどがあります。

[Object Hierarchy] WIDTH=151 HEIGHT=87 ここでは、私が空想したクラス階層を示しています。; これを試して、プログラマーが納得がいくかどうか試してください。この世界のすべてのものは、Thingと考えられます。; 一つのThingは名前を持ち、詳細記述をもち、場合によってはそのほかのThingを含みます。Thingは、Roomであるか、Occupantのどちらかでありえます。Roomは、コネクション(北とか南など)を持つことが出来ます。Occupantには二種類あり、ItemとCreatureがあります。Itemは、鍵やテーブルのようなものです。Cretureは、プレーヤーかモンスターのどちらかになります。「Monster」によって、私は技術的なロールプレイングゲームの定義を意味しています。: モンスターは、プレーヤーと違った自身の動作をするすべてのものです。私は、ここで「Object」という単語を意図して使いませんでした。というのも、私たちはThingではないそのほかのパッケージにおいてObjectを持つ可能性があるからです。

ある意味において、このクラス階層は当初私たちが必要としている以上のものです。(わたしは、現在ただちにモンスターを実装する計画は持っていません) しかし、これはわたしたちに可能性を広げることが出来ます。将来的なバージョンでは、これをさらに拡張することもあるかもしれません。 - 例えば、Door型とKey型がItemの拡張としてあるかもしれません。

そこで、型の階層が分かった場合、これらの型を持つパッケージはどのようの組織すべきでしょうか。Adaにおいては、型はパッケージにおかれます。そして、それらは一対一に対応させる必要はありません。プログラマーは、パッケージに一つ以上の型を宣言することが出来ます。そして、特別な方法においては、それらをグループ化するために子パッケージを使用することが出来ます。しかしながら、 そうでなければ、なにかしら理由があるのでない限り、「シンプルな」方法が通常ベストです。: パッケージに対してタグ付けされた型を作成します。命名規則としては、わたしはパッケージに対しては複数形を用い、型に対しては単数形を用いています。 そこで、タグ付け型「Occpant」が、パッケージ「Ocuupants」におかれます。それぞれのパッケージは、その親のパッケージを「with」することを必要とします。そこで、わたしたちは、Things、Rooms、Occupants、Items、Creatures、Monsters,Playersの名がついたパッケージを得ます。

さて、わたしたちは作成すべきパッケージが分かりました。それらの内部では型の定義はどのようにしたらよいでしょうか。 さて、Thingとすべてのその子孫は、タグ付け型でなければなりません。というのは、わたしたちは継承を持っているからです。Room、Occupantあるいはそのほかの子に対するすべての型定義は、次のようになっているでしょう。:

 

 type X is new PARENT with private;

あー、この階層のルートの定義はどのようにすればよいでしょう。(この場合は、Thing型になります)。 わたし達は直ちに、これを必要とする訳ではありませんが、おそらくいくつかのオブジェクトが作成されたり、削除されたりする際に起きるために、特別なものを起こすようにしたくなるはずです。これは、わたし達が「コントロールド」型を必要としているように聞こえます。これは、わたし達にそのようなことを許可するものです。しかしながら、わたし達はそれらの間の割り当てを可能にする必要がおそらく無いので、そこでThing型を新しいバージョンである「Limited_Controlled」型として作成しておくべきでしょう。 Thing型は、なんらか直接インスタンス化されることはありません。; その代わり、プログラマーはそれの子のインスタンスを作成することが出来ます。このように、Thingは抽象型としておくべきでしょう。; 抽象型として宣言しておくことによって、誰もそれをインスタンス化することが出来なくなります。ここで、Thingの定義を掲載します。(これは、パッケージThingsにおかれます)。:

 

 type Thing is abstract new Limited_Controlled with private;

これらのいくつかの決定をなす根底には主要なルールがあります: パッケージ仕様においては、必要以上の露出は避けるというものです。例えば、わたしは、いたるところで「with private」を使うことを選択していることに注意してください。これは、これらの型の実際の実装がパッケージ仕様のプライベート部に隠されることを意味しています。そして、ユーザーからは直接使用されることが出来ないのです。これは、わたし達がユーザーにインパクトを与えることなしに、後で実装を変更することができることを意味しています。

出典: http://www.adahome.com/Tutorials/Lovelace/s18s2.htm

Last Updated on Sunday, 28 September 2014 18:36  

ニュース速報

リナックスアカデミーでのLinuxセキュリティの4回目。

内容は、

1、CentOS 4.8のネットワークインストール

2、サーバーの構築。ただし、セキュリティに考慮したものにする。

手順が簡略化されているので、とまどっている様子。

PCによっては、CD-ROMが認識されないものがある。