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

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

ただいまの
回答率

89.97%

try catchの用途【PHP】

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 4
  • VIEW 2,934

nanndemoiikara

score 705

try catchの用途が適切であるかわかりません。
PHPでアプリケーション開発を行う際、try catchをほぼ使います。
try catchがどのような動きをするかはわかっています。

下記はCodeIgniterのコントローラなのですが、バリデーションエラー等を全てthrowしてcatch内でエラー用の画面を表示させたりリダイレクトで飛ばしたりするような設計で開発してしまいます。
オープンソースのコード等を読んでいると、この様にtry catchを使っているコードをあまり見た事がありません。

エラー時の処理が楽だし見やすいと思っているのでこの様な書き方をしているのですが
何か問題点があるのでしょうか?
また、参考記事のC++だとパフォーマンスが悪くなるみたいな
他言語の情報でもご教授頂けますと幸いでございます。


参考記事:http://www.thinkridge.com/modules/tinyd1/content/index.php?id=7

<?php
defined('BASEPATH') OR exit('のび太さんのエッチ!');
class Api extends CI_Controller{
    function __construct()
    {
        parent::__construct();
        $this->load->model('api_model');
        $this->load->library('form_validation');
    }
    
    public function add_user()
    {
          //POST Request以外は無視
          if ( $this->input->method(TRUE) !== 'POST' ) return show_404();
          $json_str   = $this->input->raw_input_stream;
          //ここform_validationしやすい様に配列で渡す。
          $json_data = json_decode($json_str, TRUE);
          if ( empty($json_data) ) return show_404();

          $this->form_validation->set_data($json_data);
          $this->form_validation->set_rules('name', 'lang:name', 'required|max_length[100]');
          $this->form_validation->set_rules('tel', 'lang:tel', 'required|is_natural|max_length[13]');
          $this->form_validation->set_rules('sex', 'lang:sex', 'required|in_list[1,2]');

          $result = new stdClass;
          try
          {
               if ( $this->form_validation->run() === FALSE )
               {
                    throw new Exception('Request Validation Error', 2);
               }

               if ( ! $this->api_model->add_user($json_data) )
               {
                    throw new Exception('User add Error', 1);
               }

               $result->statusCode = 'success!!!';
               $result->message    = 'ユーザー登録できたっぽいよ!';
          }
          catch ( Exception $e )
          {
              $result->statusCode = 'EA' . $e->getCode();
              $result->message    = $e->getMessage();

              if ( ! empty(validation_errors()) )
              {
                  $result->validationMessages = $this->form_validation->error_array();
              }
          }
          return $this->output
              ->set_content_type('application/json')
              ->set_output(json_encode($result));
    }
}


大げさですがifで分岐するパターンです。
<?php
defined('BASEPATH') OR exit('のび太さんのエッチ!');
class Api extends CI_Controller{
    function __construct()
    {
        parent::__construct();
        $this->load->model('api_model');
        $this->load->library('form_validation');
    }
    
    public function add_user()
    {
          //POST Request以外は無視
          if ( $this->input->method(TRUE) !== 'POST' ) return show_404();
          $json_str   = $this->input->raw_input_stream;
          //ここform_validationしやすい様に配列で渡す。
          $json_data = json_decode($json_str, TRUE);
          if ( empty($json_data) ) return show_404();

          $this->form_validation->set_data($json_data);
          $this->form_validation->set_rules('name', 'lang:name', 'required|max_length[100]');
          $this->form_validation->set_rules('tel', 'lang:tel', 'required|is_natural|max_length[13]');
          $this->form_validation->set_rules('sex', 'lang:sex', 'required|in_list[1,2]');

          $result = new stdClass;
          if ( $this->form_validation->run() === FALSE )
          {
               $result->message = 'Request Validation Error';
               $result->statusCode = 'EA2';
               $result->validationMessages = $this->form_validation->error_array();
               return $this->output
                  ->set_content_type('application/json')
                  ->set_output(json_encode($result));
          }
          
          if ( ! $this->api_model->add_user($json_data) )
          {
               $result->message = 'User add Error';
               $result->statusCode = 'EA1';
               return $this->output
                  ->set_content_type('application/json')
                  ->set_output(json_encode($result));
          }

          $result->statusCode = 'success!!!';
          $result->message    = 'ユーザー登録できたっぽいよ!';
          return $this->output
                  ->set_content_type('application/json')
                  ->set_output(json_encode($result));
    }
}


