FORTRANなどの手続き型言語は、手続きが固定しているか、非常に限定された範囲である場合には、効率的に動作する。特に計算速度の上では、有利であろう。たとえば、評価システムの対象とする製造物が限定されていてﾌﾟﾛｾｽフローも多くの種類か存在しない、という場合には、それでもよいかもしれない。しかし、今、ここで目指しているものは、可能な限り制約条件のついていない汎用性のあるシステムである。手続き型言語で、このようなシステムの構築を目指すと、プログラミング上も、もたソフトウェアの管理上においても破綻をきたしてしまう。以下に具体的な例を挙げて説明することにする。

概要のページで記述した環境負荷評価を行う手順を、もう少し具体化して書くと次のようになるであろう。

係数マトリックスの列はﾌﾟﾛｾｽに対応しており、行はマテリアル、投入エネルギーなどに対応している。x列ベクトルはﾌﾟﾛｾｽ量を、z列ベクトルは系全体の物質収支の総和を示す。z列ベクトルに境界条件を与えた上で、xベクトルについて連立一次方程式を解けば、プロセス量の解が得られ、これに各プロセスからの環境負荷の寄与を積算すれは系全体の環境負荷が算出される。一見、簡単そうに見えるこの手順も、汎用性ということを考えると、そうは簡単にはいかない。

まず、プロセスデータを個別にシステムに読み込ませながら、係数マトリックスを構築するが、マトリックス全体の大きさは、全てのプロセスデータを読み込んでからでないと、明らかにならない。列すうは、プロセスの数であるから比較的単純であるが、物質数は複数のプロセスデータにおける重複があり得るので複雑である。なお、CO₂などの環境負荷項目についても、複数のプロセスデータ内で重複があり得るので、同様の注意が必要である。手続き型言語では、１．全プロセスデータを一次的に作業領域に置く、２．項目の重複などを除外した上で、マトリックスの大きさを決定、３．各プロセスデータを係数マトリックスの行列の適切な位置に代入する、などの処理をすることになろう。マトリックスの大きさを、事前に配列宣言などて確保する構造になっている場合には、かなり大き目に領域をとっておかなければならない。また、この二次元配列の大きさが、システムの取り扱い限界を示し、それ自体一つの制約事項となる。

この点、オブジェクト指向では、クラス設計が適切に行われている場合、単独のプロセスデータの読み込み時に、動的にメモリ領域を拡張してゆくので、全データを読み込まなくても、個別に処理ができ、もはや領域のサイズや確保などということに注意を払わなくともよい。その結果、各プロセスのデータを管理するクラスProcessと、プロセスの系全体を隔離するクラスLCAを用いて、簡単にマトリックスの組み立てが実現できる。例えば、ファイル名がProc1.datである１つのプロセスデータを、系の中に組み込む動作は、以下の単純な操作で実現できる。

      LCA lca;
      Process pr;
      pr("Proc1.dat");
      lca.add(pr);

この操作をオブジェクトlcaに対して、プロセスの数だけ繰り返せば、オブジェクトlcaのメンバデータにマトリックスが形成される。このことは、このことは、手続き型言語に比べると、大幅な労力の軽減であり、プログラム上の誤りも少なくなり、オブジェクト指向の大きな利点であるといえる。

ただし、クラス設計は慎重に行わなければならず、それなりに時間もかかる。例えば、上記のマトリックス操作の汎用化を実現するために以下のような汎用クラスを開発した。

クラス	内容
Array	一次元配列を管理するクラス
Store	一次元配列とそれに随伴る整数を管理するクラス
Array2d	二次元配列を管理するクラス
Matrix	マトリックスの演算や代入などを管理するクラス
Vector	多次元ベクトルを管理するクラス

これらの汎用クラスは、オブジェクト指向のtemplateという機能を使って、任意のデータ型やクラス型のデータの処理に利用できる。