タグ付けされた質問 「c#」

不変オブジェクトのような可変オブジェクトと不変オブジェクトの利点は、共有および書き込み可能な状態が原因で、マルチスレッドプログラミングの問題のトラブルシューティングが非常に困難になることを理解できます。逆に、変更可能なオブジェクトは、毎回新しいコピーを作成するのではなく、オブジェクトのIDを処理するのに役立ちます。そのため、特に大きなオブジェクトのパフォーマンスとメモリ使用量も向上します。 私が理解しようとしていることの1つは、関数型プログラミングのコンテキストで可変オブジェクトを使用すると何が問題になるのかということです。私に言われたポイントの1つのように、異なる順序で関数を呼び出した結果は確定的ではありません。 関数プログラミングで可変オブジェクトを使用すると何がうまくいかないかが非常に明白な実際の具体例を探しています。基本的にそれが悪いのであれば、オブジェクト指向や関数型プログラミングのパラダイムに関係なく悪いのですよね？ 私自身の声明自体がこの質問に答えると思います。それでももっと自然に感じられるように、いくつかの例が必要です。 OOは、カプセル化、ポリモーフィズムなどのツールを使用して、依存関係を管理し、より簡単で保守可能なプログラムを作成するのに役立ちます。 関数型プログラミングも、保守可能なコードを促進する同じ動機がありますが、OOツールとテクニックを使用する必要性を排除するスタイルを使用しています。

9 c#  object-oriented  programming-practices  functional-programming  immutability 

