コラム / テトリスぽいもの / 4

• Prev
• Next
• コラム/テトリスぽいもの

まずは、積もったブロックを定義するクラスを作ります。
クラスってのはあれですね、
インスタンスを作って、
変数、プロパティ、手続き、関数を持ってる難しい奴。
あれを自作します。

type

 //ここに記述します

 TForm1 = class(TForm)
   PaintBox1: TPaintBox;
   Timer1: TTimer;
 private
   { Private 宣言 }
 public
   { Public 宣言 }
 end;

まずは雛形を書きます

type

   TMapBlocks = Class(TObject)
   private
   public
       //変数定義
   end;

 TForm1 = class(TForm)
   (略)

TMapBlocksというクラスを定義しました。
変数定義はvarでしたが、
クラス定義はtypeです。

type
  宣言１
  宣言２
  宣言３
  ・
  ・
  ・

といった風に、type以降に羅列していきます。
その一個一個の宣言方法を見て見ます。

クラス名 = class(継承元)
private
public
end;

今回の場合、クラス名は TMapBlocks です。
さて、継承元とはなんでしょうか。
実は、クラスという概念の、一番すごい部分が、この、「継承」です。

例えば、
白黒テレビクラス　を定義したとします。
白黒テレビクラスには、「画面を出す」　仕組みが既にあります。
ある日、カラーテレビクラス　を　定義したくなったとします。
画面を出す　仕組みは、白黒テレビクラスで作ったので、
これを流用できるのです。
そのためには、白黒テレビクラスを継承するだけです。
そして、独自の部分として色をつける処理だけ追加して、
カラーテレビクラスが作れます。
さらにまたある日、
プロジェクタークラスと、プラズマディスプレイクラスを作りたくなったとします。
プロジェクタークラスは、ブラウン管の仕組みをちょいと変えて、
紙に光を当てられれば作れます。（いや、知らんけど
そのためには、カラーテレビクラスを継承し、
新しく、「強い光で投影する」という処理を追加して、
「画面を出す」処理をその処理の中に合成します。
一方、プラズマディスプレイクラスを作るには、
「色をつける」部分は併用できますが、
根本的に仕組みが違うので、「画面を出す」部分はちょっと使えません。
そこで、「画面を出す　処理を　上書き」してしまいます。
でも、色を扱ったりする手法や、
テレビという箱を製造する技術はそのまま継承しておきます。

うーん、ずいぶん大げさなたとえですが、
本当にこんな感じです、クラス。
つまり、
「継承元の機能は全て持っている」というのが前提で、
その上で、「一部を上書きしたり、新しい機能を付け足す」
という事ができます。

まぁ、今回は、ゲームのフィールド情報を定義するだけなので、
特に継承すると嬉しいクラスもないので、デフォルトの、
TObjectを継承しています。

   TMapBlocks = Class(TObject)

ま、継承に関しては、テトリス製作では触れません。

で、その下の、 private public というのは、
「可視性」の情報です。
またもやテレビで説明するとします。

テレビクラスを、もっと詳しく考えた場合、
テレビを使う人のための部分と、そうでない部分があります。
テレビには、「電源を入れる」という手続きがあります。
電源を入れるのは、テレビを見る人のためにある機能です。
しかし、テレビの中にある、「映像投射機構」を考えてみてください。
テレビを使うときに、
いちいちテレビを分解して、中の機械を触ったりする人はいません。
（あくまで、一般ユーザー　の話
もし、映像投射機構が、誰でも触れるようにむき出しになっていたら、
うっかりそこを触ってテレビが爆発するかもしれません。
つまり、道具というのには、
「使う人がいじるための機能」
「道具を正しく動作させるための、いじられちゃ困る機能」
の組み合わせでできている、というのが、クラスの考え方です。

さて、それをクラスで考えると、
「クラスが定義されているユニットのコードからのみアクセスできる要素」
「すべてのコードからアクセスできる要素」
という考え方になります。
で、その、ユニットのコードからのみ、という要素を書く部分の始まりが、
private
すべてのコードからアクセスできる　という要素を書く部分の始まりが、
public
というわけです。
つまり、

おにゃのこ = class(人間)
private
    思考
    感情
public
　　おっぱい
    服装
end;

って感じです。我ながらこの例は良いと思う　うん　ﾊｧﾊｧ
おにゃのこは人間を継承しています。
人間の全要素を持っているからです。
で、private 、すなわち、外部から直接アクセスできないのが、
思考とか感情です。
もしここに介入して自由に操作できたら女の子が爆発します。
で、対してpublic、外部からアクセス自由なのが、
おっぱいとか服装とかです。
どっちも「読み込み」は簡単です、つまり、
「見るという操作には、おんなのこ　というシステムは対応している」
といえます。
もし見てるだけでおんなのこが爆発したら設計ミスです。  
正しい使い方なのにバグがあるのは困ります。
まぁ、服装とかおっぱいに、「書き込む」のはちょいと難しいですが。
下手するとホリエモンの同居人になりかねん。くわばらくわばら。
やっぱりあんまりいい例じゃなかったです。
使おうとしても暴走する危険があるってことは、
単体のインターフェースとして問題がありますね。
おっぱいも服装もprivateで定義して欲しいものです。
いや、そうしなくても、
「読み取り専用」というのが使えるのが、
「ぷろぱてぃ　」なんですけど、
まぁみなさんの頭が爆発するまえに俺の妄想終わり

結局何がいいたいかっていうと、
クラスには可視性　っていうルールがあるよ　ってことです。

まぁ、、、結局、
今回はユニットファイルを分けないので、
可視性も何も無いです。

ユニットファイルの説明はまたこんど。
TMapBlocksクラスの実装を次回からやっていきましょう。
といっても、ゲームが早く動かしたいと思われるので、
最低限だけやったら、適宜追加していく方針でいきます。

• Prev
  コラム/テトリスぽいもの/3
• Next
  コラム/テトリスぽいもの/5
• Home
  Up