「ランタイムライブラリ」と「スタティックライブラリ」の違いは以下です。基本的には、特に理由がなければ「ランタイムライブラリ」で開発した方が良さそうでしょう。
ランタイムライブラリ
実行時にリンクされるライブラリです。Windowsで言えばDLL(Dynamic Link Library)と呼んだりします。LinuxではELF形式という「*.so(Shared Object)」の拡張子がついたファイルです。(「*.so.6」とバージョン番号が付く場合もあります。)
メリット
- 外出しされていることでプログラム本体のサイズが小さくなります。
- ランタイムライブラリにバグがあった場合は、本体はいじらずランタイムライブラリを置き換えるだけで済む。
デメリット
- ファイルの数が増えるので管理が大変になる。
スタティックライブラリ
コンパイル時にリンクされるライブラリです。
メリット
- プログラム一本で完結しているので単品でコピーしても動作する。
デメリット
- プログラム本体のサイズが大きくなります。
- 部品に変更があった場合は、コンパイルし直す必要がある。(アップデートが手間)
ライブラリの時代変革
構造化プログラミング時代(C言語の時代)
「関数ライブラリ」で共通化されたサブルーチンを呼ぶだけしかできなかった。
オブジェクト指向の時代
オブジェクト指向時代のライブラリは以下のようなことが可能になり再利用の幅が広がりました。
クラスを利用する(インスタンス化して使う。)
クラスの変数定義と、メソッドをまとめて再利用する。
ライブラリのクラスを拡張して使う。(継承)
ライブラリで提供されるクラスに対して、メソッドや変数を追加して新しいクラスとして使う。
呼び出される側のロジックをアプリケーション固有処理で置き換える。(ポリモーフィズム)
Webアプリケーションフレームワークとかがこれに該当するでしょう。フレームワーク側であらかじめ制御の流れの枠組みが決まっており、それに沿って呼び出される側のクラス内容をユーザーがいじっていくような形式です。
コンポーネントの時代変革
そもそもコンポーネントの一般的な定義
- OOPのクラスより粒度が大きい
- ソースコード形式ではなく、バイナリ形式で配布される。
- コンポーネントの定義情報を含めて提供される。
- 機能の独立性が高く詳細を知らなくても利用できる。
歴史
1990年代
マイクロソフト社が開発したVBのコントロール部品、コンポーネントという単語を業界に浸透させた。
2000年代
JavaもEJBコンポーネントを発表した。実行性能のオーバーヘッドが大きかったことや、データ構造に依存する業務アプリでは汎用部品の作成が難しかったのであまり流行らなかった。
2010年代
Unityのコンポーネント。プロパティの設定変更や継承を行い簡単にゲームを作れる。
この記事へのコメントはありません。