1度しか使わないメソッドは作る必要ありますか。

どちらでもいい、個人の好きずきで良い内容かも知れませんが参考に皆様の意見を聞きたいです。

javaで言えばアクセス修飾子privateで一度しか使わないメソッドですが、コードが長くなる際は、このようなメソッドを作ると可読性が良くなるとか、複数回使うときがあるかも知れないのであっても良いと伺った事がありますが、個人的にメソッドが沢山あるのがわかりにくく感じます。c言語とかだとヘッダーファイルのコードが増えるし面倒なのではないでしょうか。また、プログラムの最適化の観点でも余分なメソッドを作る影響はないのでしょうか。こういうメソッドの必要性について皆さんのご意見を頂けたらとおもいます。

行動規範の内容に同意します

回答11件

ベストアンサー

個人の趣向や感覚、熟練度などによって違ってくるので一概には言えませんが、単純に一部の処理を切り取ってメソッドにしてしまっているために、却って読みにくくなっているコードはありますね。

・・・・・・

何度も使うメソッド、標準関数や標準APIを使う場合に、それらの中身をいちいち確認したりしないですよね？
それと同じように、一度しか使わないメソッドも、適切に分割して作られたものなら読みやすくなるはずです。
分割する際は、メソッド名も重要になります。

・・・・・・

分岐が複雑になっている箇所は、具体的な処理の部分をメソッドに分けることで、見通しが良くなり、処理の流れが分かりやすくなるメリットがあります。

※追記：このif文全体が1画面に収まる30～50行程度であれば、そのままの方が見通しが良いので分割しない方が良いと思います。全部では無く、処理が長くてひとまとまりのところだけをメソッドに切り出して、1画面に収まればOKです。
（Chironianさんにご指摘いただきました。）

