プログラムでも書いてみよう

VC++6.0でSSL通信

VC6.0++でSSL通信をする場合、OpenSSLを使って、、、と記載されているサイトがたくさんある。

だが、BSDライセンスのOpenSSLを組み込むとライセンス条項は表示しないといけなくなるので使いたくないとずっと考えていたのだがふと名案。

 

IXMLHTTPRequestがSSL通信対応しているからこのクラスに通信を任せてしまえば何とかならないだろうか？

なぜこんなことを考えているかと言うとTwitterのAPIをテストしているのでSSL通信が必要になってしまったのです。

一本でも通信が成功したらまたなんか書く予定♪

C++のtemplate

掲題について、C++を使っている人の中にはC言語から初めた方が実に多い。

ただ多くの方がC言語ベースで、オブジェクト指向やC++のメリットを考えずに、ただ業務などでC++のコンパイラを使っているからC++が出来ると考えている。

 

ここで改めてC++のメリットを2点挙げる。

１．オブジェクト指向

２．template library

 

１については、何冊の本にもなるほどの情報になりパターンなど発展した考え方も特に重要なので気が向いた時に追々に書いていきたいが２の考え方は慣れるまで難しいが慣れてしまえばとても有用なので少し書いていきたいと思う。

 

以下ひとつのtemplateの定義である。

 

/* ソース1 */

#ifndef SINGLETON_TEMPLATE_H
#define SINGLETON_TEMPLATE_H

template < class T >
class SingletonTemplate {

 private :

  //唯一のインスタンス
  static T Data;

  //コンストラクタ
  SingletonTemplate(){};
  SingletonTemplate(SingletonTemplate<T> &){};
 public:
  

  //デストラクタ
  ~SingletonTemplate(){};

  //インスタンスの取得
  static T & getInstance(){ return  SingletonTemplate::Data ; };
};

template < class T >
T SingletonTemplate<T>::Data ;

#endif

 

これはGOFのsingletonパターン（クラスのインスタンスがひとつしか生成されないような実装）の変形パターンである。

要はコンストラクタとデストラクタをprivateに隠蔽しstaticに定義されている変数はひとつしか生成されない。

このクラスのgetInstanceをコールすることによりstatic変数を取得できる。

といったパターンである。

singletonについてはnetに情報が腐るほど転がっているのでそれを参考にしていただきたい。

 

このコードではtemplateの部分が重要なのであるが、この記述のルールは「class Tと言うデータ型を仮に定義してあり実際に利用する際に後から定義する」ということである。

利用する際には仮のデータ型を指定する必要があるので以下のような記述になるであろう。

 

/* ソース2 */

class a{

public:

  int data1;

  float data2;

};

 

a & val = SingletonTemplate< a >::getInstance();

 

ではこのときにtemplateの実装のソースをどう読めばよいかと言うと単純にtemplate定義のTの部分を置き換えればよいのである。

 

/* ソース3 */

class SingletonTemplate {

 private :

  //唯一のインスタンス
  static a Data;

  //コンストラクタ
  SingletonTemplate(){};
  SingletonTemplate( a & ){};
 public:
  

  //デストラクタ
  ~SingletonTemplate(){};

  //インスタンスの取得
  static a & getInstance(){ return  SingletonTemplate::Data ; };
};

a SingletonTemplate::Data ;

 

a & val = SingletonTemplate::getInstance();

 

それこそdefineでプリプロセッサが置き換えるようなイメージである。

ソース1のデータ型を実際に記述したのがソース3である。

 

そしてtemplateの記述ルールさえ把握しておけばソース3からソース1への記述を変更することも当然出来るようになる。

このソース3からソース1への修正が出来るようになればコードの再利用が格段にアップするようになる。

 

私の過去の実装をいくつか例にあげてみても以下のようなものが簡単に出てくる。

１．Thread処理についてThreadでの主処理やデータは変わってくるがThreadの生成や同期処理については共通であるためThread処理のクラスは仮定義して共通処理はtemplateとして実装しておく。

２．singletonはデータ型が変わるごとにsingletonのクラスを改めて定義するのではなくデータ型を仮定義してsingletonの主要ルールはtemplateとして実装しておく。

