オブジェクト指向のプログラミングのはなし

オブジェクト指向とは
　現在のオブジェクト指向言語とはまた違っているかも知れませんが、今から２０年前ぐらいに輸出用衛星受信機のソフトの話です。当時は組み込みCPUの NEC 78K シリーズを使って、受信機の様々なパラメーターを設定するのに、テレビの画面に表示する「オンスクリーン・ディスプレイ」メニューが主流でした。
　リモコンでカーソルをアップダウンさせたり、左右のカーソルボタンで項目を選択して、+/-ボタンで値を修正っていうインターフェイスでした。当時はアッセンブラーからC言語に移行したころで、なんとかソースを見やすく機能的に構成したいが、メニューについては輸出用であることから、英語・フランス語・イタリア語・ドイツ語･スペイン語で切り替わることが当たり前で、メニューの表示文字の長さも変わるし、数値の単位も変わってくることがしばしばです。おまけに仕向け別にちょっとずつ機能が違うので、メニューにない項目があったりで、このメニューのプログラミングには大変苦労していました。
ハード的には
　当時はまだフラッシュP-ROMなど一般的で無く、ソフトはガラス窓がついた EPROMというメモリーにプログラムして、ソケットに刺すことが普通でした。それで、ちょっとでもバグがあれば、現地に行ってROM交換したり、生産中に変更があると書き換え･交換が必要なバグが出ないようにと、プログラマーは大変なプレッシャーになっていました。
ソフト的には
　当時、メニューは表示項目がCストリングの配列になっていて、言語によって最初のテーブルアドレスを切り替えて呼び出していました。表示の長さによって1画面に入りきれないと、次のページに移るのですが、表示すべきラインが一番下にあるのかどうかで次のページを表示するか判断し、戻って来るときは現在のライン位置が一番上に無ければページは移動しなくて良い。などプログラミングが大変複雑になっていました。数値編集ルーチンも、整数5桁のものから、単なる ON/OFF 、小数点以下2桁表示があるなど、表示･変更するルーチンも変数だけ変えれば同じように使えるものがあったりして、ROM容量節約のためにもできるだけ共用したいのも実情でした。
　そこで、考え出したのは、メニューを構造体の配列にしたことです。そのなかで、メニューの1ラインの内容を、
１．表示文字列
２．ページ番号
３．操作対象の変数アドレス
４．操作ルーチンのアドレス
５．表示単位
６．表示長さ
などを定義して、現在のページと表示すべきラインのページが異なっていたらページを再表示すること。そのラインで編集すべき変数と、設定ルーチンをメニューの構造体に持っておくことで、メニューを書き換えることによるトラブルとか、変数内容の修正に対応できる構造にしました。
　この考え方は、「オブジェクトが自分の名前、値、変更方法を自分で持って管理する」という現在のオブジェクト指向に近いもので、いくつかのトラブルの経験からたどり着いたとはいえ、正しい方向ではなかったかと思うのです。
　その後、デジタル衛星放送の時代になると、CPUは モトローラのCold-Fireになったり、Flash-Promにプログラムできるようになったりしましたが、やっぱりユーザーインターフェイスの部分が大変なのは今も昔も変わらないってことでしょうか？