タグ付けされた質問 「parameters」

C＃にはoutand refキーワードがあります。なぜこれら2つが必要なのですか？免責事項：C＃の深い知識はありません。

18 c#  parameters  keywords 

Martin FowlerのRefactoring bookで一般的なコードのにおいについて読んでいます。その文脈で、私はコードベースで見ているパターンについて疑問に思っていました、そしてそれが客観的にそれをアンチパターンと考えることができるかどうか。 パターンは、オブジェクトが1つ以上のメソッドへの引数として渡されるものであり、それらはすべてオブジェクトの状態を変更しますが、いずれもオブジェクトを返しません。そのため、（この場合は）C＃/。NETの参照によるパスに依存しています。 var something = new Thing(); // ... Foo(something); int result = Bar(something, 42); Baz(something); （特にメソッドに適切な名前が付けられていない場合）そのようなメソッドを調べて、オブジェクトの状態が変化したかどうかを理解する必要があることがわかりました。複数レベルの呼び出しスタックを追跡する必要があるため、コードの理解がより複雑になります。 このようなコードを改善して、新しい状態の別の（クローンされた）オブジェクト、または呼び出しサイトでオブジェクトを変更するために必要なものを返すことを提案したいと思います。 var something1 = new Thing(); // ... // Let's return a new instance of Thing var something2 = Foo(something1); // Let's use out param to 'return' other info about the …

17 code-smell  anti-patterns  parameters 

デジタルボードと通信した後にデータファイルを作成する方法があります。 CreateDataFile(IFileAccess boardFileAccess, IMeasurer boardMeasurer) ここではboardFileAccessとboardMeasurerの同じインスタンスですBoardその実装するオブジェクトの両方IFileAccessとIMeasurer。IMeasurerこの場合、ボード上の1つのピンをアクティブに設定して簡単な測定を行う単一の方法に使用されます。この測定からのデータは、を使用してボードにローカルに保存されIFileAccessます。Board別のプロジェクトにあります。 私はCreateDataFile、簡単な測定を行ってからデータを保存することで1つのことを行うという結論に達しました。同じ方法で両方を行うことは、このコードを使用して測定を行ってファイルに書き込む必要がある他の人にとってより直感的です個別のメソッド呼び出しとして。 私には、同じオブジェクトをメソッドに2回渡すのは厄介に思えます。IDataFileCreator拡張IFileAccessし、必要なメソッドを呼び出すだけのインスタンスをIMeasurer含む実装を持つローカルインターフェイスを作成することを検討しました。同じボードオブジェクトが常に測定とファイル書き込みに使用されることを考えると、同じオブジェクトをメソッドに2回渡すのは悪い習慣ですか？もしそうなら、ローカルインターフェイスと実装を使用して適切なソリューションですか？BoardBoard

15 c#  interfaces  methods  parameters 

C＃は、参照によって渡される引数を作成するためのrefand outキーワードを提供します。2つのセマンティックは非常に似ています。唯一の違いは、フラグ付き変数の初期化です。 ref関数に渡す前に変数を初期化する必要がありますが、必要ありoutません。 out関数内で変数を初期化する必要がありますが、必要ありrefません。 これらの2つのキーワードの使用例もほぼ同じであり、あまりにも頻繁に使用されるため、コードのにおいと見なされます（TryParseandやTryGetValuepattern などの有効な使用例もあります）。 このため、誰かが説明できますが、なぜC＃には非常に狭いユースケース用の2つの非常に類似したツールがあるのですか？ また、MSDNでは、実行時の動作が異なることが記載されています。 refキーワードとoutキーワードは異なる実行時の動作を引き起こしますが、コンパイル時のメソッドシグネチャの一部とは見なされません。 実行時の動作はどのように異なりますか？ 結論 両方の答えが正しいように見えます、ありがとう。jmorenoを受け入れたのは、より明確だからです。

15 c#  parameters  implementations  runtime 