私がこのような長い方法を持っているとしましょう： public void SomeLongMethod() { // Some task #1 ... // Some task #2 ... } このメソッドには、個別のメソッドまたはローカル関数に移動する必要がある繰り返し部分はありません。 長いメソッドはコードのにおいだと思っている人はたくさんいます（私を含めて）。また、私は#regionここで（s）を使用するのが好きではありません。なぜこれが悪いのかを説明する非常に人気のある答えがあります。 しかし、このコードをメソッドに分割すると public void SomeLongMethod() { Task1(); Task2(); } private void Task1() { // Some task #1 ... } private void Task2() { // Some task #1 ... } 次の問題が発生します。 単一のメソッドによって内部的に使用される定義でクラス定義スコープを汚染しているため、どこかに文書化する必要がTask1あり、そのTask2内部のみを対象としてSomeLongMethodいます（または、私のコードを読むすべての人がこのアイデアを推測する必要があります）。 単一のSomeLongMethodメソッド内で一度だけ使用されるメソッドの汚染IDEオートコンプリート（Intellisenseなど）。 このメソッドコードをローカル関数に分離すると …

9 c#  refactoring  functions  methods 

ユーザー入力を解析する場合、例外をスローしてキャッチするのではなく、検証メソッドを使用することをお勧めします。.NET BCLでは、これは、たとえばint.Parse（無効なデータで例外をスローする）とint.TryParse（false無効なデータで戻る）の違いになります。 私は自分でデザインしています Foo.TryParse(string s, out Foo result) メソッドと私は戻り値がわからない。bool.NET独自のTryParseメソッドのように使用することもできますが、エラーのタイプ、つまりに解析できなかった正確な理由について sはわかりませんFoo。（たとえば、s括弧Barが一致していない、文字数が間違っている、対応するがないBazなど） APIのユーザーとして、操作が失敗した理由を通知せずに成功/失敗のブール値を返すだけのメソッドは嫌いです。これにより、推測ゲームのデバッグが可能になり、ライブラリのクライアントにもそれを課したくありません。 私はこの問題の多くの回避策（ステータスコードを返す、エラー文字列を返す、エラーパラメータを出力パラメーターとして追加する）を考えることができますが、それぞれに欠点があり、また、 .NET Frameworkの。 したがって、私の質問は次のとおりです。 （a）例外をスローせずに入力を解析し、（b）単純なtrue / falseブール値よりも詳細なエラー情報を返す.NET Frameworkのメソッドはありますか？

9 c#  .net  api-design 

データベースのISessionContext、ログ用のILogManager、および別のサービスとの通信に使用されるIServiceを必要とする多くのコアクラスがあります。すべてのコアクラスで使用されるこのクラスに依存性注入を使用したい。 2つの可能な実装があります。3つのクラスすべてのIAmbientContextを受け入れるか、3つのクラスすべてのクラスに注入するコアクラス。 public interface ISessionContext { ... } public class MySessionContext: ISessionContext { ... } public interface ILogManager { } public class MyLogManager: ILogManager { ... } public interface IService { ... } public class MyService: IService { ... } 最初の解決策： public class AmbientContext { private ISessionContext sessionContext; private ILogManager …

9 c#  dependency-injection 

ASP.Net Coreでは、Claims認証は具体的な方法ではないことがわかりました。我々は、何も追加することができますClaimTypeし、ClaimValueペアを。groups、firstname、lastname、brithdate、canAccessThisURI、isEditorなどです。ただし、この方法（クレームとして保存できるものはすべて保存）では、アプリケーションデータの50％を含む巨大なクレームテーブルが作成されます。 良い方法として、クレームとして保存する必要がある一般的なデータは何ですか？

9 c#  .net  identity  asp.net-core  .net-core 

でブログ記事のこのシリーズ、エリックリッペルトは、ウィザードとの例として、戦士を使用して、オブジェクト指向設計における問題点を説明します。 abstract class Weapon { } sealed class Staff : Weapon { } sealed class Sword : Weapon { } abstract class Player { public Weapon Weapon { get; set; } } sealed class Wizard : Player { } sealed class Warrior : Player { } 次に、いくつかのルールを追加します。 戦士は剣しか使用できません。 ウィザードはスタッフのみを使用できます。 次に、C＃型システムを使用してこれらのルールを適用しようとすると発生する問題（たとえばWizard、ウィザードがスタッフのみを使用できることをクラスに責任を持たせるなど）を示します。Liskov置換原則に違反したり、ランタイム例外のリスクを冒したり、拡張が困難なコードを作成したりする。 …

9 c#  design-patterns  object-oriented  solid 

最近、私が使用するいくつかの大きなC＃コードベースの周りに浮かぶいくつかのヘルパースタイルの「ユーティリティバッグ」静的クラスを確認していました。 // Helpers.cs public static class Helpers { public static void DoSomething() {} public static void DoSomethingElse() {} } 私がレビューした特定の方法は 主に互いに無関係です 呼び出し間で持続する明示的な状態なしで、 小さい、そして それぞれが、関連のないさまざまなタイプによって消費されます。 編集：上記は申し立てられた問題のリストを意図したものではありません。これは、私が検討している特定のメソッドの一般的な特性のリストです。回答がより関連性の高いソリューションを提供するのに役立つコンテキストです。 この質問のためだけに、この種のメソッドをGLUM（一般的な軽量ユーティリティメソッド）と呼びます。「glum」の否定的な意味合いは部分的に意図されています。これが馬鹿げた言い回しとして出くわしたらすみません。 GLUMについての私自身のデフォルトの懐疑論はさておき、私はこれについて以下のことを好きではありません。 静的クラスは名前空間としてのみ使用されています。 静的クラス識別子は基本的に無意味です。 新しいGLUMが追加されると、（a）この「バッグ」クラスは理由もなく触れられるか、または（b）新しい「バッグ」クラスが作成されます（通常、それ自体は問題ではありません。悪いのは、新しい静的クラスは多くの場合、無関係な問題を繰り返すだけですが、メソッド数は少なくなります）。 メタ命名は、それはだかどうか、必然的に、ひどい非標準、通常は内部的に矛盾しているHelpers、Utilitiesまたは何でも。 これをリファクタリングするための合理的に良い＆単純なパターンは何ですか？ 私はおそらく強調する必要があります：私が扱っているすべての方法は、互いにペアで関係がありません。それらをよりきめ細かく、それでもマルチメンバーの静的クラスのメソッドバッグに分解するための合理的な方法はないようです。

9 c#  design-patterns 

新しいソフトウェア開発プロジェクトでStructureMapを使用しています。チームメンバーの1人が、基本的にStructureMapコンテナー構成をテストする単体テストを実装しました。これを行うには、次のようにします。 アプリケーションの名前空間のクラスに構成されているアセンブリのインスタンスの数をカウントします。 クラスレベルで予期されるインスタンスを定義します 予想されるインスタンスが見つかったインスタンスの総数と一致することを表明します。 予想されるインスタンスがテストで定義されたインスタンスと一致することを表明する この例は次のとおりです。 var repositories = container.GetAllInstances<IEnvironmentRepository>(); Assert.AreEqual(1, repositories .Count()); foundInstances = foundInstances + repositories .Count(); 次のクラスの「単体テスト」もあります。 public MyClass(IEnvironmentRepository environmentRepository) { } これらのテストでは、IEnvironmentRepositoryをモックしているため、ライブシステムで発生するようなコンテナーからの注入は行いません。 同僚は、「ユニットテストはそれ自体の構成のみをテストする」というコメントを付けて、structuremap configのユニットテストを無視しました。これは明らかにテストの目的であり、私の意見では完全に有効です。テストを無視した人に構造テストの構成を削除してIEnvironmentRepository（テストはまだ無視されています）、完全な単体テストスイートを実行するように依頼したところ、すべて成功しました。次に、アプリケーションを実行しましたが、コンテナー構成が無効になったため、アプリケーションが倒れました。私の意見では、これはテストの価値を証明しました、私の同僚はまだ反対しました。彼は単に構成をテストするべきではないと述べましたが、これは単体テストの範囲内であると私は思います。 したがって、いくつかの質問があります。 それは有効な単体テストですか？ストラクチャマップが機能するのではなく、コンテナの構成をテストしています（ただし、重複が確認できます） そうでない場合、テストせずに構成を検証するにはどうすればよいですか。誰かが誤って必要なコード行を削除してチェックインしないようにするにはどうすればよいですか？ なければならないMyClassユニットテストは、のインスタンスを解決IEnvironmentRepositoryコンテナからとでこれを渡しますか？

9 c#  unit-testing 

問題 私は最近、シングルトンが悪いことと、依存性注入（「インターフェースを使用する」と理解しています）がどのように優れているかについて、多くのことを読みました。コールバック/インターフェース/ DIを使用してこの一部を実装し、インターフェース分離の原則に準拠した場合、結局は混乱しました。 基本的にそのすべての子の依存関係を組み合わせたUI親の依存関係。したがって、UI要素が階層の上位にあるほど、そのコンストラクターは肥大化していました。 UI階層の最上位にあるのはApplicationクラスで、現在の選択に関する情報と、変更を反映する必要のある3Dモデルへの参照を保持していました。アプリケーションクラスは8つのインターフェイスを実装していましたが、これは製品（/インターフェイス）の5分の1に過ぎません。 私は現在、現在の選択を保持するシングルトンと、自分自身を更新する機能を持つUI要素を使用しています。この関数は、UIツリーとUI要素を細流化し、必要に応じて現在の選択シングルトンにアクセスします。コードはこのように私にはきれいに見えます。 質問 このプロジェクトにはシングルトンが適切でしょうか？ そうでない場合、私の考えやDIの実装に根本的な欠陥があり、それが非常に煩雑になりますか？ プロジェクトに関する追加情報 タイプ：ベルとホイッスル付きのアパートメントのショッピングバスケット サイズ：コードとUIに2か月/月 メンテナンス：実行中の更新はありませんが、後で「バージョン2.0」になる可能性があります 環境：エンティティを使用するUnityでC＃を使用コンポーネントシステム ほとんどすべての場合、ユーザーの操作によっていくつかのアクションがトリガーされます。たとえば、ユーザーがアイテムを選択したとき そのアイテムとその説明を表示するUIパーツを更新する必要があります。このため、価格を計算するために、3Dモデルから情報を取得する必要もあります。 UIをさらに上に行くと、全体の合計価格を更新する必要があります 3dモデルのクラスの対応する関数を呼び出して、そこに変更を表示する必要があります

9 c#  dependency-injection  singleton 

私たちは多くのユニットテストとビジネスオブジェクトのリファクタリングを行っており、クラスの設計について他のピアとは非常に異なる意見を持っているようです。 私がファンではないクラスの例： public class Foo { private string field1; private string field2; private string field3; private string field4; private string field5; public Foo() { } public Foo(string in1, string in2) { field1 = in1; field2 = in2; } public Foo(string in1, string in2, string in3, string in4) { field1 = …

9 c#  object-oriented-design  class-design  class 

浮動小数点値が等しいかどうかを比較する場合、2つの異なる方法があります。 NaN一致する、それ自体に等しくないIEEE 754仕様。 NaN等価関係の定義に不可欠な反射性の数学的特性を提供する、それ自体に等しい C＃（にIEEE浮動小数点型に内蔵floatし、doubleIEEEのためのセマンティクス従う）==及び!=（等リレーショナル演算子<）が、ための反射性を確保しobject.Equals、IEquatable<T>.Equals（およびCompareTo）。 ここで、float/の上にベクター構造体を提供するライブラリについて考えますdouble。このようなベクトル型は過負荷になり==/ !=およびオーバーライドobject.Equals/ IEquatable<T>.Equals。 何皆に同意すると、そのある==/ !=IEEEセマンティクスに従ってください。問題は、そのようなライブラリーがEquals再帰的な方法で、またはIEEEセマンティクスに一致する方法で（等価演算子とは別の）メソッドを実装するかどうかです。 のIEEEセマンティクスを使用するための引数Equals： IEEE 754に準拠 SIMD命令を利用できるため、（おそらくはるかに）高速です。 私は、スタックオーバーフローについて、SIMD命令を使用して再帰的等式をどのように表現するか、およびそれらのパフォーマンスへの影響について、別の質問をしました。浮動小数点の等値比較のためのSIMD命令 更新： 3つのSIMD命令を使用して効率的に再帰的等式を実装できるようです。 のドキュメントでEqualsは、浮動小数点を使用する場合に再帰性は必要ありません。 次のステートメントは、Equals（Object）メソッドのすべての実装に当てはまる必要があります。リストには、x、y、およびznullではないオブジェクト参照を表します。 x.Equals(x)true浮動小数点型を含む場合を除いて、を返します。ISO / IEC / IEEE 60559：2011、情報技術-マイクロプロセッサシステム-浮動小数点演算を参照してください。 floatを辞書のキーとして使用している場合は、罪の状態にあり、正常な動作を期待するべきではありません。 再帰的であるという主張： それはを含む既存のタイプと一致だSingle、Double、TupleとSystem.Numerics.Complex。 Equals再帰的ではなく、IEEEに従うBCLの前例は知りません。カウンターの例としてはSingle、Double、TupleとSystem.Numerics.Complex。 Equals主に、反射性に依存するコンテナと検索アルゴリズムで使用されます。これらのアルゴリズムでは、動作を妨げる場合、パフォーマンスの向上は重要ではありません。パフォーマンスの正確さを犠牲にしないでください。 これは、すべてのハッシュベースのセットや辞書、壊れるContains、Find、IndexOfさまざまなコレクション/ LINQ、セットベースのLINQの操作（上Union、Exceptデータが含まれている場合など）NaNの値を。 IEEEセマンティックが受け入れられる実際の計算を行うコードは、通常、具象型で機能し、==/ !=（またはより可能性の高いイプシロン比較）を使用します。 ジェネリック演算が必要なため、現在ジェネリックを使用して高性能計算を作成することはできませんが、これらはインターフェース/仮想メソッドを介して利用できません。 したがって、遅いEqualsメソッドはほとんどの高性能コードに影響を与えません。 IEEEセマンティクスが必要な場合、またはパフォーマンス上の利点が必要な場合に、IeeeEqualsメソッドまたはを提供するIeeeEqualityComparer<T>ことができます。 私の意見では、これらの議論は再帰的な実装を強く支持しています。 MicrosoftのCoreFXチームは、そのようなベクトル型を.NETに導入することを計画しています。私とは異なり、彼らは主にパフォーマンス上の利点のために、IEEEソリューションを好みます。このような決定は最終リリース後も変わらないので、大きな間違いだと私が信じていることについてコミュニティからフィードバックを得たいと思います。

9 c#  .net  math  floating-point 

プロジェクトに元に戻すとやり直しを実装するためにコマンドパターンを使用しようとしました public abstract class Command { protected Form Receiver { set; get; } protected HtmlElement Element { set; get; } abstract public void ReDo(); abstract public void UnDo(); public Command(Form receiver) { this.Receiver = receiver; } } class AddElementCmd : Command { public AddElementCmd(HtmlElement elem, Form receiver) : base(receiver) { …

9 c#  design-patterns 

このコードは、簡略化すると次のようになります。 public class Room { public Client Client { get; set; } public long ClientId { get { return Client == null ? 0 : Client.Id; } } } public class Client { public long Id { get; set; } } 現在、3つの視点があります。 1）Clientプロパティは常に設定される必要があるため（つまりnullではない）、これは適切なコードでClient == nullあり、Id値0は偽のIDを示します（これはコードの作成者の意見です;-)） 2）が0偽の値であることを呼び出し元に依存することはできません。Idまた、 Clientプロパティを常に設定する必要exceptionがあるget場合は、Clientプロパティがnullになったときにをスローする必要があります。 3）Clientプロパティを常に設定する必要がある場合は、プロパティがたまたまnullの場合に戻りClient.Id、コードにNullRef例外をスローさせClientます。 これらのうちどれが最も正しいですか？または、4つ目の可能性はありますか？

9 c#  code-quality  null 

私はこの興味深い記事に出くわしました：CodeProjectでのCOM相互運用性が好きになりました。 著者は、.NETライブラリの美しさを損なうため、.NETライブラリにCOM-ityを必要としないと主張しています。代わりに、.NETライブラリをCOMに公開する個別の相互運用ライブラリを作成します。この相互運用ライブラリは、COMがパラメーター、オーバーロードメソッド、ジェネリックス、継承、静的メソッドなどのコンストラクターをサポートしていないという事実を処理します。 そして、それは非常に斬新なことだと思いますが、それだけでプロジェクトを完成させるのではないですか？ 次に、.NETライブラリとInteropライブラリを単体テストする必要があります。 次に、美しい.NETライブラリを回避してCOMに公開する方法を理解するために時間を費やす必要があります。 クラス数を効果的に2倍または3倍にする必要があります。 COMと非COMの両方をサポートするためにライブラリが必要かどうかは確かに理解できます。ただし、COMのみを使用する場合、この種の設計は私には見られない利点をもたらしますか？C＃言語の利点しか得られませんか？ または、ラッパーを提供することでライブラリのバージョン管理を容易にしますか？COMを使用する必要がないため、単体テストの実行が速くなりますか？

9 c#  interoperability  com 

モデルに（EFを使用して）さまざまなエンティティがあるとします（ユーザー、製品、請求書、注文など）。 エンティティが事前に決定されたセットに属しているアプリケーションでエンティティオブジェクトの要約を印刷できるユーザーコントロールを作成しています。この場合、ユーザーと製品の要約を要約できると言います。 要約にはすべてIDと説明しか含まれないため、このための簡単なインターフェースを作成します。 public interface ISummarizableEntity { public string ID { get; } public string Description { get; } } 次に、問題のエンティティについて、このインターフェイスを実装する部分クラスを作成します。 public partial class User : ISummarizableEntity { public string ID { get{ return UserID.ToString(); } } public string Description { get{ return String.Format("{0} {1} is from {2} and is …

9 c#  design-patterns  interfaces  anti-patterns  data-types