コールチェーンのいくつかのレベルでのみ使用される（パラメータを渡す）パターンの名前はありますか？

私はいくつかのレガシーコードでグローバル変数を使用する代替案を見つけようとしていました。しかし、この質問は技術的な選択肢に関するものではなく、私は主に用語について心配しています。

明らかな解決策は、グローバルを使用する代わりに関数にパラメーターを渡すことです。このレガシーコードベースでは、値が最終的に使用されるポイントと最初にパラメーターを受け取る関数の間で、長い呼び出しチェーン内のすべての関数を変更する必要があることを意味します。

higherlevel(newParam)->level1(newParam)->level2(newParam)->level3(newParam)

どこnewParam私の例では、グローバル変数以前だったが、それは代わりに、以前にハードコード値だったかもしれません。ポイントは、newParamの値がで取得されhigherlevel()、で「移動」する必要があることlevel3()です。

値を変更せずに「渡す」多くの関数にパラメータを追加する必要があるこのような状況/パターンの名前があるかどうか疑問に思っていました。

うまくいけば、適切な用語を使用することで、再設計のソリューションに関するリソースをさらに見つけ、同僚にこの状況を説明できるようになります。

データ自体は「トランプデータ」と呼ばれます。これは「コードのにおい」であり、あるコードが他のコードと距離を置いて仲介者を介して通信していることを示します。

• 特に呼び出しチェーンで、コードの剛性を高めます。呼び出しチェーン内のメソッドをリファクタリングする方法については、さらに制約があります。
• データ/メソッド/アーキテクチャに関する知識を、あまり気にしない場所に配布します。ただ通過するデータを宣言する必要があり、その宣言に新しいインポートが必要な場合、名前空間が汚染されています。

グローバル変数を削除するためのリファクタリングは困難であり、トランプデータはその1つの方法であり、多くの場合最も安価な方法です。コストがかかります。

これ自体はアンチパターンだとは思いません。問題は、実際にはそれぞれを独立したブラックボックスと考える必要があるときに、関数をチェーンと考えていることだと思います（注：再帰的メソッドは、このアドバイスの顕著な例外です）。

たとえば、2つのカレンダー日付の間の日数を計算する必要があるとしましょう。関数を作成します。

int daysBetween(Day a, Day b)

これを行うために、新しい関数を作成します。

int daysSinceEpoch(Day day)

それから私の最初の機能は簡単になります：

int daysBetween(Day a, Day b)
{
    return daysSinceEpoch(b) - daysSinceEpoch(a);
}

これについてアンチパターンはありません。daysBetweenメソッドのパラメーターは別のメソッドに渡されており、メソッド内で参照されることはありませんが、そのメソッドが必要なことを行うためには引き続き必要です。

私がお勧めするのは、各機能を見て、いくつかの質問から始めることです。

• この機能には明確で焦点の合った目標がありますか、それとも「何かをする」方法ですか？通常、ここでは関数の名前が役立ちます。名前で記述されていないものがある場合、それは赤旗です。
• パラメーターが多すぎますか？メソッドが合法的に大量の入力を必要とする場合もありますが、非常に多くのパラメーターがあるため、使用や理解が面倒になります。

メソッドにバンドルされた単一の目的のないごちゃ混ぜのコードを見ている場合、それを解くことから始めるべきです。これは面倒です。最も簡単なものから始めて、別の方法に移動し、一貫性のあるものになるまで繰り返します。

パラメーターが多すぎる場合は、メソッドからオブジェクトへのリファクタリングを検討してください。

BobDalgleishは、この（アンチ）パターンが「トランプデータ」と呼ばれることをすでに指摘しています。

私の経験では、過剰なトランプデータの最も一般的な原因は、オブジェクトまたはデータ構造に実際にカプセル化されるリンクされた状態変数の束を持っていることです。場合によっては、データを適切に編成するために、オブジェクトの束をネストする必要さえあります。

簡単な例では、同様の性質を持つカスタマイズ可能なプレイヤーキャラクターを持っているゲームを、検討しplayerName、playerEyeColorその上と。もちろん、プレーヤーはゲームマップ上の物理的な位置、および現在および最大の健康レベルなどのさまざまな他のプロパティも持っています。

