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

私は通常、ほとんどのコード分析の警告に同意し、それらを順守しようとします。しかし、私はこれで苦労しています： CA1031：一般的な例外タイプをキャッチしない このルールの根拠を理解しています。しかし、実際には、スローされた例外に関係なく同じアクションを実行したい場合、それぞれを具体的に処理するのはなぜですか？さらに、特定の例外を処理する場合、呼び出しているコードが変更されて将来新しい例外がスローされるとどうなりますか？次に、その新しい例外を処理するためにコードを変更する必要があります。一方、単にExceptionコードをキャッチしただけなら、変更する必要はありません。 たとえば、FooがBarを呼び出し、FooがBarによってスローされた例外のタイプに関係なく処理を停止する必要がある場合、キャッチしている例外のタイプを特定することに利点はありますか？ たぶんより良い例： public void Foo() { // Some logic here. LogUtility.Log("some message"); } public static void Log() { try { // Actual logging here. } catch (Exception ex) { // Eat it. Logging failures shouldn't stop us from processing. } } ここで一般的な例外をキャッチしない場合は、可能なあらゆる種類の例外をキャッチする必要があります。パトリックには、OutOfMemoryExceptionこの方法で対処すべきでない良い点があります。では、例外をすべて無視したい場合はどうしOutOfMemoryExceptionますか？

57 c#  design  exceptions 

私は、チームリーダーがSOLID開発原則の熱心な支持者であるチームに取り組んでいます。しかし、彼は複雑なソフトウェアをドアから取り出すのに多くの経験を欠いています。 すでに非常に複雑なコードベースであったものにSRPを適用した状況があり、現在では非常に断片化されており、理解とデバッグが困難になっています。 現在、コードの断片化だけでなく、プライベートまたは保護されている可能性のあるクラス内のメソッドが「変更の理由」を表すと判断され、パブリックまたは内部クラスおよびインターフェースに抽出されているため、カプセル化にも問題がありますアプリケーションのカプセル化の目標に沿っていない。 20を超えるインターフェイスパラメーターを受け取るクラスコンストラクターがいくつかあるため、IoCの登録と解決はそれ自体が怪物になりつつあります。 これらの問題のいくつかを修正するために使用できる「SRPからのリファクタリング」アプローチがあるかどうかを知りたいです。私は、いくつかの密接に関連するクラスを「ラップ」してそれらの機能の合計への単一のアクセスポイントを提供する多数の空の粗いクラスを作成する場合、SOLIDに違反しないことを読んだ過度にSRPされたクラスの実装）。 それとは別に、誰もが幸せなまま、開発努力を実践的に続けることを可能にする解決策は考えられません。 助言がありますか ？

57 c#  wpf  inversion-of-control  single-responsibility 

個人的に、.NetでWeakReference型を使用する必要がある状況に遭遇したことはありませんが、一般的な信念は、キャッシュで使用する必要があるということです。博士ジョン・ハロップは、彼の中にキャッシュ内WeakReferencesの使用に対して非常に良いケース与えた答えにこの質問を。 また、AS3開発者がメモリフットプリントを節約するために弱い参照を使用することについて話すことをよく耳にしましたが、私が持っていた会話に基づいて、意図した目標を必ずしも達成することなく複雑さを追加するようであり、ランタイムの動作はかなり予測不可能です。そのため、多くの人は単純にそれをあきらめ、代わりにメモリ使用量をより慎重に管理する/コードを最適化してメモリ集約度を下げます（またはCPUサイクルを増やしてメモリフットプリントを小さくします）。 Jon Harrop博士はまた、.Net弱参照はソフトではなく、gen0には弱参照の積極的なコレクションがあると彼の答えで指摘しました。MSDNによると、長い弱参照はオブジェクトを再作成する可能性を与えてくれますbut the state of the object remains unpredictable.！ これらの特性を考えると、弱い参照が役立つ状況を考えることはできません。おそらく誰かが私を啓発できるでしょうか？

56 c#  .net  garbage-collection  weak-references 

Applicationクラスのインスタンス（エントリポイントを含む）でアプリケーションインスタンスを表すのではなく、（特に）JavaとC＃が静的メソッドをエントリポイントとして持つことにした理由について、プライマリソースまたはセカンダリソースからの明確な回答を探しています。適切なコンストラクタであること）。 私の以前の研究の背景と詳細 これは以前に尋ねられました。残念ながら、既存の回答は単に質問を懇願しているだけです。特に、次の答えは私を満足させるものではありません。 コンストラクターがオーバーロードされると、あいまいさが生じます。–実際、C＃（およびCとC ++）では異なる署名を使用できるMainため、同じ潜在的なあいまいさが存在し、対処されます。 staticこの方法は、その初期化の順序は明らかである前に、何のオブジェクトをインスタンス化することはできないことを意味します。–これは事実上間違っています。一部のオブジェクトは前にインスタンス化されます（静的コンストラクターなど）。 したがって、親オブジェクトをインスタンス化することなく、ランタイムによって呼び出すことができます。–これはまったく答えではありません。 なぜこれが有効で興味深い質問であると思うのかをさらに正当化するために： 多くのフレームワークは、クラスを使用してアプリケーションを表し、コンストラクターをエントリポイントとして使用します。たとえば、VB.NETアプリケーションフレームワークは、専用のメインダイアログ（およびそのコンストラクター）をエントリポイント1として使用します。 JavaもC＃も技術的にmainメソッドを必要としません。まあ、C＃をコンパイルするには1つが必要ですが、Javaでもそれは必要ありません。また、どちらの場合も実行には必要ありません。したがって、これは技術的な制限ではないようです。そして、最初の段落で述べたように、単なる慣習としては、JavaとC＃の一般的な設計原則に不自然に合わないようです。 明確に言うと、静的メソッドを使用することには特別な欠点はありません。それは明らかに奇妙です。そのため、技術的な根拠があるのではないかと思いました。main 私は単なる推測ではなく、一次または二次情報源からの決定的な答えに興味があります。 1ただし、Startupこれをインターセプトする可能性のあるコールバック（）があります。

54 java  c#  history  entry-point 

void構築可能でなく、ジェネリック型として許可されないことを支持して設計上の決定は何でしたか？結局それだけで特別な空であるstructと明確な持つの合計PITA避けているだろうFuncし、Actionデリゲートを。 （C ++は明示的なvoid戻り値を許可voidし、テンプレートパラメータとして許可します）

53 c#  .net  language-design 

TDD、特に開発の部分に頭を包み込もうとしています。私はいくつかの本を見てきましたが、私が見つけた本は主にテストの部分に取り組んでいます-NUnitの歴史、テストが良い理由、レッド/グリーン/リファクタリング、文字列計算機の作成方法。 良いものですが、それはTDDではなく「単なる」単体テストです。具体的には、テストを開始するためにデザインが必要な場合、TDDが優れたデザインを取得するのにどのように役立つか理解できません。 例として、次の3つの要件を想像してください。 カタログには製品のリストが必要です カタログは、ユーザーが閲覧した製品を記憶する必要があります ユーザーは製品を検索できる必要があります この時点で、多くの本は魔法のうさぎを帽子から引き出して「ProductServiceのテスト」に飛び込みますが、そもそもProductServiceがあるという結論に至った経緯については説明していません。それが私が理解しようとしているTDDの「開発」の部分です。 既存の設計が必要ですが、エンティティサービス以外のもの（つまり、Productがあるため、ProductServiceが必要です）はどこにも見つかりません（たとえば、2番目の要件では、ユーザーですが、思い出させる機能をどこに配置しますか？また、検索はProductServiceの機能または別のSearchServiceの機能ですか？どちらを選択すべきかをどのように知ることができますか？） SOLIDによると、UserServiceが必要になりますが、TDDなしでシステムを設計すると、単一メソッドサービスが大量に発生する可能性があります。TDDは、最初に自分のデザインを発見することを意図したものではありませんか？ 私は.net開発者ですが、Javaリソースも機能します。実際のビジネスアプリケーションを扱う実際のサンプルアプリケーションや本はないようです。TDDを使用して設計を作成するプロセスを示す明確な例を提供できますか？

50 java  c#  .net  tdd 

ここ数年、私たちは少しずつ一歩ずつ、より良い記述コードに徐々に切り替えてきました。私たちはついに、少なくともSOLIDに似たものへの切り替えを始めていますが、まだまだそこにはありません。切り替えを行って以来、開発者からの最大の不満の1つは、以前はすべてのタスクで開発者が5〜10個のファイルを操作するだけで十分だった数十個のファイルをピアレビューおよびトラバースできないことです。 切り替えを開始する前に、アーキテクチャは次のように編成されていました（1〜2桁以上のファイルが付与されています）。 Solution - Business -- AccountLogic -- DocumentLogic -- UsersLogic - Entities (Database entities) - Models (Domain Models) - Repositories -- AccountRepo -- DocumentRepo -- UserRepo - ViewModels -- AccountViewModel -- DocumentViewModel -- UserViewModel - UI ファイルに関しては、すべてが非常に線形でコンパクトでした。明らかにコードの重複、密結合、および頭痛の種がたくさんありましたが、誰もがそれを横断して理解することができました。完全な初心者、つまりVisual Studioを開いたことのない人は、わずか数週間でそれを理解できました。全体的なファイルの複雑さの欠如により、初心者の開発者や新規採用者も、あまり時間をかけずに貢献を始めることが比較的簡単になります。しかし、これはコードスタイルの利点が出てこないところです。 コードベースを改善するためのあらゆる試みを心から支持しますが、このような大規模なパラダイムシフトについて、チームの他のメンバーからプッシュバックを得るのは非常に一般的です。現在の最大のこだわりのポイントは次のとおりです。 単体テスト クラス数 ピアレビューの複雑さ ユニットテストは時間の無駄だと信じており、個々のコードよりも全体としてコードをはるかに迅速に処理テストできると信じているため、チームにとっては信じられないほど難しい販売でした。SOLIDの承認として単体テストを使用することはほとんど無益であり、この時点ではほとんど冗談になりました。 クラス数はおそらく克服すべき最大のハードルです。5〜10個のファイルを使用していたタスクは、70〜100個かかるようになりました。これらの各ファイルにはそれぞれ異なる目的がありますが、膨大な量のファイルが圧倒される場合があります。チームからの反応は、主にうめき声と頭を掻くものでした。以前は、タスクには1つまたは2つのリポジトリ、1つまたは2つのモデル、ロジックレイヤー、およびコントローラーメソッドが必要でした。 単純なファイル保存アプリケーションを構築するには、ファイルが既に存在するかどうかを確認するクラス、メタデータを書き込むクラスDateTime.Now、ユニットテストの時間を注入できるように抽象化するクラス、ロジックを含むすべてのファイルのインターフェイス、ファイルがあります各クラスの単体テストと、DIコンテナにすべてを追加するための1つ以上のファイルを格納します。 中小規模のアプリケーションの場合、SOLIDは非常に簡単に販売できます。誰もが保守性の利点と容易さを理解しています。ただし、非常に大規模なアプリケーションでは、SOLIDの価値提案が見られないだけです。だから私は、組織と管理を改善して、成長する痛みを乗り越える方法を見つけようとしています。 最近完了したタスクに基づいて、ファイルボリュームの例を少し強くしたいと思いました。ファイル同期要求を受信するために、新しいマイクロサービスのいずれかに機能を実装するタスクが与えられました。要求が受信されると、サービスは一連の検索とチェックを実行し、最終的にドキュメントをネットワークドライブと2つの個別のデータベーステーブルに保存します。 ドキュメントをネットワークドライブに保存するには、いくつかの特定のクラスが必要でした。 - …

50 c#  coding-style  dependency-injection  solid  single-responsibility 

誰かがすべてのメソッドの前に/// <summary>コメントブロック（C＃）を付けるべきだと言ったことがありますが、その 理由は説明しませんでした。 私はそれらを使い始め、それらが私をかなり悩ませるので、ライブラリと静的メソッドを除いてそれらの使用を止めました。それらはかさばり、更新するのをいつも忘れています。 /// <summary>コードでコメントブロックを使用する正当な理由はありますか？ 私は通常//、常にコメントを使用します/// <summary>。それは、私が考えていたブロックだけです。

49 c#  comments 

この質問は主観的なものですが、ほとんどのプログラマーがこれにどのようにアプローチしているかに興味がありました。以下のサンプルは擬似C＃ですが、これはJava、C ++、およびその他のOOP言語にも当てはまります。 とにかく、クラスでヘルパーメソッドを記述するとき、静的メソッドとして宣言し、ヘルパーメソッドで必要な場合はフィールドを渡すだけです。たとえば、以下のコードを考えると、メソッド呼び出し＃2を使用することを好みます。 class Foo { Bar _bar; public void DoSomethingWithBar() { // Method Call #1. DoSomethingWithBarImpl(); // Method Call #2. DoSomethingWithBarImpl(_bar); } private void DoSomethingWithBarImpl() { _bar.DoSomething(); } private static void DoSomethingWithBarImpl(Bar bar) { bar.DoSomething(); } } これを行う私の理由は、ヘルパーメソッドが実装を読み取らなくても、他のオブジェクトに副作用がある可能性があることを（少なくとも私の目には）明らかにするからです。この手法を使用するメソッドをすばやく理解できるため、デバッグに役立ちます。 あなたはどちらか好む独自のコードでやってそうするためのあなたの理由は何ですか？

48 java  c#  design  object-oriented  programming-practices 

一般的な質問ではありますが、C ++のような言語はコンストラクターの実行、メモリ管理、未定義の動作などに関して異なるセマンティクスを持っていることを知っているので、私のスコープはむしろC＃です。 誰かが私に興味深い質問をしましたが、それは私には簡単には答えられませんでした。 クラスのコンストラクターが終わりのないループ（つまり、ゲームループ）を開始できるようにするのは悪い設計と見なされるのはなぜですか（またはまったくそうではないのですか）。 これによって破られるいくつかの概念があります： 最小限の驚きの原則のように、ユーザーはコンストラクターがこのように動作することを期待していません。 ユニットテストは、このクラスを作成したり、ループを終了しないため挿入したりできないため、より困難です。 ループの終わり（ゲームの終わり）は、概念的にはコンストラクターが終了する時間であり、これも奇妙です。 技術的には、このようなクラスにはコンストラクター以外のパブリックメンバーがありません。これにより、理解が難しくなります（特に実装が利用できない言語の場合） そして、技術的な問題があります： コンストラクターは実際には終了しないため、GCで何が起こるのでしょうか？このオブジェクトは既にGen 0ですか？ このようなクラスから派生することは、不可能であるか、少なくとも非常に複雑です。これは、基本コンストラクターが決して返さないため そのようなアプローチでより明らかに悪いまたは不正な何かがありますか？

47 c#  architecture 

switchいくつかのケースを処理する構造があります。switch動作enumを組み合わせた値によって重複したコードの問題を提起しています： // All possible combinations of One - Eight. public enum ExampleEnum { One, Two, TwoOne, Three, ThreeOne, ThreeTwo, ThreeOneTwo, Four, FourOne, FourTwo, FourThree, FourOneTwo, FourOneThree, FourTwoThree, FourOneTwoThree // ETC. } 現在、switch構造は各値を個別に処理します。 // All possible combinations of One - Eight. switch (enumValue) { case One: DrawOne; break; case Two: DrawTwo; …

47 c#  switch-statement  goto 

C＃では、次のコードが有効です interface I{ int property{get;set;} } これは私には意味がありません。これは、インターフェースの最も重要な原則の1つ、つまり状態の欠如（つまり、フィールドなし）を破っているようです。プロパティは暗黙のプライベートフィールドを作成しませんか？それはインターフェースにとって本当に悪いことではないでしょうか？

47 c#  interfaces  properties 

だから、私は.Netで働いています。.Netでオープンソースプロジェクトを作成します。それに関する私の最大の問題の1つは、.Netではなく、その周辺のコミュニティとフレームワークに必要なことです。魔法のネーミングスキームと文字列は、すべてを行うための最良の方法として扱われているようです。大胆な発言ですが、見てください： ASP.Net MVC： Hello world route： routes.MapRoute( "Default", // Route name "{controller}/{action}/{id}", // URL with parameters new { controller = "Home", action = "Index", id = "" } // Parameter defaults ); これが意味することは、ASP.Net MVCが何らかの形でHomeControllerコードを検索するということです。どういうわけか、それの新しいインスタンスを作成してから、Index 明らかidに何らかのパラメーターで関数を呼び出します。そして、次のようなものがあります： RenderView("Categories", categories); ...or.. ViewData["Foobar"]="meh"; そして、XAMLにも同様のことがあります。DataContextオブジェクトとして扱われ、希望するタイプに解決されることを期待し、祈らなければなりません。DependencyPropertiesは、マジックストリングとマジックネーミング規則を使用する必要があります。そして、このようなもの： MyData myDataObject = new MyData(DateTime.Now); Binding myBinding = new Binding("MyDataProperty"); …

47 c#  .net  asp.net-mvc  static-typing  xaml 

（サービスロケーター）デザインパターンに関する記事を読みながら、コンストラクター注入と依存性注入という用語を見てきました。 コンストラクターインジェクションについてGoogleで検索した結果、結果が不明確だったため、ここでチェックインする必要がありました。 コンストラクター注入とは何ですか？これは特定の種類の依存性注入ですか？規範的な例は大きな助けになるでしょう！ 編集 1週間のギャップの後にこの質問を再訪すると、私がどれほど失われたかを見ることができます。コメント/修正してください。 コンストラクター注入とプロパティ注入は、依存性注入の2つのタイプです。

47 c#  dependency-injection 

static多くの言語のメンバーのキーワードは、そのメンバーにアクセスできるようにするためにそのクラスのインスタンスを作成しないことを意味します。ただし、クラス全体を作成する理由はありませんstatic。なぜ、私はクラスを作る必要があるときstatic？ クラスを作るとどんなメリットがありstaticますか？つまり、静的クラスを宣言した後も、インスタンス化せずにアクセスしたいすべてのメンバーを静的として宣言する必要があります。 これは、たとえば、Math開発者のコ​​ーディング方法に影響を与えることなく、クラスを（静的ではなく）通常と宣言できることを意味します。言い換えれば、クラスを静的または通常にすることは、開発者にとっては透過的です。

47 c#  class  static-keyword