。。。。微妙。。。。
<?php
defined('BASEPATH') OR exit('のび太さんのエッチ!');
class Api extends CI_Controller{
    function __construct()
    {
        parent::__construct();
        $this->load->model('api_model');
        $this->load->library('form_validation');
    }
    
    public function add_user()
    {
          $json_data = $this->validation_set_value();
          
          $result = $this->error_check($json_data)
          if ( ! empty($result) )
          {
               $result = new stdClass;
               $result->statusCode = 'success!!!';
               $result->message    = 'ユーザー登録できたっぽいよ!';
          }
          return $this->show_output($result);
    }

   private function show_output(array $result)
   {
        return $this->output
              ->set_content_type('application/json')
              ->set_output(json_encode($result));
   }

   private function error_check($json_data)
   {
       if ( $this->fvalidation_check($json_data) === FALSE )
       {
            $result = $result = $this->err('Request Validation Error', 1);
        }
        elseif ( ! $this->api_model->add_user($json_data) )
        {
            $result = $this->err('User add Error', 1);
        }
       $result;
   }

   private function err($msg, $code)
   {
       $result = new stdClass;
       $result->statusCode = 'EA' . $e->getCode();
       $result->message    = $e->getMessage();

       if ( ! empty(validation_errors()) )
       {
          $result->validationMessages = $this->form_validation->error_array();
       }
       return $result;
   }

   private function validation_check()
   {
          $this->form_validation->set_data($json_data);
          $this->form_validation->set_rules('name', 'lang:name', 'required|max_length[100]');
          $this->form_validation->set_rules('tel', 'lang:tel', 'required|is_natural|max_length[13]');
          $this->form_validation->set_rules('sex', 'lang:sex', 'required|in_list[1,2]');
          return $this->form_validation->run();
   }

   private function validation_set_value()
   {
          //POST Request以外は無視
          if ( $this->input->method(TRUE) !== 'POST' ) return show_404();
          $json_str   = $this->input->raw_input_stream;
          //ここform_validationしやすい様に配列で渡す。
          $json_data = json_decode($json_str, TRUE);

          if ( empty($json_data) ) return show_404();
          return $json_data;
   }
}
  • 気になる質問をクリップする

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

回答 3

checkベストアンサー

+4

参考にされている記事はかなり古いので、そのまま鵜呑みにしない方が良いと思います。

計測に使っている、Visual C++6 は、例外処理機構が良くなかったので、とても遅かったのは確かです。現在でも条件分岐よりは遅いですが、気にする程かどうかは、微妙です。
試しにgcc 4.9.2でそこのプログラムを実行すると、例外処理は 1.54s、条件分岐は0.11s になりました。

これがソースコードの可読性を犠牲にしてまで求めるパフォーマンスかどうかは、その時次第だと思います。

