テーブルから別テーブルへの転記 ③ 配列と連想配列の組合せ ～その７．亜神誕生～

前回までテーブル間の転記について、色々とあれこれと、作っては直しを
繰り返してきた。
infoment.hatenablog.com
今日は、今まで作ってきたマクロのクラス化に関するお話。

今まで似たような機能のプロシージャを作り溜めるたび、クラスモジュールに
まとめてきた。今回もそのつもりだったのだが、ここで悩ましい問題が発生。

それは、作成したマクロが別のクラスモジュールのメソッドを使用している
ため、二つのクラスモジュールをペアで使用しなければならないということ。

ここで考えた選択肢が、以下の二つだ。

1. 二つのクラスモジュールを、必ずペアで使う。
機能別に二つのクラスモジュールに切り分けられているため、解り易い。
一方、ペアで使うことを知らなければ、クラスモジュールの「移植漏れ」が
発生する恐れがある。なにより、毎回二つインポートするのは面倒くさい。

2. 集合クラスに、今回作成したマクロを全て統合する。
インポートするクラスモジュールが一つしかないため、「移植漏れ」は起きない。
しかし「集合」と「テーブルの転記」は、機能的に全く関係がない。複数の異なる
機能を、一つのクラスモジュールに押し込めてよいものか。

設計の一部分（クラス）に、過剰に機能を集中させることを、「神オブジェクト」
「神クラス」と呼ぶそうな。
ja.wikipedia.org
今回の規模で神を名乗るなど烏滸がましく、気にすることなどないのかも。
しかし一般的に否定されるアンチパターンに手を染めるのは、それはそれで
躊躇われる。

さて、どうしたものか・・・。

かなり悩んだが、今回は選択肢２．を採択し、 ↓ こちらに統合することとした。
※統合済み。
infoment.hatenablog.com

繰返しになるが、この程度の規模で神のクラスを名乗るなど烏滸がましい。
良くて亜神（亜：上位や主たるものに次ぐ、という意味がある）どまりの
アマチュアクラスといったところか。

ということで次回から少しだけ、このクラスモジュールの使用例をご紹介。

参考まで。