Q&A
ご回答ありがとうございます！
> 関数名はあくまでも機能を示しますから、引数が増えようが何しようが命名は「機能が分かるように」する
間違いなくそのとおりですね、ありがとうございます。
既存プロジェクトが基本引数からの命名スタンスなので、完全にその発想がありませんでした。
function getByThreeTypes(int $aaa, int $bbb, int $ccc)
なるほど個数……その手段もあるんですね！ありがとうございます
PHPのコードの命名規則で少し困っています。
案や経験のお知恵を貸していただけると嬉しいです。
質問
複数の引数がある場合のメソッド名の命名で困っています。
質問詳細
例えば、DBからプライマリーキーでデータを取得する処理があった場合、
function getById(int $id)
のように定義できるかと思います。
では、与える引数が多い場合はどの様に命名するのがスマートなのでしょうか？
（メソッド名が長くなる）
function getByAaaTypeIdBbbTypeIdCccTypeId(int $aaaTypeId, int $bbbTypeId, int $cccTypeId)
は流石にごちゃごちゃしすぎます……
こういうのは引数を分けずに連想配列などで渡すのでしょうか？
その場合、どの様に命名すればいいのでしょうか…？
一人で開発する分には自分がわかればいいのですが、人と開発する場合なので結構悩んでおります。
お力を貸していただけると嬉しいです。
回答9件
0
引数を基準に命名する必要があるのでしょうか。
それでは20個引数があったとして、それを全部使用しデータ検索する場合は20個を繋げたメソッド名になりませんか？
引数を使うというより、「どういうデータ」を取得したいのかで命名してみてはいかがでしょうか。
もし引数を必ず命名で使わなければいけないという規約があるのでしたら、配列などにまとめた物を渡すしかないかと思います。
投稿2018/11/09 05:40
総合スコア2341
0
関数名はあくまでも機能を示しますから、引数が増えようが何しようが命名は「機能が分かるように」するべきでしょう。
挙げられたのでいえば、
PHP
1function getById(in $id) 2function getByThreeTypes(int $aaa, int $bbb, int $ccc)
にでもしますかね。
ただし、上の例がどちらも「あるテーブルのプライマリーキーを指定して取得する」のであれば、
PHP
1function getByPk(int $id) 2function getByPk(int $aaa, int $bbb, int $ccc)
にします。明確に Primary Key でアクセスしているとわかったほうがいいからです。
投稿2018/11/09 05:40
総合スコア13703
いや、これはもともとが aaaTypeId, bbbTypeID, cccTypeID と「3つのtype」からだったからです。個数で単純に Three と付けたわけではないです。
0
ベストアンサー
UNIX哲学を参考にしましょう。
これがUNIXの哲学である。
一つのことを行い、またそれをうまくやるプログラムを書け。
協調して動くプログラムを書け。
標準入出力（テキスト・ストリーム）を扱うプログラムを書け。標準入出力は普遍的インターフェースなのだ。
まぁ、質問はPHPの話なので「標準入力」云々は無視して良いのですが、
その手前の「一つのことを行い、またそれをうまくやるプログラムを書け」は非常に重要な考え方です。
機能はしょぼくてシンプルであればあるほどよいのです。
1個の引数だけ引き受けるメソッドを沢山用意しましょう。
与える引数が多い場合はどの様に命名するのがスマートなのでしょうか？
これは単純に連想配列案件でしょう。
適当にSQL文字列作る風な実装で書くとこんな感じになると思います。
PHP
1function getByOptions (options = []) { 2 $where = ''; 3 foreach ($options as $key => $val) { 4 if ($where === '') { 5 $where = 'WHERE '; 6 } else { 7 $where = $where . ' AND '; 8 } 9 $where = $where . $key . ' = ' . $val; 10 } 11} 12getByOptions([ 13 'aaa' => 123, 14 'bbb' => 234, 15 'ccc' => 345, 16]);
引数がゴテゴテ何個もあるのは完全に設計ミスです。
連想配列で受けられないようなケースは一時的にオブジェクトのプロパティに持たせて、
違う条件も欲しければ別途newして作り直すとか…
オブジェクト志向的な設計を工夫して対応しましょう。
投稿2018/11/09 05:42
総合スコア21158
ご回答有り難うございます！
> UNIX哲学を参考にしましょう。
> 機能はしょぼくてシンプルであればあるほどよいのです。
> 1個の引数だけ引き受けるメソッドを沢山用意しましょう。
なるほど、確かにその方がわかりやすいですね。
Pythonがそのようなイメージがあります。
> これは単純に連想配列案件でしょう。
> 適当にSQL文字列作る風な実装で書くとこんな感じになると思います。
まさにこれが現在の案件でした…！
ありがとうございます！
> getByOptions
なるほど、この様に単純化してしまえば確かに汎用性もあるし、ごちゃごちゃしなくてすみますね…！
目からウロコです！＞＜
ちなみなのですが、SQLのjoinが必要な場合のメソッドだと、どの様にされていますでしょうか？
> SQLのjoinが必要な場合のメソッドだと、どの様にされていますでしょうか？
基本はtacsheavenさんの回答と同じ考え方をします。
しかし、例えばDBのUsersオブジェクトに対して、joinが必要って時点でかなりアレですよね。
なんでjoinしなければ成立しないのかに着目して、
よく使うのであればテーブルとしては存在しないが、複数テーブルをjoin前提で扱う論理テーブル的な存在をクラスとして用意してみるという発想はあります。
ご返信ありがとうございます。
> 基本はtacsheavenさんの回答と同じ考え方をします。
なるほど、機能面からの命名ですね。
> 例えばDBのUsersオブジェクトに対して、joinが必要って時点でかなりアレですよね
まあ、Usersだとそうですね！
今回データが複雑で、joinが複数回必要な構造になってしまいました。。。
（別プロジェクトとのデータの整合性とかも合わせなければならず……）
なので、必要な値が多く、引数が多くなってしまう and メソッド名が長くなる問題にあたってしまい、
それを打破したく現在に至ります。
> 複数テーブルをjoin前提で扱う論理テーブル的な存在をクラスとして用意してみるという発想
こちらご提案ありがとうございます。
「論理テーブル的な存在」とは……どういったものでしょうか。
ぐぐると「MySQLでいうviewのようなもの」と出てくるのですが、おそらくviewは使わずにコードで実装するかと思います。
今回、データをある程度SQLのwhere句で絞らないと、数十万件のデータが返ってきて、PHPがメモリエラーで死を迎えるという悲惨な状態になっております……
こういった問題も、論理テーブルというもので解決できるのでしょうか？
> viewは使わずにコードで実装するかと思います
通常フレームワークのModelはMySQL等のテーブルと1:1でひも付きます。
しかし、マニュアルでSQL文作って発行したり、ORマッパーで好き勝手なクエリを生成する機能も備わっています。
そういう機能を利用して、from区にAテーブルにBテーブルをジョインさせて検索を行う前提のModel作って管理すればよくね？というアプローチです。
まぁ素直にViewを使っても良いと思いますし、この辺は完全にアイデア次第です。
> こういった問題も、論理テーブルというもので解決できるのでしょうか？
それ以前にMySQLなどと通信を行うのはSQLという文字列がベースです。
重要な事は「適切なSQLを作るプログラムを作って管理する」わけで、
そういう視点で見れば自分のプログラミングスキルやオブジェクト指向による設計能力は無限大に活かせます。
色々作ってみて、「思ってたのと違うから次はこうしてみよう」という風に試行錯誤してみてください。
0
可変的な引数なら配列で渡すことが多いですが、
固定的で抜けを許さないならむしろご提示の羅列してるタイプが好ましいと思います。
もちろん配列で渡しても結局参照するときに意味がわかる命名が好ましいのですから
なにでやっても結果は同じだと思います
投稿2018/11/09 05:33
総合スコア114968
ご回答有り難うございます。
> 固定的で抜けを許さないならむしろご提示の羅列してるタイプが好ましい
なるほど！
ありがとうございます！
古いのかもしれませんが私もこのタイプです。
配列で渡すと引数の見た目はすっきりしますが、
ソース内を覗かないと、何の引数がどう必要なのかわからなくなるのは
あまり好きではありません。
SQLの列名という事も、作った本人はわかりますが、
ぱっと見て、ソースを見なくても、なんの引数がどう必要でどう必須なのかが
すぐにわかる方がいいという考えです。
0
こういうのは引数を分けずに連想配列などで渡すのでしょうか？
引数の渡し方についてはメンテのしやすさや可読性を考慮して決めればよいかと。
yamabejp 様が仰るように、臨機応変に適宜使い分けるのがよいと思われます。
その場合、どの様に命名すればいいのでしょうか…？
getByIdは「IDをキーにして(何か)を取得する」と言うような意味合いでしょうか。
私なら「そのメソッドがどういった役割、機能を持つか」が明示的にわかるようにしますかね。
何かを作成するメソッドならmake○○、何かを削除するメソッドならdelete○○みたいな感じですね。
後々自分や他の人が見た場合に、何をやっているかがイメージしやすいような形にするのがよいかと。
投稿2018/11/09 05:36
編集2018/11/09 05:41
総合スコア992
ご回答有り難うございます。
すいません、論点にするつもりではなかったので書いてませんでしたが、
CakePHPのメソッドなので、
$this->DBのクラス名->getById
の様になります
なるほど、さいでございましたか。
何れにせよ kunai 様や azuapricot 様のように
「なにで」取得するかではなく「なにを」取得するかで命名しますね。
どうしても「なにで」取得するかを主体にしなくてはいけない(By○○)であれば、
引数を配列(単一のもの)にしてしまうか「引数をひとまとめにしたものになんらかの呼称をつける」
(その場合はinputのparamについてPhpDocに記載したりだとか)位しか思い浮かばないですな…。
0
同じでよくないですか？
それかidというのが気持ち悪いならpkey
PhpDocの様式でコメントでparamとreturnの補足をつければ良いかと。
モデルであればどのデータのgetIdかはクラス名辿ればかりますし。
固定の引数がたくさんあるのは拡張性に欠けるので配列でドンと渡して
設定でpkeyのリストを持っておいて必須チェックかけるようにすれば良いと思います。
今後構成が変わってキーが増減する場合のことを考えて命名すべきと思います。
メソッド名を変えて(呼びもともメソッドにも)引数も増やすのか
呼びもとの引数を増やしてコメント追記するだけにするのか
影響範囲次第だと思います。
IDEを使っていてきちんとPhpDoc書いてればコメントは開発時に確認できるので
長すぎるメソッド名は開発を進めてメンテナンスまで考えた場合、
リスク高いと思います
投稿2018/11/09 05:35
編集2018/11/09 05:46
総合スコア80854
ご回答有り難うございます。
> idというのが気持ち悪いならpkey
表現足りずすいません。
こちら、「メソッド名が長くなってしまう」問題をどうしようかなーと……
こういうのって長くなるのは仕方ないのでしょうか？
そのあたり含めて伝わりにくかったかなと思ったので追記しました。
ご返信ありがとうございます。
> IDEを使っていてきちんとPhpDoc書いてればコメントは開発時に確認できるので
> 長すぎるメソッド名は開発を進めてメンテナンスまで考えた場合、
> リスク高いと思います
そうですよね……
他の方の回答を見て、「別に引数名を命名に使わなくてもいい」という発想をいただきました。
そちらを参考に、わかりやすい命名を考えます。
ありがとうございます！
はい。システムは必ず変更が入るものです。
最初はそのつもりではなくても何年か経ったらそのときの状態に合わせて変化が必要になります。
あまり細かくつけすぎるのも考えものです。
コメントはそういうときのための(どういう意図や意味があるのか)ものだと思います
0
辞書を共有できるネーミングツールってのがありますけど、、。
codic
概要がわかるblog
投稿2018/11/09 06:39
総合スコア798
0
ベストアンサー出たあとで申し訳ないですが、答えとしてはケースバイケースで、絶対コレが正しいというのはないと思います。
なので、どんな書き方があるのかを知っておいて、その状況に適切だと思うのを選ぶのが良いと思います。
php
1function getByAaaTypeIdBbbTypeIdCccTypeId(int $aaaTypeId, int $bbbTypeId, int $cccTypeId)
php
1function getRecords($aaaTypeId, $bbbTypeId = null, $cccTypeId = null)
php
1function getWithOptions($options = [])
php
1getById($id)->filterWithTypeA($typeA)->filterWithTypeB($typeB)
で、個人的に思うのは、連想配列で渡すのは、本当に必要かどうか考えて、できれば最後の選択肢にして欲しいです。
後で修正する必要が出たときに大変だからです。
柔軟性がある反面、引数になんでもアリなわけだから、動いてみなくちゃわからないってことになりがちだし、影響度も膨らみがちだからです。
だから、3個ぐらいの引数だったら、そのまま引数の名前で関数名にするか、他の意味で命名するのが良いと思います。
だって、他の言語だったら、迷わずオーバーロードで書くでしょう？
投稿2018/11/13 01:13
総合スコア56
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/11/09 05:58
2018/11/09 06:03