タイトル | : Re^5: 長くなりすぎるプロシージャ名 |
記事No | : 7653 |
投稿日 | : 2008/06/02(Mon) 09:58 |
投稿者 | : よねKEN |
> 「1つの機能」の概念が理解できないのですが?
機能という言葉は役割や仕事と言い換えてもいいです。 1つのメソッドは1つの機能だけを実現する。 1つのメソッドは1つの役割だけを実現する。 1つのメソッドは1つの仕事だけを実現する。 :
先ほど例に出したIsNumberメソッドは数値かどうか判定するメソッドで、 「数値かどうか判定する」だけの1つの機能しか持ちません。 このメソッドに判断対象データが何進数として検査するか? ということを指定できる引数を追加しても、あくまでこのメソッドは 「数値かどうか判定する」という1つの機能だと言えるでしょう。
' stringValue->検査対象、base→基数を指定 16を指定すると16進数としてチェック ' 例えば、16進数の場合、FFは数値である。 Public Function IsNumber(ByVal stringValue As String, ByVal base As Integer) As Boolean
しかし、下記のようなメソッドはどうでしょうか?
' stringValue->検査対象、number->検査対象で整数として読み取れる部分までを変換した整数を返す ' 例えば、"123XX"という文字列を渡した場合、numberは123、戻り値はFalse Public Function IsNumber(ByVal stringValue As String, ByRef number As Integer) As Boolean
このメソッドに違和感を感じませんか? stringValueを検査するという機能と、stringValueから整数と読み取れる箇所を抜き出す機能という2つの機能を持っています。 この機能面に基づいてメソッド名を変えるとIsNumberAndCutNumberのような 妙な名前のメソッドになるかもしれません。
こういうような意味での「1つの機能」です。
> Public Sub 処理11(選択 as Integer) > Select Case 選択 > Case1: 処理111 > Case2: 処理112 > : > CaseN: 処理11N > End Select > End Sub > この場合は1つの機能とは言えないのでしょうか?
というわけで具体的な処理を説明いただかないと私には判断できません。
> 実際にはこのような処理ばかりです。
必然的にこのようにしか実装できないロジックもないとは言えないので、 実例で話をしないと指摘は難しいです。
例えば、一般的な業務アプリではfor文による多重ループはせいぜい3重程度までで それ以上のループになるとしたら、ほぼ間違いなく整理されていないロジックです。 しかし、数学の問題などを解くロジックだと8重ループとか平気で出てきたりして、 それでいて、そういう処理を書くのが素直な場合もあります。 長い記述になるコードでも、それが十分素直な記述であれば、 それでよいという判断をする場合もあります。
> > また、例えば、この中で処理111は処理1の中の処理11から呼び出されるわけですが、 > > 処理111は処理1や処理11に依存した内容でしょうか? > > 依存しない内容であれば、処理1_処理11_処理111という名前にする必要はなく、 > > 単に処理111でよいはずです。 > > 上記のように選択肢で分岐してますので、依存した内容です。
依存しているというのはわかりましたが、上記のイメージだけを見ると 処理11メソッドは必要なくて、処理1にSelect Caseをそのまま書くという選択肢も 考えられます。(あくまで上記のコードイメージを見ての判断ですが)
> このような場合に、他のメソッドに依存しないように作るにはどのように > すればいいのでしょうか?
#本質的に依存するものであれば切り出せない場合もあります よくある蜜に結合されているメソッド群は、メソッドの引数を通じてデータを やりとりせず、モジュールレベルの変数にデータを持たせて、 そのモジュールレベルの変数を介して連携しているものがあります。 こういう場合では、モジュールレベルの変数を介して処理をするのを やめてメソッドの引数、及び、戻り値を使うようにすれば、そのメソッドの 独立性が高まります。
> 自己レスで入れたように、クラス単位で分割を試みていますが、 > 手続き的な処理の本質は変えられないのですが、こういうのはまずいのでしょうか?
クラス単位に分けることを先ほどは提案しましたが、今回話題にしているメソッド群が 一連の手続きなのであれば、それらはすべて1つのクラスの中のメソッドにしか ならないかもしれませんので、無理にクラスに分けるのはお勧めできません。
|