20240505エクセルVBAクラス備忘録（クラスの統合・整理（孫クラス的なのを追加）)仮・問題点メモ
＜前書き＞
エクセルVBAオブジェクト指向、初心者です。
VBA自体は、以前から使用していました。
オブジェクト指向というものがあることは、知っていましたが、ネットなどを見てもよく分からず、挫折した過去あり。
＜以上前書き＞
（素人なので間違っているかもしれません。汗。）
今回は、コードは書いていません。
ここ最近、クラス、オブジェクト指向をやってきて、思ったこととしたことの？備忘録（未確認・未確定メモ）です。
（素人なので間違っているかも。汗）
＜最近やっていること＞
昔、作成した「手続き型のVBAコード」をクラスを意識して少しずつ直しています。（リファクタリング）
それがある程度できたら、別の機能を新たに実装しようかと思っています。
その備忘録です。自分用なので読まなくてもいいです。日記です。汗
【クラスのまとめ方は難しい（仮）】
今回、クラス「氏名_make、用務地_make、用務内容_make」などクラスを作った。
「氏名_make」などの命名は、日本語と英語で「何をどうするか」を表したもの。
（自分のオリジナルでこれでいけるのか、考え中）
（インスタンス化する時に、この名前でなく、別のインスタンス名を付ければいいか。
例：dim v氏名リスト as 氏名_make。・・・ややこしいか・・・？）
で、上記の各クラスだが、内容は、シートの表を読み込むメソッドだけ。（今現在）
中身は「リスト配列」というメソッド(読み込み列の関係で少し引数の数が違うなどだが類似)なので、
１個のクラスにまとめること可能。クラス「配列_make」とかで、まとめられるなと思う。
やるとしたら、
////////////////////////////////
＜元の例＞
dim v氏名 as 氏名_make
set v氏名 = new 氏名_make
v氏名.リスト配列 "sheet_simei",1,2,8
dim v用務地 as 用務地_make
set v用務地 = new 用務地_make
v用務地.リスト配列 "sheet_youmuti",2,3,4,5,10,12
みたいな感じで書いていたのをクラス「配列_make」とかで、まとめて・・・
///////////////////////////////
＜仮の例＞
dim v氏名 as 配列_make
set v氏名 = new 配列_make
v氏名.配列_make1 "sheet_simei",1,2,8
dim v用務地 as 配列_make
set v用務地 = new 配列_make
v用務地.配列_make2 "sheet_youmuti",2,3,4,5,10,12
だと、どうだろう。
（クラス「氏名_make、用務地_make、用務内容_make」は不要になる。）
配列のまとめ方としては分かりやすくなるが、
この先、クラス「氏名_make、用務地_make、用務内容_make」で、独自のメソッドなどが出てくるかもしれない。
そう考えると、クラス「氏名_make、用務地_make、用務内容_make」はそれぞれ残し、
その中で、さらに子（孫）クラスとして、クラス「配列_make」を呼ぶ方がいい気がする。
●親モジュール
●子クラス「氏名_make」
●孫クラス「配列_make」
（この場合、子クラス「氏名_make」は、孫クラス「配列_make」を呼ぶだけ）
この、問題点を考える・・・。
親子孫クラスまで階層ができると、またややこしいし、クラス同士の関係がややこしくなる・・・。
（孫クラスとして呼び出す場合以外、他の階層で呼び出す場合もありうる。）
というか、この関係構築・把握に慣れていく（しかない）のがオブジェクト指向なのか？？？
（目的（何を）手段（どうするか）の分け方・くくり方をしっかりしておく必要があるか）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
で、ここまでの仮結論（方針）
この先やることが多いので、（自分にとっては）ここはひとまずこのままで、このリファクタリング（？）は、
内容を見極め、もう少し先でやるようにしようかと思う。
オブジェクト指向は、作っては壊しの作業ばかりなのかな・・・。汗。
というか、それぞれの必要な要件の詳細を先に決めておけばできるのだろうけど。素人なのでできない（見通せない）。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
で、終わろうかと思ったが、仮で、上の改修をやってみた。
それなりに出来たが、このまとめた孫クラス「配列_make」は今回は実装しないことに。
（子クラス時点で、できていればそれでいいかと。）
特に、現時点では問題ないが、以下に気になった点を羅列しておきます。
＜改修方法＞
●親モジュール
→→→①子クラスへのメソッドのコードを改修（必要なら）
●子クラス「氏名_make」
→→→①親クラスからの呼び出しメソッドを改修（必要なら）
→→→②子クラスのメソッドを孫クラスへ卸す（孫クラスで要改修）
→→→③孫クラス呼び出し用のコードを新設
（親コードに書いていたのを卸して改修
→→→④ここでも孫クラスインスタンス化（戻り値必要）
●孫クラス「配列_make」
→→→①子クラスから卸したのコードを改修（ただ動くだけならあまり直さないでいいかも）
（↑寄せ集めでなくきちんとしたいなら、private変数など直す）
＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋
・上記のように、引っ越すには、当該「配列_make」だけでなく上位のコード、下位のコードも直す必要あり。
（というか、下にコードを卸す感じ。）
・階層を変えるため、クラス名も分かりやすく命名し直しか・・・も。
（また、子クラスへ引き渡しが多くなると、インスタンス化した変数がきちんと消えていくのか気になる。）
（ローカルウィンドウだと（なんとなく）、消えているようだ。不要になればきちんと消せばいいのだけれど。）
・中間の子クラスでは、孫クラスのインスタンス化が必要。
（また、中間の子クラス同志では、リスト配列_makeのような、「氏名_make、用務地_make、用務内容_make」でかなり似た孫クラスインスタンス化のコードを書く）
・孫クラスも、各メソッドの変数が寄せ集めただけではバラバラで整理し直した方がいい。
結局、コード作成途中で、「配列を作る」という①機能ごとで、「下請けクラス」（孫クラス：クラス「配列リスト」）を作ればいいと思ったが、
上の「氏名_make、用務地_make、用務内容_make」では、②目的ごとにクラスを分けることをしている。
今回のクラス「配列リスト」には、１次元配列や、２次元配列、シートを読み込む際、必要な列の指定や、前列を読み込むcurrentregionを使った各種メソッドができたが、
これを洗練、整理して、実装した方がいいのだろう。（コードも減るし。）しかし、中には、面倒なpublic変数が１個含まれたりしている。
（昔、どうしても解決できなかったpublic変数・・・。）
文書作成でいう「推敲」が必要だろうか。
ただ、今後の見通しがまだまだ立たないため、「氏名_make、用務地_make、用務内容_make」個々のクラス内単独に処理していた方が、
「考えるスコープ」が少なくて済むかも・・・。
どうしようか。慣れれば、改修した方の方がいいか。
その他：
命名について
クラスを追加したりすると、目的や機能が少し変わり、命名など直す必要に迫られる・・・。「日本語名詞＋英語動詞」でいいかなと思ったが、
下位にメソッドを持つクラスを追加すると、例えば、英語動詞部分(_make)が、ジャマで分かりにくくなる。
クラスのまとめ方について
「クラスの中では、どんな方法で、処理されていても、問題ない」という考えを、拡大解釈して、クラスの中は、「書き散らかし放題」ではいけないのだろう。
それでは、「手続き型で、スパゲッティ状態」になっているのと同じか。
クラス同志も一見して、分かりやすいように、配置できないかな・・・プロジェクトブラウザ様。
追記：クラス「配列リスト」について
中身は、ぐちゃぐちゃでも、「使おうかな」とも思っています。
全体を作ってから、個別部分は直してもいいかなという気もあります。悩む。
（せめて命名だけは、分かりやすくできないかな。）