lang
1if ( ... ) {
2    while ( ... ) {
3        // メソッド
4    }
5}
6else if ( ... ) {
7    if ( ... ) {
8        // メソッド
9    }
10else {
11    // メソッド
12}

・・・・・・

Javaで言えば、privateにしないで、デフォルトアクセスにして、かつstaticにできるように分割することで、単体テストがしやすくなります。
言い換えると、単体テストがしやすいようにメソッドを切り出すことが重要です。
privateにしないことについては異論があるかと思いますが、私は単体テストの利便性を取ります。

・・・・・・

メソッド呼び出しによるパフォーマンスへの影響は、皆無ではありませんが、一度だけ呼ばれるものならほとんど無視して良いものだと思います。

まとめると、1度しか使わないメソッドは、必ずしも要るとは言えません。
下手に分割するくらいならしないほうが良いです。
適切に分割されていれば、読みやすくなると思います。

（追記）

書き忘れましたが、
この辺の話は、リファクタリングとも関係してきますね。

リファクタリングメソッド分割 - Google 検索

投稿2015/11/12 04:05

編集2015/11/13 03:16

argius

総合スコア9388

trick

2015/11/12 04:11

私は、argius さんに賛成ですね。適切に分割されていれば、読みやすいと思いますよ。後は、名前の付け方だと思いますね。パッと見で解る名前であればそんなに読み辛くないと思います。

argius

2015/11/12 04:25

trickさん賛同いただきありがとうございます。

Chironian

2015/11/13 02:31

morisakisanさんの例、メソッドの長さに言及していないので、メソッド分割した方が良い例としては宜しくないと思います。このケースでも、メソッド分割しない方が良いケースは少なくないです。分割した方が良い積極的な理由がなく、メソッドに分割しなくても例示の部分が１画面程度に収まるような場合です。例程度の複雑さであれば時々発生しますが、ほとんどの人はメソッド分割しないと思いますよ。(大抵は忙しいからですが。) そして、このようなケースでは、仮に神のように素晴らしいひと目で内容が読み取れるようなメソッド名をつけることができたとしても、分割しない方が良いです。名前をつけた人は既に内容を理解しているので、誰が見てもひと目で分かる素晴らしい名前と思うかもしれませんが、多くの場合はそんなことないです。どうしても誤解の入る余地が残ります。なので、ソースを読む人は、自分が開発者の意図を誤解していないことを確認するため、実行文も読む必要があります。折角ひと目で見れる部分だったのに、分割した結果ひと目で見れなくなり、可読性は確実に劣化します。このようなケースではメソッドに分割するのではなく、その分かりやすいメソッド名をコメントとしてつけると、たいへん読みやすいソースになると思います。誤解の余地があるにせよ、その場で内容を確認できるし、理解するための指標になりますから。

argius

2015/11/13 02:53

Chironianさんコメントありがとうございます。（名前間違えてませんか？）絶対に分割するべきだとは思っていません。分割しないという意見に対して、分割するとメリットになる場合もあるよ、と言っています。１画面程度に収まるような場合は分割しなくても良いと思います。実際書くときはコメントをちゃんと書きますが、例では処理の中身が無いのでコメントを省いてしまいました。言葉が足りていない点、特に、コメントが無い点は不適切だったかも知れません。ご指摘ありがとうございます。

Chironian

2015/11/13 04:25 編集

argiusさん、修正ありがとうございます。実際にこの例で１画面に収まるようなケースでメソッド分割する人がいて、ほんとに苦労したことがあるので拘ってしまいました。ごめんなさいね。 Chironianは断絶への航海に出て来るケイロン人の意味なので、間違ってないですよ。 https://en.wikipedia.org/wiki/Voyage_from_Yesteryear

argius

2015/11/13 05:12

Chironianさんいえ、私も読み手に好意的な判断を強制しているフシがあるので、伝わらないことがあっても自分の責任ですね。柔軟な対応ができない人がいて苦労するのはどこも同じですね。お察しします。基本的にはケースバイケースということで、あとは実施する人の判断かな、と思います。 Chironianさんの名前の由来、私は寡聞にして知りませんでした。 SF作品由来なんですね。私はホーガンの巨人シリーズ1，2くらいしか読んだことがありません。名前間違えていませんか？は、「宛名」間違えていませんか？というべきでしたね。「morisakisanさんの例」とあったので、最初どれのことかなーと迷いまして... また言葉足らずでしたね。すみません。ちなみに私のIDは特に意味はありません。(^-^; 強いて言うならアナグラムのような何かです。

Chironian

2015/11/13 06:19

argiusさん、こんにちは。あう、ごめんなさい。宛先間違えてました。

行動規範の内容に同意します

私は「一度しか使わない」などと言った現れる回数を判断基準にして、メソッドにするかしないかを決めることはしないようにしています。一度だろうが、複数回だろうが、メソッドにすべきと思ったものはするし、すべきでないと思ったものはしないです。一度しか使わないだろうと思っていると、あとで複数回使うことになったり、逆にここはどこかで再利用するはずと思ったら、結局一度だけだったというのはよくあることなので、そういった基準は始めからしないようにしています。

投稿2015/11/12 12:28

raccy

総合スコア21735

自分は「機能の一部をメソッドにする」ということは、ベースソースに「ブラックボックスを置く」ようなものだと思っています。
いくらわかりやすい名前であったとしても、実際にメソッドの中の処理を見るまでは何が行われているのかわかりません。

それを踏まえて、自分がメソッドにしたほうがよいと思う基準は、

パラメータを変えるなどして繰り返し利用できるロジック
長すぎる、またはネストが深すぎる部分

などです。
メンテナンス性・可読性を考慮したもので、morisakisanの判断基準とほぼ同じだと思います。

逆にメソッドにしないほうがよいと思う基準は

メソッドにせず直接記述したほうが処理内容がわかりやすいもの
繰り返し利用しない数行程度のロジック

といったところです。

例えば計算式のようなものはよほど繰り返し利用するものでない限り直接記述されていたほうがわかりやすいです。
ただし頻出する計算式で、後に修正される可能性がある場合などはメンテナンス性を考慮してメソッド化したほうがいい場合もあります。

上記からは少し外れますが、

再利用の予定はないが、メソッドとして提供されている類似機能がある場合

も機能単位の統一化という意味でメソッドにする場合があります。
郷に入れば・・・ではないですけれど、まわりのコードになじませるという意味合いが強いですね。

自分なりの判断基準を上げさせていただきましたが、最終的にはあとからそのソースコードを改修する人の立場に立ち、可読性とメンテナンス性からどちらが適切か判断すればいいと思います。

投稿2015/11/12 04:54

編集2015/11/12 04:56

jawa

総合スコア3013

Chironian

2015/11/12 05:51

賛成です！！

行動規範の内容に同意します

言語によって文化は違いますが、Rubyの場合はむしろ「1つ1つのメソッドの短さ」を重視する傾向にあります。何かしらの「意味のかたまり」があれば、1つのメソッドにくくりだす、ぐらいの勢いです。

投稿2015/11/12 04:15

maisumakun

総合スコア145183

コマンドラインでつかえるツールを作る場合を考えます。
パラメータに -v を指定したらバージョンを表示するという機能を持たすことが多いはずです。
バージョンを表示するロジックは、通常は箇所にだけ書くはずです。

みなさんは、その処理をどのようにかきますか？
パラメータ解析部分中にロジック添加して書く、
show_version() のようなメソッドを作ってそれを呼びだすように書く。

show_version() メソッドをつくることを選択することが多いのではないでしょうか？
そうする動機は何でしょう？

他の方の回答にもありますが、
メソッドとして独立させる動機は、呼び出し回数だけではありません。
処理粒度の単位でメソッドを分けるということも大きな動機になります。

個人的にメソッドが沢山あるのがわかりにくく感じます

これも数だけが問題なのではありません。
多機能なプログラムなら、メソッドの数は増えます。
メソッド分割の階層、分類に統一性があると理解がしやすくなるです。
弱にメソッド数がすくなかったとしても、理解しにくくなる例もあります。
驚嘆な例ですが、処理の粒度を無視して、行数が多くなった処理を単純に 10行毎に
メソッドに分けるとしたら、理解、テスト、保守がしにくくなるでしょう。

最適化の観点

メソッド呼び出しのオーバーヘッドは１度しか呼ばないなら全く問題にはならないはずです。
処理速度には、オブジェクト生成、ガベージコレクト、 Disk IO, ネットワーク処理といったことが大きな要因になることが多いです。

投稿2015/11/12 15:41

編集2016/01/29 13:56

katoy

総合スコア22324

私は下記の条件に従って作っています

名前がつけやすいもの
作用が明確であるもの
同じ値を投げ込めば常に同じ値が帰る事が想定されるもの

1度のみ使う使わないかは条件ではありません。
良い名前を付けて分類出来るならどんどん名付けて仕分けて行くべきだと思ってます。
このロジックの分割をどんどん体験することでプログラミングも上達していくと思いますしね。

逆に言えば良い名前が思いつかないなら関数やメソッドにするべきではないと思います。

投稿2015/11/12 13:14

miyabi-sun

総合スコア21158

何も考えずにただ分ければいいと言った感じで
あまり細かく分けるのも読みづらいと思います。

天下り的ですが、読みやすければ適切に抜き出せている
そうでなければ適切でない抜き出し方をしている事になると思います。
(適切なまとめ方なら名前もわかりやすいはず)

再利用云々はその時が来たら抜き出せばいい話です。

ただ、抽象度を揃えるために抜き出すことはあります。

c言語とかだとヘッダーファイルのコードが増える

javaで言うprivateなメソッドは要するに外部に公開しないということなので、
Cだとstatic関数になり、ヘッダーは特に変わらないと思います。

投稿2015/11/12 04:04

編集2015/11/12 04:35

ozwk

総合スコア13521

自分はJavaでEclipseを使った開発が主で、かつ複数人で開発するか
あるいは運用中であるものに関わっていますが、
「絶対に1回しか使わない」と確信が持てるなら分ける必要はないです。
1）複数のクラスで読む可能性がある（ユーティリティ系）処理はクラスごと分ける
2）単独のクラスでしか読まないが、何回も出現する→メソッドを分ける
大まかにこんな感じですかね。

Eclipseが適度にわかりやすくしてくれるので、細かく分けられても追えないわけではありません。
テキストエディタで見ろと言われたら発狂します。
無駄に分けられると隠されてしまうので好みではありませんが…。
ただ、コード規約でどうしても分割せざるを得ないなど、規約を守らないといけないのであれば分けざるを得ないでしょう。

投稿2015/11/12 03:46