質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.42%

  • Java

    14754questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • C

    4107questions

    C言語は、1972年にAT&Tベル研究所の、デニス・リッチーが主体となって作成したプログラミング言語です。 B言語の後継言語として開発されたことからC言語と命名。そのため、表記法などはB言語やALGOLに近いとされています。 Cの拡張版であるC++言語とともに、現在世界中でもっとも普及されているプログラミング言語です。

  • C++

    3923questions

    C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

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

解決済

回答 11

投稿

  • 評価
  • クリップ 3
  • VIEW 4,472
退会済みユーザー

退会済みユーザー

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

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

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 11

checkベストアンサー

+10

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

・・・・・・

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

・・・・・・

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

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

if ( ... ) {
    while ( ... ) {
        // メソッド
    }
}
else if ( ... ) {
    if ( ... ) {
        // メソッド
    }
else {
    // メソッド
}

・・・・・・

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

・・・・・・

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




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


(追記)

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/11/12 13:11

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

    キャンセル

  • 2015/11/12 13:25

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

    キャンセル

  • 2015/11/13 11:31

    morisakisanさんの例、メソッドの長さに言及していないので、メソッド分割した方が良い例としては宜しくないと思います。
    このケースでも、メソッド分割しない方が良いケースは少なくないです。

    分割した方が良い積極的な理由がなく、メソッドに分割しなくても例示の部分が1画面程度に収まるような場合です。
    例程度の複雑さであれば時々発生しますが、ほとんどの人はメソッド分割しないと思いますよ。(大抵は忙しいからですが。)
    そして、このようなケースでは、仮に神のように素晴らしいひと目で内容が読み取れるようなメソッド名をつけることができたとしても、分割しない方が良いです。

    名前をつけた人は既に内容を理解しているので、誰が見てもひと目で分かる素晴らしい名前と思うかもしれませんが、多くの場合はそんなことないです。どうしても誤解の入る余地が残ります。
    なので、ソースを読む人は、自分が開発者の意図を誤解していないことを確認するため、実行文も読む必要があります。
    折角ひと目で見れる部分だったのに、分割した結果ひと目で見れなくなり、可読性は確実に劣化します。

    このようなケースではメソッドに分割するのではなく、その分かりやすいメソッド名をコメントとしてつけると、たいへん読みやすいソースになると思います。
    誤解の余地があるにせよ、その場で内容を確認できるし、理解するための指標になりますから。

    キャンセル

  • 2015/11/13 11:53

    Chironianさん

    コメントありがとうございます。(名前間違えてませんか?)

    絶対に分割するべきだとは思っていません。
    分割しないという意見に対して、分割するとメリットになる場合もあるよ、と言っています。
    1画面程度に収まるような場合は分割しなくても良いと思います。
    実際書くときはコメントをちゃんと書きますが、例では処理の中身が無いのでコメントを省いてしまいました。

    言葉が足りていない点、特に、コメントが無い点は不適切だったかも知れません。
    ご指摘ありがとうございます。

    キャンセル

  • 2015/11/13 13:21 編集

    argiusさん、修正ありがとうございます。
    実際にこの例で1画面に収まるようなケースでメソッド分割する人がいて、ほんとに苦労したことがあるので拘ってしまいました。ごめんなさいね。

    Chironianは断絶への航海に出て来るケイロン人の意味なので、間違ってないですよ。
    https://en.wikipedia.org/wiki/Voyage_from_Yesteryear

    キャンセル

  • 2015/11/13 14:12

    Chironianさん

    いえ、私も読み手に好意的な判断を強制しているフシがあるので、伝わらないことがあっても自分の責任ですね。
    柔軟な対応ができない人がいて苦労するのはどこも同じですね。お察しします。
    基本的にはケースバイケースということで、あとは実施する人の判断かな、と思います。


    Chironianさんの名前の由来、私は寡聞にして知りませんでした。
    SF作品由来なんですね。
    私はホーガンの巨人シリーズ1,2くらいしか読んだことがありません。


    名前間違えていませんか?は、「宛名」間違えていませんか?というべきでしたね。
    「morisakisanさんの例」とあったので、最初どれのことかなーと迷いまして...
    また言葉足らずでしたね。すみません。

    ちなみに私のIDは特に意味はありません。(^-^;
    強いて言うならアナグラムのような何かです。

    キャンセル

  • 2015/11/13 15:19

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

    キャンセル

+5

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+5

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

それを踏まえて、自分がメソッドにしたほうがよいと思う基準は、
  • パラメータを変えるなどして繰り返し利用できるロジック
  • 長すぎる、またはネストが深すぎる部分
などです。
メンテナンス性・可読性を考慮したもので、morisakisanの判断基準とほぼ同じだと思います。

逆にメソッドにしないほうがよいと思う基準は
  • メソッドにせず直接記述したほうが処理内容がわかりやすいもの
  • 繰り返し利用しない数行程度のロジック
といったところです。

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

上記からは少し外れますが、
  • 再利用の予定はないが、メソッドとして提供されている類似機能がある場合
も機能単位の統一化という意味でメソッドにする場合があります。
郷に入れば・・・ではないですけれど、まわりのコードになじませるという意味合いが強いですね。

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/11/12 14:51

    賛成です!!

    キャンセル

+5

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+4

私は下記の条件に従って作っています
  • 名前がつけやすいもの
  • 作用が明確であるもの
  • 同じ値を投げ込めば常に同じ値が帰る事が想定されるもの

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+4

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

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

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

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+3

こんにちは。

私もmorisakisanさんの方針に賛成です。
小さくて、かつ、1度しか使わないメソッドが多用されているとソースを追いかけていて、ブチブチ思考が途切れるので非常に辛いです。ですので、そのようなメソッドはあまり作らない方針です。
モジュール分割は適度な粒度で行うのが適切と思いますよ。

昔、派遣の方がそのような細切れソースを作ってくれて、後でメンテにかなり苦労しました。
その方はかなり頭の良い方でした。だから細切れなソースでもメンテでき、本人は気にならなかったかも知れません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+3

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+3

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

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

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

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


c言語とかだとヘッダーファイルのコードが増える
javaで言うprivateなメソッドは要するに外部に公開しないということなので、
Cだとstatic関数になり、ヘッダーは特に変わらないと思います。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

無名関数(匿名関数)で定義するのが有効な場合もあると思います。
後から呼び出す箇所が増えた場合の対処も楽ですし、他の回答で出ているコードが追いにくくなることへの影響も少ないです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

一度しか使わないというのがどういう判断かわかりませんが、アプリに完全に依存していて、汎用的に使えないと断言できるのであれば、メソッドにせず、そのまま書けばいいとおもます。
ただ汎用的に使える要素があるのであればutilパッケージなど作ってクラスに分けて置いておいてください。
いつか役立つかも!

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

同じタグがついた質問を見る

  • Java

    14754questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • C

    4107questions

    C言語は、1972年にAT&Tベル研究所の、デニス・リッチーが主体となって作成したプログラミング言語です。 B言語の後継言語として開発されたことからC言語と命名。そのため、表記法などはB言語やALGOLに近いとされています。 Cの拡張版であるC++言語とともに、現在世界中でもっとも普及されているプログラミング言語です。

  • C++

    3923questions

    C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。