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

基本クラスが純粋なインターフェイスクラスであることが望ましくないと仮定し、以下の2つの例を使用すると、抽象メソッドまたは仮想メソッドクラス定義を使用する方が適切なアプローチですか？ 「抽象」バージョンの利点は、見た目がきれいで、派生クラスに意味のある実装を強制的に提供させることです。 「仮想」バージョンの利点は、他のモジュールによって簡単に引き込められ、抽象バージョンが必要とするような基本的なフレームワークを追加することなくテストに使用できることです。 要約版： public abstract class AbstractVersion { public abstract ReturnType Method1(); public abstract ReturnType Method2(); . . public abstract ReturnType MethodN(); ////////////////////////////////////////////// // Other class implementation stuff is here ////////////////////////////////////////////// } 仮想バージョン： public class VirtualVersion { public virtual ReturnType Method1() { return ReturnType.NotImplemented; } public virtual ReturnType Method2() …

11 c#  design 

C＃でのOOPに関する「ベストプラクティス」の質問があります（ただし、すべての言語に当てはまります）。 たとえば、プロパティアクセサを介して、パブリックに公開されるオブジェクトを含むライブラリクラスを持つことを検討してください。 class A { // Note: List is just example, I am interested in objects in general. private List<string> _items = new List<string>() { "hello" } public List<string> Items { get { // Option A (not read-only), can be modified from outside: return _items; // Option B (sort-of read-only): …

11 c#  object-oriented 

私はC＃仕様を読んでいます。セグメントで説明を使用できます： C＃には統一型システムがあります。intやdoubleなどのプリミティブ型を含むすべてのC＃型は、単一のルートオブジェクト型を継承します。したがって、すべてのタイプは一連の共通操作を共有し、任意のタイプの値を一貫した方法で格納、転送、および操作できます。さらに、C＃はユーザー定義の参照型と値型の両方をサポートしているため、オブジェクトの動的な割り当てと軽量構造のインラインストレージが可能です。 この文脈で「軽量構造のインラインストレージ」とはどういう意味ですか？

11 c#  specifications 

私は何年もC＃とVB.NETの両方でプログラミングしましたが、主にVBでプログラミングしました。私はキャリアをC＃にシフトしていますが、全体的にはC＃の方が好きです。 しかし、私が抱えている問題の1つは、中括弧のスープです。VBでは、各構造キーワードに一致する近いキーワードがあります。次に例を示します。 Namespace ... Class ... Function ... For ... Using ... If ... ... End If If ... ... End If End Using Next End Function End Class End Namespace C＃で記述された同じコードは、非常に読みにくくなります。 namespace ... { class ... { function ... { for ... { using ... { if ... { …

11 c#  programming-practices 

複数の「スクリーン」を持つWinformアプリを構築する適切な方法は何ですか？たとえば、小さなバックアッププログラム（主に笑い用）を作成しようとしていますが、コントロールとコンテナーをフォームにダンプしています。 パネルとグループボックスを使用して異なる画面を分離しています（例：パネルを使用して[設定]ウィンドウのすべてのコントロールを保持し、別のパネルを使用して設定済みのすべての現在のバックアップを表示しています）。まあ、私のform.csファイルは膨大な量のコードに膨れ上がり、何か間違ったことをしているように感じます。ファイルにはほとんど何も見つかりません。最初からやり直す準備ができています。このプロジェクトは、私にとってC＃と.NETの知識を広げるためだけのものでした。そのため、新しいプロジェクトを開始することは大したことではありません。

11 c#  gui  winforms  gui-design 

コードをリファクタリングするときに、IDEをC＃クラスのusingセクションに移動し、未使用の名前空間と重複する名前空間を削除して、すべてを並べ替えました。 ペア（ペアプログラミング）が理由を尋ねました。なぜそうしたのか分かりませんでした。私はすべてのコードをきれいに整頓することを習慣からやった。つまり、よりクリーンなコードを作成することは一般的には良いアイデアであると言いましたが、もちろんその理由は正当な理由ではありませんでした。C＃コードページのusingセクションで時間を費やすことすらしません。 クラスまたは列挙（または一般に型）をあるネームスペースから別のネームスペースに移動することが多いため、コードに新しいusingステートメントを追加します（コードウィンドウを上に移動して自分でusingステートメントを記述するか、またはAlt+ Ctrl+のF10組み合わせを使用してエディタを介して）、これらの新しいusingステートメントはusingセクションの最後に追加され、アルファベット順にソートされず、コンパイラはこれらの問題のいずれにも不満を感じないため、なぜこれを行う必要があるのかセクションはきれいで整頓されていますか？どのような理由がありますか？

11 c#  programming-practices 

過去数年間で、私が使用したい言語はますます「機能的」になりつつあります。現在、C＃、F＃、Scalaなどの「ハイブリッド」言語を使用しています。ドメインオブジェクトに対応するクラスを使用してアプリケーションを設計し、これによりコーディングがより簡単に、より正確に、より安全になる機能機能を使用します（特にコレクションの操作時または関数の受け渡し時）。 ただし、パターンを設計する場合、2つの世界は「衝突」します。私が最近直面した具体的な例は、Observerパターンです。アイテムが作成または変更されたときに、プロデューサーに他のコード（「消費者/オブザーバー」、たとえばDBストレージ、ロガーなど）に通知してほしい。 私は最初に次のように「機能的に」それをしました： producer.foo(item => { updateItemInDb(item); insertLog(item) }) // calls the function passed as argument as an item is processed しかし、私は今、もっと「OO」アプローチを使用すべきかどうか疑問に思っています。 interface IItemObserver { onNotify(Item) } class DBObserver : IItemObserver ... class LogObserver: IItemObserver ... producer.addObserver(new DBObserver) producer.addObserver(new LogObserver) producer.foo() //calls observer in a loop 2つのアプローチの長所と短所はどれですか？かつてFPの第一人者が、デザインパターンは言語の制限のためだけにあると言ったことを聞いたことがあり、それが関数型言語にはほとんどない理由です。たぶん、これはその例でしょうか？ 編集：私の特定のシナリオでは、私はそれを必要としませんが、..機能的な方法で「観測者」の削除と追加をどのように実装しますか？（つまり、パターンのすべての機能をどのように実装しますか？）たとえば、新しい関数を渡すだけですか？

11 c#  functional-programming  scala  object-oriented-design  f# 

しばらくの間、C＃for WindowsおよびASP.net MVC開発で遊んでいます。しかし、私はまだいくつかの領域で不明です。私は、類似の種類のGeneric Collection Interfacesの使用と交換に関するパフォーマンスの問題の基本的な違いを理解しようとしています。 基本的な違いは何ですかIEnumerable<T>、ICollection<T>、List<T>(Class)？ アプリケーションで問題が発生することなく、それらを使用および交換しているようです。また、これらの3つと交換できるこれらのような類似の汎用コレクションはありますか？

11 c#  generics  interfaces 

Java（frameworks / ECOシステムなど）のすべての.net開発者をトレーニングする新しいプロジェクトを開始します。C＃で記述された多くのコードがあり、すべてJavaで書き直す必要があるため、これらはすべて無駄になるようです。私が見る問題は、最初の1年かそこら（おそらく2年）は以前のものが今はJavaであったものを再現するためにほとんどの時間を費やすため、何も提供できないことです。 私たちのチームは世界中のさまざまなオフィスに分散しており、多数のJava開発者（20から30）と10人の開発者が.netを使用しているため、すべての開発者が同じ言語/プラットフォームを使用して、コンポーネント/モジュールを再利用します。だから私は経営者の視点を理解できます。 昨日、Scalaに出会い、現在の製品（C＃で記述されている）でこれを使用する方が良いかどうか疑問に思っていました。少なくとも1年で機能する製品ができます。また、製品の他の部分を移行しながら、1年でJavaの世界で使用できるモジュールがあります。 私たちが達成しようとしていることを考えると、ScalaはJavaよりも良い選択でしょうか？

11 java  c#  scala 

現在の.NETプラットフォーム上に、おそらくSchemeインタープリターである動的言語コンパイラー/インタープリターを作成したいとしましょう。Dynamic Language Runtime（DLR）を使用するか、C＃4.0を使用して言語の動的機能を実装する方が良いでしょうか？または、両方が必要ですか？ 特にIronSchemeとIronPython に関して、この分野で他の作業が行われたことを知っています。これらの言語は両方ともDLRを使用します。IronPythonはDLRの最新バージョン（約1年前）を使用し、IronSchemeは初期バージョンのDLRの大幅に修正された初期のフォークを使用すると考えています。しかし、これらのコンパイラが作成されたとき、C＃4.0は利用できませんでした。 C＃4.0の動的な機能を使用したRob ConeryのMassiveでの作業を見てきました。とても印象的です。しかし、C＃は動的言語コンパイラ/インタープリターの本格的な努力に耐えるでしょうか？C＃にない機能がDLRにありますか、それともDLRは本質的にC＃4.0に組み込まれましたか？C＃4.0のみを使用した場合、DLRの重要な機能が失われますか？

11 c#  compiler  dynamic-typing 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 2002年にMicrosoftが.NET FrameworkとC＃言語を発表したとき、C＃を紹介した最初の記事は何でしたか？ 他の言語の必要性を説明し、背景を話し、コードサンプルを持っている可能性のある、MSDNまたはMicrosoftのWebサイトで公開されている論文を探しています。 また、一般的な.NET Frameworkドキュメントではなく、元のC＃の紹介に興味があります。 私がいることを覚えて、早期の.NET論文はかなり霧だったし、それが再読み込み、それらに楽しいの公正なシェアである一方で、私は言語を中心とした文書を目指します。

11 c#  microsoft  history  msdn 

私は依存関係の注入について学んでいるだけで、何かにこだわっています。依存性注入では、コンストラクターを介して依存クラスを送信することをお勧めしますが、これがデータオブジェクトに必要かどうかは疑問です。単体テストはDIの主な利点の1つであるため、データを格納するだけで、プロシージャを単体テストすることはなく、DIを不要な複雑なレイヤーにするデータオブジェクト、または依存関係の表示にも役立ちますデータオブジェクトで？ Class DO{ DO(){ DataObject2List = new List<DO2>(); } public string Field1; public string Field2; public List<DO2> DataObject2List; } Class DO2{ public DateTime Date; public double Value; }

11 c#  dependency-injection  class-design 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 ReSharper（C＃用）を使い始めたばかりで、そのコードがファインダの匂いを嗅ぐようなもので、かなり前に修正するつもりだった文章（主に可変命名規則）を示しています。 メソッドとインスタンス変数の命名規則のいくつかを再考することになりました。ReSharperは、インスタンス変数はラクダの小文字で、アンダースコアで始まることを提案しています。しばらくの間、すべてのローカル変数をキャメルケースの小文字にするつもりでしたが、アンダースコアが必要ですか？快適ですか？私はこのコンベンションが好きではありませんが、私はまだそれを試していません、それについてあなたはどう思いますか？ 再評価を促された2番目のことは、GUIイベントハンドラーの命名規則です。私は通常VS標準のControlName_Actionを使用し、コントロールは通常ハンガリー語表記を使用します（接尾辞として、ユーザーに見えるものと同様の名前の変数を処理する場合にないものをコードで明確にするため）。 ）、それについてあなたはどう思いますか？ReSharperコンベンションに屈するべきですか、それとも他の同等に有効なオプションがありますか？

11 c#  naming  resharper 

私の会社は最近、Visual Studio 用のAndroid向けMonoツールに投資しました。多くの.NET開発者がおり、monodroidツールの威力に感銘を受けました。ZDNetの投稿を読んだ後、このプロジェクトが死んでしまったのではないかと悲しくなりました。その記事にリストされているものよりもこれについてもっと知っているかもしれない誰かがそこにいますか？どうやら多数の開発者がモノプロジェクトから手放されたようですが、それが本当かどうか疑問に思っています。どんな情報も大歓迎です。私たちはEnterprise 5ライセンスを購入しましたが、これは非常に高価であり、このものを購入して学習し始めた後に消滅した場合、私はかなり怒ってしまいます！

11 c#  .net  monodroid 

プロパティと私の反論に対するいくつかの議論は次のとおりです。 getterおよびsetterメソッドを書くよりも使いやすい ゲッターメソッドとセッターメソッドのペアはコードのにおいです。これらの記述を簡単にすることは、Scantronフォームを使用してすべての「C」を入力することにより、数学テストに失敗しやすくするようなものです。永続化のために状態のみを含むオブジェクトは、getter / setterを使用してはならず、永続化時に不変オブジェクトを作成する必要があります。 オブジェクトのコンシューマーにとって重要なのは、オブジェクトが行う方法ではなく、オブジェクトが行うことです。その振る舞いはそれがすることです。その状態は、その方法です。オブジェクトの状態を気にかけている場合（永続性を除き、これもオブジェクト指向を破壊します）、OOPを実行せず、その利点を失います。 彼らは消費者にパフォーマンスの大まかな指標を与えます これは、特定のプロパティについて、将来変更される可能性があるものです。リリース1.0で、PropertyXにアクセスするとフィールドが返されるだけだとします。リリース1.5では、フィールドがnullの場合、PropertyXはNull Objectパターンを使用して新しいnullオブジェクトを作成します。リリース2.0では、PropertyXのgetterメソッドによってフィールドがさらに検証されています。 プロパティがますます複雑になるにつれて、プロパティを使用することによるパフォーマンスの指標はますます真実になりそうです。 パブリックフィールドよりも優れている これは本当です。しかし、メソッドもそうです。 これらはメソッドとは根本的に異なるオブジェクトの側面を表し、オブジェクトのすべてのコンシューマーはこれに注意する必要があります 上記のステートメントの両方が正しいと確信していますか？ 入力しやすいです 確かに、タイピングmyObject.Lengthはタイピングよりも簡単ですがmyObject.Length()、それを少しの構文糖で修正することはできませんか？ プロパティの代わりにメソッドを使用する理由 パフォーマンスの保証はありません。メソッドがより複雑になっても、APIは真実のままです。消費者は、パフォーマンスの問題に直面している場合、コードをプロファイルする必要があり、APIに依存しません。 消費者が考えることは少なくなります。このプロパティにはセッターがありますか？メソッドは確かにそうではありません。 消費者は適切なOOPの考え方から考えています。APIのコンシューマーとして、オブジェクトの動作と対話することに興味があります。APIでプロパティを見ると、状態によく似ています。実際、プロパティの実行が多すぎる場合は、プロパティであってはなりません。したがって、実際には、APIのプロパティはコンシューマに表示される状態です。 APIのプログラマは、戻り値を持つメソッドについてより深く考え、可能であれば、そのようなメソッドでオブジェクトの状態を変更することを避けます。可能な限り、コマンドをクエリから分離する必要があります。 それでは、なぜメソッドの代わりにプロパティを使用するのですか？MSDNのほとんどのポイントは、それ自体がコードの匂いであり、プロパティにもメソッドにも属していません。 （CQSについて考えた後、これらの考えが浮かびました。）

11 c#  object-oriented-design