３．通常C++ではmew,deleteを使うがwindowsではバッファを利用しないファイル読み込みなどVirtualAllocを使いたいケースもある。

メモリーの取得方法についてどの方法を使うかは仮定義として、メモリーのサイズの管理や拡張、最終的な破棄についてはtemplate実装しておく。

 

など数多くのケースで利用している。

また、c++で標準で持っているSTLのかなり有益であるので、これを機会にみなさんにもtemplateを見直すもしくは改めて勉強することをお奨めする。

 

自作ソフトi-port紹介ページ
http://www.geocities.jp/ys_and_otherjp/index.htm

なんとなくクラス設計について

さて、いまさらながらクラス設計について。。。

まぁ、オブジェクト指向でクラス設計をしている時必ずぶち当たる話、クラス設計だとかクラス分割もっと大きな意味で言うと機能分割の話。

実際のチーム開発でこれが完璧にこなせているシステムを見たことがある人、多分いないと思う。

クラス設計が終わった段階で完璧なものを作り上げるためにはウォーターフォールかなんかで上流がかっちりと決まっていると何とかなるかもしれない、、、というか上流がかっちり決まっていないとしっかりしたクラス設計なんでありえない。

しかし、ここって一番大きな矛盾が生じるところのような気がしています。
だって、いまどきウォーターフォールでしっかりと上流が決まるなんてありえないもん（笑）

運良く上流がしっかり決まったとしても、運用フェーズに入って仕様変更として受けた場合、運用による機能変更って言葉を変えると過去に決まった上流の否定だもん（自爆）

なので、仕様なんてまともに決まらないしひたすら変わっていくというスタンスでの開発思考がスパイラルとかRUPなんかあるけど、ここで大きな間違いをする人がいるんだな。

プロジェクト管理の話で言うと進捗割合が問題になるが、当然決めなくてはならない上流が決まっていない問題を上記の事を偏った意味で引用して、

１．仕様が変わっていく
２．仕様は恒久のものではない
３．仕様は決定事項ではない
４．仕様を決定しなくてもよい

などの拡大的な「風が吹けば桶屋が儲かる」理論を持ち出して上流を決めないで下流の出来る部分から手をつけること。

さて、このような開発の直接実装に携わったSEもしくはPGはよくご存知だと思いますが当初想定もしなかった仕様が出てくる、そのため変更点が想定外の部分にまで波及する、、、そりゃそうだ、上流と下流は考え方のベースがそもそも違うのが当然なのだから。

上流の考え方の基本-顧客（発注先）の要求ベースでシステムを構築する
下流の考え方の基本-既存等を含めてシステムや実装済み機能を有効利用することシステムを構築する

そのギャップにより追加工数の話をすると、「未定部分に対して柔軟に対応できるシステムではない」なんて否定的なことを言われてしまう。
これって、理不尽だよね、「そもそもこの部分はどう変わるか分かりません」を前提に組んだシステムなんて適合するか適合しないかなんて博打みたいなもの。
せめて、未定部分の外部仕様ぐらいはまともに決めていなければいけないけどそんなことしていない。
また、このギャップを埋めるのはSEの仕事だけどまともに機能していないよね。

では、ここで下流の作業に携わる人間として取るべき道は２つある。
１．とりあえず全体の整合性など考えず顧客の要求ベースで最小の修正で対応。
２．全体の整合性が取れないソフトは末永くメンテナンスする上で必ずメンテナンス工数が増大するので影響範囲・作業工数などを含め説明の上その方向で作業できるように調整する。

ここで、１を選ぶからまともなクラス設計をしているソフトなんて存在しない。


さて、上記を踏まえた上でクラス設計・機能設計について
１．クラス設計のタイミングはクラスに対して外部仕様の変更が発生した時に行うものである。
２．クラス設計を行うタイミングは当然仕様変更に基づくものなのでそれ相応の工数が発生する。

なのである。

今度、気が向いた時に、もうちょっと書くかな（笑）

i-port紹介ページ
http://www.geocities.jp/ys_and_otherjp/index.htm