2014年3月28日金曜日

2014年2月の社内発表会

2014年2月から社内の発表会をブログに載せることになりました。
本当は2014年1月から実施する予定でしたが、
担当がインフルエンザにかかってしまったので1か月遅れの開始となりました。

今回は、改めてオブジェクト指向とSQLを考えてみました。


オブジェクト指向)

オブジェクト指向の考え方は、私の知る限り25年前から耳にします。その頃は「オブジェクト指向とC++」なんて書籍が本屋さんに並んでいました。その中で私の目を引いたのは「オブジェクト指向でC言語の限界」(?)だったかな。オブジェクト指向でC言語の実装方法が記載してありとても分かりやすかった。

オブジェクト指向を実現する手段として、C++やJavaはオブジェクト指向を実現しやすい言語だけど、その言語を使ったからと言って全てがオブジェクト指向かと言うと?ですよね。

今回はオブジェクト指向の考え方から始めました。
プログラミングを少しかじったことがある人は、プログラムを見せると直ぐロジックに食いつきます。でもロジックを追ったところで何の処理かなんてわかりません。本来はどんな入力情報で、どんな領域構造で管理しているのか、どんな出力情報があるのか。それが分かれば処理は自然と見えてきます。要は処理というのは管理情報が全てです。

オブジェクト指向は管理情報を中心としたデータ指向です。
1つのオブジェクトに対し必要な属性(管理情報)を持たせることで、管理自体をオブジェクトに任せる(カプセル化)考え方です。その管理情報を取り出す手段としてメソッド(メッセージ)を考えます。オブジェクト指向はどんな言語でも実現できる考え方です。


ちょっと昔を思い出し、C言語で簡単なオブジェクト指向プログラムを作ってみました。やっぱりC言語好きだな、ポインタが楽しい。

・String.h(ヘッダーファイル)

struct String {
        char *string;
        int  (*Equals)(struct String *, char *);
        int  (*Length)(struct String *);
};

struct String *CreateString(char *);


・String.c(クラスソース)

#include 
#include 
#include 
#include "String.h"

int Equals(struct String *string, char *compare) {
        return strcomp(string->string, compare);
}

int Length(struct String *string) {
        return strlen(string->string);
}

struct String *CreateString(char *string) {
        struct String *s = malloc(sizeof(struct String));
        s->string = malloc(strlen(string)+1);
        strcpy(s->string, string);
        s->Equals = Equals;
        s->Length = Length;
}


・main.c

#include 
#include 
#include "String.h"

int main(int argc, char **argv) {

        struct String *abcObj = CreateString("abc");
        int length_abc = abcObj->Length(abcObj);
        if (abcObj->Equals(abcObj, "xyz")) {
        }

        struct String *defObj = CreateString("def");
        int length_def = defObj->Length(defObj);
        if (defObj->Equals(defObj, "xyz")) {
        }

        exit(0);
}


SQL)

SQLは時間がなかったので少し駆け足でした。SQLってDBへの問い合わせですがどのように動作しているか?から始めました。
一般的にRDBはクライアント/サーバ構成なのでSQLを発行するクライアントはサーバと通信を行い、実際のSQLはサーバで実行されます。クライアントとサーバの通信はSQLのオーバヘッドとなるので1度のSQLで結果を求めるために長文のSQLを組んだりします。
実際はクライアントは自分だけでなく他にも動作しているので、これではサーバに負担を押し付けてることになりますよね。
サーバのパフォーマンスチューニングで実行計画を元にINDEXを張ったり領域を増やしたりしますが、クライアント処理でやった方が速い場合があります。
そのためにアルゴリズムやマッチング、キーブレイク処理などの基本ロジックが存在します。


やはり文章だけだと何だかなぁですね。
次回は発表会の写真で雰囲気を伝えられればと思います。

0 件のコメント:

コメントを投稿