このようなゲームの最初のイテレーションでは、これらのすべてのプロパティをグローバル変数にすることは完全に合理的な選択かもしれません。したがって、グローバル状態には次のような変数が含まれる場合があります。

playerName = "Bob"
playerEyeColor = GREEN
playerXPosition = -8
playerYPosition = 136
playerHealth = 100
playerMaxHealth = 100

しかし、ある時点で、おそらくゲームにマルチプレイヤーモードを追加するために、このデザインを変更する必要があることに気付くかもしれません。最初の試みとして、これらすべての変数をローカルにし、それらを必要とする関数に渡すことができます。ただし、ゲーム内の特定のアクションには、次のような関数呼び出しチェーンが含まれる場合があります。

mainGameLoop()
 -> processInputEvent()
     -> doPlayerAction()
         -> movePlayer()
             -> checkCollision()
                 -> interactWithNPC()
                     -> interactWithShopkeeper()

...このinteractWithShopkeeper()機能では、店主がプレーヤーを名前でアドレス指定するため、突然これらすべての機能をplayerName介してトランプデータとして渡す必要があります。そして、もちろん、店主が青い目をしたプレイヤーがナイーブだと思っており、それらに対してより高い価格を請求する場合、機能のチェーン全体を通過する必要があります。playerEyeColor

この場合の適切な解決策は、もちろん、プレイヤーキャラクターの名前、目の色、位置、健康、およびその他のプロパティをカプセル化するプレイヤーオブジェクトを定義することです。そうすれば、その単一のオブジェクトを、何らかの形でプレーヤーに関係するすべての関数に渡すだけで済みます。

また、上記の関数のいくつかは、そのプレーヤーオブジェクトのメソッドに自然に作成できます。これにより、プレーヤーのプロパティに自動的にアクセスできるようになります。ある意味、これは単なるシンタックスシュガーです。オブジェクトのメソッドを呼び出すと、オブジェクトインスタンスがメソッドに隠されたパラメーターとして効果的に渡されますが、適切に使用するとコードがより明確で自然に見えます。

もちろん、典型的なゲームは、単なるプレーヤーよりもはるかに「グローバル」な状態になります。たとえば、ほぼ確実にゲームが行われる何らかのマップがあり、マップ上を移動するノンプレイヤーキャラクターのリストと、おそらくその上に置かれたアイテムがあります。これらすべてをtrampオブジェクトとして渡すこともできますが、それでもメソッドの引数が乱雑になります。

代わりに、解決策は、永続的または一時的な関係を持つ他のオブジェクトへの参照をオブジェクトに保存させることです。したがって、たとえば、プレイヤオブジェクトは、のような方法がなるように、現在のレベル/マップへの参照を持っているでしょう「ゲームの世界」オブジェクトへの参照を格納する必要があるだろう（そしておそらくどのNPCがあまりにもオブジェクト）player.moveTo(x, y)には必要ありません。マップをパラメーターとして明示的に指定します。

同様に、プレイヤーキャラクターがペットの犬を追いかけた場合、犬を記述するすべての状態変数を自然に1つのオブジェクトにグループ化し、プレイヤーオブジェクトに犬への参照を与えます（プレイヤーが、たとえば、名前で犬を呼び出す）、またはその逆（犬がプレーヤーの位置を知るため）。そしてもちろん、プレーヤーと犬のオブジェクトを両方ともより一般的な「俳優」オブジェクトのサブクラスにしたいので、同じコードを再利用して、たとえば両方をマップ上で移動することができます。

追伸 例としてゲームを使用しましたが、そのような問題が発生する他の種類のプログラムもあります。しかし、私の経験では、根本的な問題は常に同じである傾向があります。1つまたは複数の相互リンクされたオブジェクトに本当にまとめたい個別の変数（ローカルまたはグローバル）がたくさんあります。関数に侵入する「トランプデータ」が数値シミュレーションの「グローバル」オプション設定またはキャッシュされたデータベースクエリまたは状態ベクトルで構成されているかどうかにかかわらず、解決策は常にデータが属する自然なコンテキストを識別し、それをオブジェクトにすることです（または選択した言語で最も近いものは何でも）。

私はこれの特定の名前を知りませんが、あなたが説明する問題はそのようなパラメータの範囲のための最良の妥協点を見つける問題であることに言及する価値があると思います：