例外処理で気をつけなければならないのは、catch漏れだと思います。
Javaなどでは、コンパイラがある程度教えてくれますが、IDEが貧弱な言語だと、プログラマーの裁量に寄るところが大きいです。
私はPHPのIDEには詳しくないですが、catch漏れを防ぐ仕組みがなければ、よく起こりうるエラーに例外は使わない方が良いのではないでしょうか。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2015/09/03 10:27

    ご回答ありがとうございます。

    > 試しにgcc 4.9.2でそこのプログラムを実行すると、例外処理は 1.54s、条件分岐は0.11s になりました。

    ありがとうございます。勉強になります。

    > これがソースコードの可読性を犠牲にしてまで求めるパフォーマンスかどうかは、その時次第だと思います。

    そうですよね。。。。


    > 私はPHPのIDEには詳しくないですが、catch漏れを防ぐ仕組みがなければ、よく起こりうるエラーに例外は使わない方が良いのではないでしょうか。

    私自身特にIDEの指定が無い限りはIDEは使わずvimを使用していますが、catch漏れで困った事は無いんですよね。。。
    IDEによってですと、開発環境を統一していないかつ複数人で開発するアプリケーションの場合はあまりこういった記述はしない方が良いでしょうか?

    キャンセル

  • 2015/09/03 11:06

    catch漏れで困るのは、常駐型PGMの場合がほとんどなので、phpがCGIなどで使われているならば、むしろ例外を外にthrowした方がわかりやすいかもしれませんね。
    これは私がPHPだということを考慮しなかった回答でしたね。申し訳ないです。

    C++作った物だと、標準エラー出力に例外情報を表示して、いきなり落ちるので、障害発生時の調査が非常に難航したりしてしまいます。

    キャンセル

  • 2015/09/03 12:37

    > catch漏れで困るのは、常駐型PGMの場合がほとんどなので、phpがCGIなどで使われているならば、むしろ例外を外にthrowした方がわかりやすいかもしれませんね。
    > これは私がPHPだということを考慮しなかった回答でしたね。申し訳ないです。

    > C++作った物だと、標準エラー出力に例外情報を表示して、いきなり落ちるので、障害発生時の調査が非常に難航したりしてしまいます。

    いえ、ご回答頂きありがとうございます。
    C++ではそうなるんですね。勉強になります。
    レビューして頂けるのがC++出身の方だと
    「なんだこのクソコードは!!」と思ってしまう可能性がありえるという事ですね
    ((((;゚Д゚))))

    キャンセル

  • 2015/09/11 09:31

    一番 + が多いかったのでこちらをベストアンサーとさせて頂きます。
    ご回答頂きありがとうございました。

    キャンセル

0

例外はまさに「例外」なので、

  • プログラムミスやバグ(そもそも関数の引数が想定した形式でない、想定外のヌルポインタなど)
  • DBやファイル、ネットワークといった外部リソースの状態が想定外になっている
  • メモリ不足などの、処理系内部の異常
  • そもそも例外を投げるように作ってあるライブラリ

といった、まさに「異常事態」に対応するためのものです。フォームバリデーションの失敗は「異常」かといえばそうでもなく起きうるものですので(どちらかと言えばビジネスロジックに含まれうる)、例外で対応するのには少し違和感があります(もちろん、人間が値を入れるのを前提としない、Web APIであればまた違うとは思いますが)。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2015/09/03 11:42

    ご回答頂きありがとうございます。

    > まさに「異常事態」に対応するためのものです。
    > フォームバリデーションの失敗は「異常」かといえばそうでもなく起きうるものですので(どちらかと言えばビジネスロジックに含まれうる)、例外で対応するのには少し違和感があります

    そうですよね。。。その通りだと思います。
    一応、「入力が通る前提」としての「例外」という解釈で
    自分を納得させようとしているのですが
    自分自身、質問のtry catchでご回答頂きました通りの違和感があります。

    しかし、都度 ifで分けて redirectだったり表示させたりというものだと

    ・可読性がtry catchより悪い気がする
    ・効率的でない
    ・分岐させてFat Controllerになるぐらいならtry catchで書いてしまおう

    という思考に至ってtry catchしてしまうのです。。。
    (ちょっと大げさな記述になってしまいましたが分岐するパターンのコードを記載しました。)


    >(もちろん、人間が値を入れるのを前提としない、Web APIであればまた違うとは思いますが)。
    例題がAPIで申し訳ございません。
    通常の人間が入力するフォームでも上記の様にエラー処理も考えております。

    キャンセル