私が働いているプロジェクトでこの機能を見つけました： -- Just returns the text unchanged. -- Note: <text> may be nil, function must return nil in that case! function Widget:wtr(text) return text end 残念なことに、コーダーは社内で機能しなくなりました。何もしないが、呼び出されたパラメーターを返す関数を作成するのはなぜですか？ この例では指定されていませんが、どのような場合でも、そのような関数の使用はありますか？ のため function aFunction(parameter) return parameter end で終わる aFunction(parameter) == parameter なぜ私は aFunction(parameter) == whatIWantToCheck の代わりに parameter == whatIWantToCheck ？

15 functions  parameters  lua  method-chaining 

私のコードが成長し始めるとき、私をしばらく悩ませてきた非常に単純な質問があります。 ネストされた関数呼び出しの長いルートを通過するときに、パラメーターをグローバル変数に置き換える必要がありますか？ 多くの関数が共有変数を変更できるため、グローバル環境はプログラムの状態を予測不可能にする可能性があることを理解していますが、それでもグローバルスペースは物事をとても簡単にします。 私自身について説明しましょう： functionA(){ x = something functionB(x) } functionB(x){ functionC(x) } functionC(x){ finallyDoSomethingWithX(x) } finallyDoSomethingWithX(x){ x += 1 //Very dummy example ignoring pass by value, not reference. } と取り換える： globalX; functionA(){ globalX = something functionB() } ... ... ... finallyDoSomethingWithX(){ globalX += 1 } 2番目の方法は、パラメーターが簡単に蓄積され、コードを再利用する必要があるときに非常に制限される場合があるため、プログラムに非常に多くの自由を与えると感じますが、同時に、変数に関連する場合、関数がモジュール性を失うように感じますグローバル環境では、たとえば、finallyDoSomethingWithX別の変数thaで操作したい場合にも再利用性が失われglobalXます。 私は実際にデザインパターンを使用していないため、これが起こっていると思います。Javascriptでプログラミングしているためです。私にとっては、中規模プロジェクトでは、1つのスクリプトですべてを扱う言語のように感じます。 何かアドバイスは？パターン？必要に応じて、より具体的にすることができます。

10 parameters  globals 

Circleオブジェクトを作成できるライブラリを使用していて、円の半径と中心を指定してオブジェクトを定義できる状況を想像してみてください。ただし、何らかの理由で、必要なflavourパラメーターも受け取ります。ここCircleで、自分のアプリで本当に使用する必要があるとしましょう。ただし、アプリの目的で、フレーバーをFlavours.Cardboard毎回に設定できます。 この「解決」をするために、私は自分の作成Circleのみとり異なる名前空間でクラスをradiusし、centerパラメータとしてではなく、外部ライブラリのへの暗黙のコンバータがあるCircleだけで作成したクラスCircle(this.radius, this.center, Flavours.Cardboard)のオブジェクトを。したがって、他のタイプのが必要なすべての場所でCircle、自動変換を実行します。 そのようなクラスを作成するとどうなりますか？より良い解決策はありますか？私のアプリケーションが、この外部ライブラリの上に構築されたAPIであり、他のプログラマーが使用することを目的としていた場合、何か違いはありますか？

10 c#  object-oriented  constructors  parameters  type-conversion 

メソッドと関数のパラメーターとしてのオブジェクトと一意のIDの使用について賛成または反対の客観的な引数はありますか？（および他のオブジェクトのメンバー？）。特に静的型付け言語のコンテキスト（C＃/ Java / Scala） オブジェクト自体の長所： よりタイプセーフな呼び出し。IDを使用すると、引数の順序が誤ってしまうリスクがあります。これは、そのクラスのIDのみを格納するクラスごとに「ミニ」クラスを保持することで軽減できます。 永続化から一度取得し、再度取得する必要はありません （：courtsey - IDと、IDタイプが変更された場合、INTを言う>長い、そして...ミスの可能性が軒並み変更を必要とするhttps://softwareengineering.stackexchange.com/a/284734/145808） IDを使用するメリット： ほとんどの場合、実際のオブジェクトは必要ありません。uniqueidで十分です。そのため、IDがあれば、永続化から取得する時間を節約できます。 これらのテクニックの混合は、私が見る限り、両方の長所と短所の両方を持っています。 これが具体的に定義された問題であることを考えると、「私は思う」または「好き」タイプではなく、客観的な答えがあることを願っています... :-)。 編集：コメンターの提案に関するコンテキスト-唯一の制限は静的に型付けされた言語です。このアプリケーションは汎用アプリケーションですが、特定の使用シナリオに基づいて回答を得ることもできます。 編集：もう少しコンテキスト。書籍管理システムがあるとします。私のモデルは： Book: { id: Int, isbn: String, donatedBy: Member, borrowedBy: Member } Member: {id: Int, name: String} Table- wishlist: { isbn: String, memberId: Int} Table- borrows: { id: Int, memberId: Int} Method: isInWishList( book: …

10 coding-style  methods  parameters 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は新しいクラスを書き始めたばかりで、厳密には必要のないメソッド引数をたくさん追加していることに気付きました。これは、クラスの一般的な構成や依存関係ではなく、特定のメソッド呼び出しに固有のクラス内の状態を回避する習慣に従っています。 そうすることは、引数を持たない可能性のある多くのメソッドが1、2、または3で終わることを意味します。 このトレードオフについてどう思うか、どのような状況でどのアプローチを取るかをどのように決定するかについて、あなたの意見を聞きたいのですが。 コードを説明するとき、コードは英語よりも理解しやすいことが多いため、両方のバリアントを含む小さな要点を作成しました：https : //gist.github.com/JeroenDeDauw/6525656

9 class-design  complexity  methods  parameters  cohesion 

よると、機能が受け入れるべきか、多くのパラメータにそこガイドラインはありますか？、メソッドにパラメータが多すぎてはいけません。ただし、いくつかの回答は、この問題はビルダーパターンによって解決できることを示唆しています。 Builder b=new Builder(); b.setParm1("a"); b.setParm2("b"); . . . Obj obj=b.createObj(); または、単一のオブジェクトにパラメーターをカプセル化します。 ObjectParam op=new ObjectParam(); op.param1="a"; op.param2="b"; . . . obj.f(op); しかし、それが問題を解決するかどうかは疑わしいです。なぜなら、パラメーターをより適切な方法で（つまり：水平から垂直に）配置する方法だと思いますが、タスクがあまりにも多くのパラメーターに依存するという性質は変わりません。そして、パラメーターのチェーンをより見やすくしたい場合は、各パラメーターに次のような新しい行を使用できます。 https://softwareengineering.stackexchange.com/a/331680/248528 だから私の質問は、「パラメータが多すぎる」は視覚的な問題（コードの長い1行を読み取るのは難しい）ですか、それとも論理的な問題（タスクの性質はパラメータが多すぎるかによって異なり、分解する必要があります）ですか。それが視覚的な問題の詳細である場合、各パラメーターの新しい行で問題が解決されますか？

8 coding-style  parameters 

他のメソッドを呼び出すメソッドをいくつか書いています。 情報を渡すには、いくつかの選択肢があります。 情報をパラメーターとして渡す 他のメソッドがインスタンス変数にアクセスできるようにインスタンス変数を設定します どちらのオプションをいつ選択すればよいですか？ 渡されるものについて非常に具体的であるため、最初のオプションは良いようです。欠点は、多くの値が渡されていることです。 2番目の方法はすべての値を渡す必要はありませんが、メソッドがインスタンス変数を「どこかに」設定するという多くの魔法につながるようです クラス内の他のメソッドに渡されることについて常に明示する必要がありますか？例外はありますか？

8 object-oriented  ruby  parameters 

プログラムのUML図を描きたい。クラスにBarneyは、Yabadaba(Doo d)タイプのパラメータを取るメソッドがありますDoo。 どのように私は、そのクラスを表しますDooクラスで使用されているBarney私のUMLダイアグラムに？

8 uml  methods  parameters