• グローバル変数として、プログラムが特定のサイズに達するとスコープが大きすぎます

• 純粋にローカルなパラメーターとして、スコープが小さすぎる可能性があります。これは、コールチェーン内に多数のパラメーターリストが繰り返される場合に発生します。

• そのため、トレードオフとして、このようなパラメーターを1つ以上のクラスのメンバー変数にすることができます。これを適切なクラス設計と呼んでいます。

あなたが説明しているパターンは、まさに依存性注入です。これはアンチパターンではなく、パターンであると主張するコメント者もいますが、私は同意する傾向があります。

また、@ JimmyJamesの答えにも同意します。彼は、各関数をすべての入力を明示的なパラメーターとして受け取るブラックボックスとして扱うのが良いプログラミング手法であると主張しています。つまり、ピーナッツバターとゼリーのサンドイッチを作る関数を書いている場合、次のように書くことができます。

Sandwich make_sandwich() {
    PeanutButter pb = get_peanut_butter();
    Jelly j = get_jelly();
    return pb + j;
}
extern PhysicalRefrigerator g_refrigerator;
PeanutButter get_peanut_butter() {
    return g_refrigerator.get("peanut butter");
}
Jelly get_jelly() {
    return g_refrigerator.get("jelly");
}

ただし、依存関係の注入を適用して、代わりに次のように記述する方が適切です。

Sandwich make_sandwich(Refrigerator& r) {
    PeanutButter pb = get_peanut_butter(r);
    Jelly j = get_jelly(r);
    return pb + j;
}
PeanutButter get_peanut_butter(Refrigerator& r) {
    return r.get("peanut butter");
}
Jelly get_jelly(Refrigerator& r) {
    return r.get("jelly");
}

これで、関数シグネチャにすべての依存関係を明確に文書化する関数ができました。これは読みやすくするのに最適です。結局のところ、本当のためににていることmake_sandwichへのアクセスを必要としますRefrigerator。そのため、古い関数シグネチャは基本的に、冷蔵庫を入力の一部として受け取らないことで不誠実でした。

ボーナスとして、クラス階層を正しく行い、スライスを避けるなどの場合はmake_sandwich、MockRefrigerator！（ユニットテスト環境ではPhysicalRefrigeratorsにアクセスできない可能性があるため、この方法でユニットテストする必要がある場合があります。）

依存関係注入のすべての使用がコールスタックの多くのレベルで同様の名前のパラメーターを配管する必要があるわけではないことを理解していますので、私はあなたが尋ねた質問に正確に答えていません... 「依存性注入」は間違いなくあなたに関連するキーワードです。

これは、ほとんどがカップリングの教科書の定義です。あるモジュールは、別のモジュールに深く影響する依存関係を持ち、変更すると波及効果を生み出します。他のコメントと回答は、これがグローバルよりも改善されていることを示しています。これは、カップリングが破壊的ではなく、より明確になり、プログラマにとって見やすくなったためです。それはそれが修正されるべきではないという意味ではありません。カップリングを削除または削減するためにリファクタリングできる必要がありますが、しばらくそこにあると痛みを伴う場合があります。

この答えはあなたの質問に直接答えるものではありませんが、それを改善する方法について言及せずに通過させることはできません（あなたが言うように、それはアンチパターンかもしれません）。「トランプデータ」を避ける方法に関するこの追加の解説から、あなたや他の読者が価値を得られることを望みます（ボブダルグレイッシュが私たちのために非常に役立つ名前を付けたので）。

この問題を回避するために、オブジェクト指向をさらに行うことを提案する回答に同意します。ただし、単に「多くの引数を渡すために使用したクラスを渡すだけ！」にジャンプすることなく、この引数の受け渡しを深く減らす別の方法は、プロセスの一部のステップが下位ではなく上位で発生するようにリファクタリングすることです1。たとえば、次の変更前のコードを次に示します。

public void PerformReporting(StuffRepository repo, string desiredName) {
   var stuffs = repo.GetStuff(DateTime.Now());
   FilterAndReportStuff(stuffs, desiredName);
}

public void FilterAndReportStuff(IEnumerable<Stuff> stuffs, string desiredName) {
   var filter = CreateStuffFilter(FilterTypes.Name, desiredName);
   ReportStuff(stuffs.Filter(filter));
}

public void ReportStuff(IEnumerable<Stuff> stuffs) {
   stuffs.Report();
}

これはでしなければならないことが多いほど悪化することに注意してくださいReportStuff。使用するレポーターのインスタンスを渡す必要がある場合があります。そして、引き継がなければならないあらゆる種類の依存関係、関数からネストされた関数へ。

私の提案は、すべてをより高いレベルに引き上げることです。ステップの知識は、メソッド呼び出しのチェーン全体に広がるのではなく、単一のメソッドでの生活を必要とします。もちろん、実際のコードではより複雑になりますが、これによりアイデアが得られます。

public void PerformReporting(StuffRepository repo, string desiredName) {
   var stuffs = repo.GetStuff(DateTime.Now());
   var filter = CreateStuffFilter(FilterTypes.Name, desiredName);
   var filteredStuffs = stuffs.Filter(filter)
   filteredStuffs.Report();
}

ここでの大きな違いは、依存関係を長いチェーンで渡す必要がないことです。1レベルだけでなく、数レベルの深さまでフラット化しても、それらのレベルが「フラット化」を達成し、プロセスがそのレベルでの一連のステップと見なされる場合は、改善されています。

これはまだ手続き的であり、オブジェクトに変換されたものはまだありませんが、何かをクラスに変換することで達成できるカプセル化の種類を決定するための良いステップです。beforeシナリオの深く連鎖したメソッド呼び出しは、実際に何が起こっているかの詳細を隠し、コードを非常に理解しにくくします。あなたはこれをやりすぎて、高レベルのコードにすべきでないことを知らせるか、またはあまりにも多くのことを行い、単一責任の原則に違反するメソッドを作成することができますが、一般的に、物事を平らにすることは少し助けになることがわかりましたより明確なコードとより良いコードに向けて段階的に変更を加えること。

このすべてを実行している間、テスト可能性を考慮する必要があることに注意してください。チェーンメソッド呼び出しは、テストするスライスのアセンブリに適切なエントリポイントと出口ポイントがないため、実際にユニットテストを難しくします。このフラット化を使用すると、メソッドがそれほど多くの依存関係を取得しなくなるため、テストが簡単になり、モックをそれほど必要としません。

私は最近、17個の依存関係のようなものをとるクラスにユニットテストを追加しようとしました（私は書きませんでした）。私はそれがすべてうまくいったわけではありませんが、クラスを3つのクラスに分割し、それぞれが関係する別々の名詞の1つを処理し、最悪の場合は12に、依存関係のリストは約8に下げました一番いいもの。

テスト容易性は、より良いコードを書くことを強制します。ユニットテストを書く前に持っていたバグの数に関係なく、コードについて違った考え方をするようになり、最初からより良いコードを書くことがわかるので、ユニットテストを書くべきです。

あなたは文字通りデメテルの法則に違反していませんが、あなたの問題はいくつかの点でそれに似ています。質問のポイントはリソースを見つけることなので、デメテルの法則について読んで、そのアドバイスがあなたの状況にどの程度当てはまるかを確認することをお勧めします。

常にすべてを渡すオーバーヘッドではなく、特定の変数をグローバルとして持つのが（効率、保守性、実装の容易さの点で）最適な場合があります（永続化する必要のある15個ほどの変数があるとします）。そのため、潜在的な混乱（名前空間と改ざんのあるもの）を軽減するために、（C ++のプライベート静的変数として）より有効なスコープをサポートするプログラミング言語を見つけることは理にかなっています。もちろん、これは単なる常識です。

しかし、OPで述べられているアプローチは、関数型プログラミングを行う場合に非常に役立ちます。

発信者は以下のこれらすべてのレベルを知らず、気にしないので、ここにはアンチパターンはありません。

誰かがhigherLevel（params）を呼び出しており、higherLevelがその仕事をすることを期待しています。higherLevelがparamsで行うことは、呼び出し側ビジネスではありません。higherLevelは、この場合はparamsをlevel1（params）に渡すことで、できる限り最善の方法で問題を処理します。それは絶対に大丈夫です。

コールチェーンが表示されますが、コールチェーンはありません。最上部には、できる限り最善の方法で仕事をする機能があります。他にも機能があります。各機能はいつでも置き換えることができます。