第9回　保存先の変更 その3 - OOP講座

これを、実際に今までのプログラムに少し埋め込んでみます。
埋め込む場所はbbs_dataクラス。…どこで出てきたのか思い返してみると、第一回なんですねぇ。ちょっとびっくりです。
せっかくなので。今までの「ファイルを使うbbs_dataクラス」は潰さないようにしながら、新たに「DBを使うbbs_dataクラス」を作成してみましょう。
本当はもう少し丁寧に「親クラスと子クラス」を作成するのですが、一端ざっくりと切り込んでみます。

list 2

bbs_data_db.inc より

このように継承を使う事で、比較的簡単に機能を追加する事ができます。継承はまた次回に細かくやっていきますので、とりあえず「あぁそういえば継承って単語があったなぁ」程度に思い起こしてみて下さい。

上述はSQL文を直接プログラムに埋め込んでいますが。別解としての「SQLファイルを用意する」という手もあります。
その場合

• SQLになにがしか、番号なりIDなり名前なりを割り振る
• その名前がアクセスされたら該当するSQLを探し出して実行する

という流れになります。

この辺はやはり賛否両論ありますので、その辺を踏まえた上で考えていただけると。 筆者的には「listをとるSQLに関してはあり」だと思っていますが、一方で「全てをSQLファイルに切り出す」と、後々の「テーブルへのフィールド追加に伴う修正」とかが結構広範囲になってしまうので、比較的好まない傾向にある、って感じですかね。
そこの現場さんの流儀、状況、要求内容にもよるので、一概にはなんとも言えないのですが。

総括しますと、オブジェクト指向プログラミングでRDBを扱う時は、大まか「DBハンドル」と「SQL」とにわかれまして、前者は、比較的きれいにオブジェクト化することが出来る一方で、後者は、特に「SQLをある程度しっかりがっつりつかったもの」に対して「未だ議論冷めやらず」といった、大変にhotな状況のままになっています。

これを「全部混ぜてしまう」と「オブジェクト指向でRDBを扱うのは難しい」となってしまうので、とりあえずDBハンドルくらいはきれいに扱った上で、SQLの、特に「厄介なところ」について、何をどうしたいのか意識を集中していきたいところです。

次回は、最後のお題「認証処理の後出し」をやっていきたいと思います。
これもまたなかなかに厄介なところですが、同じくらい、大切なところです。