0

頻繁に起きることが予測されるような部分で例外をスローしないというのが、プログラミングの作法としてあるので使用しないほうが賢明です。パフォーマンスがどうしても良くないというのは、どの言語でも最新版のでも変わらないと思います。

パフォーマンスのことだけでなく、可読性にも問題があります。

関数の呼び出しでいくつもの階層を深めていった部分でまれに出る例外を処理したい場合に便利なのが、try,throwです。その場で、if文で分岐して数行で処理できるようなことをcatch にまとめる意味は薄いです。

ここの場合では、catchの中身を、次ようなメソッドに移します。

private function err($result, $message, $code) {}

この関数を呼び出して処理させます。

$this->err($result, 'Request Validation Error', 2);

このようにprivate functionで処理をさせるのが通常の感じだと思います。
tryのインデントも不要になり、catchの中身が分離するので、プログラムの可読性がアップするでしょう。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2015/09/03 18:14 編集

    ご返信頂きありがとうございます。

    > 規約以前の問題ですね。例外というのは、 「例」の「外」にあるから例外なのです。
    >基本的に想定外の事象を処理することを目指します。

    言葉遊びでしたら一応、「入力が通る前提」としての「例外」という解釈もできるかと思うのですが。。。


    > 何割という感覚であらかじめ予想される事象ならきちんと処理を書くことです。道具の目的をはき違えている気がします。

    > http://book.cakephp.org/2.0/ja/development/exceptions.html
    > にあるエラーはむしろthrowを使うケースパターンとして参考になります。これらは予期しないエラーに対しての定義です。

    そうなんですか?
    public function view($id) {
    $post = $this->Post->findById($id);
    if (!$post) {
    throw new NotFoundException('この Post は見つかりませんでした');
    }
    $this->set('post', $post);
    }
    このコードのidが削除されたユーザーのIDである可能性は「例外」ということでしょうか?
    それでしたら入力エラーも例外ではないでしょうか。。。?



    > ちなみに、メソッドの行数を制限する規約が存在します。だらっと一つのメソッドにプログラムを書くことは行儀が悪いとされています。
    > メソッドの行数が多すぎると警告を出すIDEもあります。まず、private functionに分割するというのを基本的習慣にしましょう。

    メール送信部分のロジックをprivate _send_mailというメソッドを作って分けたりすのは見やすくなると思うのですが「private err」は無いと思います。。。
    1コントローラでCRUDを書く事もあるのですがC U D のprivate errをそれぞれ定義するとメソッド量が多くなり可読性が落ちてしまう気がするのですが。。。



    > public function add_user()
    > はコメント含めて30行以上ありますが、functionに分けて10行以下にまとめてみると、また一段上のスッキリたコードができますよ。やってみてください。

    libraryでしたらもっともだと思うのですがControllerですよ?

    追記しました
    メソッド名は適当につけたので気にしないでいただきたいのですが10行以下にまとめて書いて見ましたがひどいコントローラになった様に思います。
    publicメソッドが複数定義されているときはあり得ない記述だと思います。

    キャンセル

  • 2015/09/03 22:18

    メソッドに分割したコードを読みました。「微妙」とご自身の判断ですが、方向性としてめちゃくちゃいいじゃないですか!当初はerr()だけの分離と思っていたのですが、その他の機能も分離してみたようで、真面目さがにじみ出ています。ものすごくプロっぽいかっこいい形になってきていると思いますよ!(外注で指示したコードも、いつもこんな風に帰ってくればいいのに・・・プロのくせに!)
    このように、関数で細かくすると複数のコントローラーで使いまわされているプログラムの分離も行いやすくなり、単体テストに乗せたりすることもしやすくなっていきます。
    例えば、
    function show_output()
    ですがjsonでアウトプットするという機能として他のコントローラーでも有用になる可能性も見えてきます。別に量産されたメソッドは、ここだけのものでなくても良いんです。どこかにまとめて置くことも視野に入ってきます。メソッドが多くなればさらにそれらをクラスに分離することもできます。そこまで行うことができたら、「実は、この機能にはもっと設定しなけらばならないこともあった」となった時に、変更が一か所で済みます。色々とやれることが見えてきます。
    提示されたコードはいくつかバグがあるようですが、この調子でprivateのプロパティ利用やメッセージ文の定数化なども行ってみてください。そして、すべての関数の先頭にコメントを書きましょう。
    /**
    * コメント
    * @param $var 説明
    */
    という形式で書いておくのも、今風の「作法」になっています。ここまでできれば、かなり完全な姿になります。

    > このコードのidが削除されたユーザーのIDである可能性は「例外」ということでしょうか?
    > それでしたら入力エラーも例外ではないでしょうか。。。?

    「ユーザーのID」は通常のフローの中では存在することが前提となっているものとしての位置づけだと思います。その前提が崩れていると例外と判断するという区分けで問題ないと思います。一方、ユーザー入力では(ユーザー入力とみなして良いんですよね?)誤った入力があるということを前提に処理をしないといけないです。ユーザーに「どこどこの入力がありません」、などの案内文の表示する必要があったりして、処理フローを定義しないといけないです。
    もしそうじゃない、その値が入るもの前提のプログラムなら、例外としても良い場合であったかもしれません。

    > メール送信部分のロジックをprivate _send_mailというメソッドを作って分けたりすのは見やすくなると思うのですが「private err」は無いと思います。。。

    すべてのコントローラーにerr()を付けるということが最終回答ではないです。(そうなってしまっているプログラムも見かけますが・・・)
    最終的には、ここで抽出されたメソッドはさらに別の場所、アプリケーション固有のメソッドの集まりの部分に集めることが理想ですね。

    > 1コントローラでCRUDを書く事もあるのですが

    うーむ、これは恐らくもっとダメなパターンですね。プログラムがズラーっとダダ書きされているんですよね。もしそうでしたら、ぜひ、それらをクラスに分離してみてください。

    > libraryでしたらもっともだと思うのですがControllerですよ?

    Controllerならfunctionを付けていけないという感覚はどこから来たのかわかりませんが、そもそもオブジェクト指向とはそういうものです。ぜひ、メソッドが並んでいる状況がかっこいいという感覚になってください。
    ・・・かっこいいという感覚は得難いとしても、無駄に定義された変数を見つけ出したり、よりよいアルゴリズムを思いつきやすくなるなどのメリットを実感できるまでになれば良いですね。

    キャンセル

  • 2015/09/04 10:07 編集

    ご回答ありがとうございます。

    > メソッドに分割したコードを読みました。「微妙」とご自身の判断ですが、方向性としてめちゃくちゃいいじゃないですか!当初はerr()だけの分離と思っていたのですが、その他の機能も分離してみたようで、真面目さがにじみ出ています。ものすごくプロっぽいかっこいい形になってきていると思いますよ!(外注で指示したコードも、いつもこんな風に帰ってくればいいのに・・・プロのくせに!)
    > このように、関数で細かくすると複数のコントローラーで使いまわされているプログラムの分離も行いやすくなり、単体テストに乗せたりすることもしやすくなっていきます。

    どう考えても、微妙じゃないですか。。。
    外注に指示したコードがこんなコードになって帰ってきたら発狂します。
    何度も書かせて頂いていますが、これ、MVCのControllerですよ?
    もしかしてではございますが、MVC フレームワークをお使いになった事はないのではないでしょうか?


    > 例えば、
    > function show_output()
    > ですがjsonでアウトプットするという機能として他のコントローラーでも有用になる可能性も見えてきます。別に量産されたメソッドは、ここだけのものでなくても良いんです。どこかにまとめて置くことも視野に入ってきます。メソッドが多くなればさらにそれらをクラスに分離することもできます。そこまで行うことができたら、「実は、この機能にはもっと設定しなけらばならないこともあった」となった時に、変更が一か所で済みます。色々とやれることが見えてきます。

    変更が一ヵ所で済むのはわかるのですが、show_outputってどちらかと言えばhelperじゃないですか?
    なぜController内に入れる必要があるのでしょうか?
    もしくはどうしても使い回したいのであればcoreのCI_Controllerのオーバーライドで実装するかだとは思いますけど。。。


    > 提示されたコードはいくつかバグがあるようですが、この調子でprivateのプロパティ利用やメッセージ文の定数化なども行ってみてください。そして、すべての関数の先頭にコメントを書きましょう。
    /**
    * コメント
    * @param $var 説明
    */
    > という形式で書いておくのも、今風の「作法」になっています。ここまでできれば、かなり完全な姿になります。

    もしかしてではございますが、あなたの言っている「作法」は「あなたの会社のコーディングルール」もしくは「俺のルール」では。。。。

    アノテーションはmodelやlibraryにはつけますがcontrollerのpublicメソッド にはあまり書きません。
    メッセージ文の定数化は必要ありません。
    Languageクラスを使用すれば良いと思います。



    > 「ユーザーのID」は通常のフローの中では存在することが前提となっているものとしての位置づけだと思います。その前提が崩れていると例外と判断するという区分けで問題ないと思います。一方、ユーザー入力では(ユーザー入力とみなして良いんですよね?)誤った入力があるということを前提に処理をしないといけないです。ユーザーに「どこどこの入力がありません」、などの案内文の表示する必要があったりして、処理フローを定義しないといけないです。

    大変恐縮ですが
    ・MVC フレームワークを使用された事が無いのではないでしょうか?
    ・もしくは、コードを読んでいないのではないでしょうか?

    URIセグメントの値が入ると思うんですが。。。



    > もしそうじゃない、その値が入るもの前提のプログラムなら、例外としても良い場合であったかもしれません。

    そうですね。
    この質問では、その「良い場合」の明確なパターンが知りたいのですが。。。



    > すべてのコントローラーにerr()を付けるということが最終回答ではないです。(そうなってしまっているプログラムも見かけますが・・・)

    全てのControllerではなく全てのエラー表示が必要なpublicメソッドになるかと思うのですが。。。


    > 最終的には、ここで抽出されたメソッドはさらに別の場所、アプリケーション固有のメソッドの集まりの部分に集めることが理想ですね。

    MVCってご存知でしょうか?



    > うーむ、これは恐らくもっとダメなパターンですね。プログラムがズラーっとダダ書きされているんですよね。もしそうでしたら、ぜひ、それらをクラスに分離してみてください。

    著名な人でも1 ControllerでCRUDを記述されている方はいくらでもいるのですが。。。
    Controllerを| C | R | U | D |で分割する必要があるときは分割しますが、滅多に無いと思います。
    特殊な環境でご活躍されているのですね。




    > Controllerならfunctionを付けていけないという感覚はどこから来たのかわかりませんが、そもそもオブジェクト指向とはそういうものです。ぜひ、メソッドが並んでいる状況がかっこいいという感覚になってください。

    Controllerならfunctionをつけてはいけない等と書いた覚えは無いです。
    privateメソッドを複数定義するぐらいならhelperかlibraryでやれと思ってしまうだけです。
    MVCで開発された経験が無いのでは?



    >・・・かっこいいという感覚は得難いとしても、無駄に定義された変数を見つけ出したり、よりよいアルゴリズムを思いつきやすくなるなどのメリットを実感できるまでになれば良いですね。

    そうですね。。。。

    キャンセル

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

  • ただいまの回答率 89.97%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる