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

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

4
不変フィールドのセッターを処理するにはどうすればよいですか?
2つのreadonly intフィールドを持つクラスがあります。プロパティとして公開されます: public class Thing { private readonly int _foo, _bar; /// <summary> I AM IMMUTABLE. </summary> public Thing(int foo, int bar) { _foo = foo; _bar = bar; } public int Foo { get { return _foo; } set { } } public int Bar { get { return …

3
C#の宣言型と同じ名前をプロパティ/メンバーに付けるのは悪い習慣ですか?
たとえば、次のようなクラス: class Dog { } //never mind that there's nothing in it... そして、次のようなプロパティ: Dog Dog { get; set; } もっと想像力に富んだ名前が思いつかない場合は、次を使用する必要があると言われました。 Dog DogObject { get; set; } これらの名前をより良くする方法についての考えはありますか?
25 c#  naming  properties 

5
多数の構造化構成/プロパティファイルを処理するためのベストプラクティス
多数のサーバーがあるシステムを想像してください。それぞれに多くの設定があります: サーバーに固有のもの 地域固有のいくつか それらすべてに共通するもの このグループのサーバーは読み取り専用であるように、カスタムグループを作成できます 等 私が念頭に置いている現在のプラクティスは、オーバーライド機能を持つ単純なプロパティ構造です。 例の目的でGoogleサーバーを使用してみましょう。それぞれにロードする設定のリストがあります。 たとえば、ロンドンのサーバーには次のものがあります。 rootsettings.properties、europesettings.properties、londonsettings.properties、searchengine.properties、など 各ファイルに一連のプロパティが含まれており、読み込みシーケンスを使用するとプロパティをオーバーライドできます。 たとえば、次のようにrootsettings.properties持っていることがありaccessible=false、デフォルトとして、しかしでオーバーライドされるsearchengine.propertiesとaccessible=true 私がこの構造で抱えている問題は、制御不能になるのが非常に簡単なことです。構造化されていないため、任意のレベルで任意のプロパティを定義でき、多くのアイテムが廃止される可能性があります。 さらに、ネットワークの成長に伴い、非常に多くのサーバーに影響を与えるため、中間レベルの変更は不可能になります。 最後に重要なことですが、個々のインスタンスにはそれぞれ1つの特別なプロパティが必要になる場合があります。つまり、ツリーは最終的に各サーバーの構成になり、最適なソリューションではなくなります。 より良い構成管理アーキテクチャの提案/アイデアがあれば、私は大歓迎です。

2
「計算された」値をプロパティまたはメソッドとして公開する必要がありますか?
Webコンテンツ管理システムのコンテンツタイプを表すC#クラスがあります。 Webコンテンツエディターがオブジェクトの表示方法のHTMLテンプレートを入力できるフィールドがあります。基本的に、オブジェクトプロパティ値をHTML文字列に代入するためにhandlebars構文を使用します。 <h1>{{Title}}</h1><p>{{Message}}</p> クラス設計の観点から、フォーマットされたHTML文字列(置換あり)をプロパティまたはメソッドとして公開する必要がありますか? プロパティとしての例: public class Example { private string _template; public string Title { get; set; } public string Message { get; set; } public string Html { get { return this.ToHtml(); } protected set { } } public Example(Content content) { this.Title = content.GetValue("title") as string; this.Message …

4
どのプロパティが値を変更し、どのプロパティが一定のままであるかが明確になるように、どのようにインターフェイスを設計しますか?
.NETプロパティに関する設計上の問題があります。 interface IX { Guid Id { get; } bool IsInvalidated { get; } void Invalidate(); } 問題: このインターフェイスには、2つの読み取り専用プロパティとがIdありIsInvalidatedます。ただし、それらが読み取り専用であるという事実は、それらの値が一定のままであることを保証するものではありません。 それを非常に明確にすることが私の意図だったとしましょう… Id 定数値を表します(したがって、安全にキャッシュできます)。 IsInvalidatedIXオブジェクトの存続期間中にその値を変更する可能性があります(したがって、キャッシュすべきではありません)。 interface IXその契約を十分に明確にするためにどのように変更できますか? 私自身の解決策の3つの試み: インターフェイスはすでに適切に設計されています。呼び出されたメソッドの存在Invalidate()により、プログラマは、同様の名前のプロパティの値IsInvalidatedが影響を受ける可能性があることを推測できます。 この引数は、メソッドとプロパティの名前が似ている場合にのみ有効です。 このインターフェースをイベントで拡張しますIsInvalidatedChanged: bool IsInvalidated { get; } event EventHandler IsInvalidatedChanged; の…Changedイベントの存在は、IsInvalidatedこのプロパティがその値を変更する可能性があることを示し、同様のイベントが存在しないことは、Idそのプロパティがその値を変更しないという約束です。 私はこのソリューションが好きですが、それはまったく使われないかもしれない追加のものがたくさんあります。 プロパティIsInvalidatedをメソッドに置き換えますIsInvalidated(): bool IsInvalidated(); これはあまりにも微妙な変更かもしれません。値は毎回新しく計算されるというヒントになるはずです-定数である場合は必要ありません。MSDNのトピック「プロパティとメソッドの選択」には、次のように書かれています。 次の状況では、プロパティではなくメソッドを使用してください。[…]パラメータが変更されていなくても、操作は呼び出されるたびに異なる結果を返します。 どのような答えが期待できますか? 私は、問題に対するまったく異なる解決策と、上記の試みをどのように打ち負かすかについての説明に最も興味があります。 私の試みが論理的に欠陥があるか、まだ言及されていない重大な欠点があり、解決策が1つしか残っていない(または何も残っていない)場合、どこで間違ったのかを聞きたいと思います。 欠陥が軽微であり、それを考慮した後、複数の解決策が残っている場合は、コメントしてください。 少なくとも、どちらがあなたの優先解決策であり、どのような理由であるかについてのフィードバックをお願いします。
12 c#  design  .net  properties 

7
OOPはプロパティの概念を含むようにどのように進化しましたか
私はC ++のバックグラウンドから来て、現在の仕事でC#を使い果たしており、パブリックフィールドとプロパティの違いと、このバリエーションと化身の前後の違いについて多くのQ&Aを読んでいます。基本的な質問(たとえば、このSO投稿と関連するすべてのリンクされた質問)。これらの質問はすべて、プロパティシステムの存在を当然とする実際的な違いの観点から説明されていますが、最初のプロパティをサポートすることを決めたすべての言語のデザイナーがこのテーマにアプローチするのは良いと思います場所は考えていました(Wikipediaの記事のリストをチェックしてください)。OOPはC ++ / Javaからどのように進化し、Wikipediaの記事で興味深いことにメソッドとメンバーデータの中間であると特定されました。 「つまり、プロパティはクラスのメンバーコード(メソッド)とメンバーデータ(インスタンス変数)の中間であり、プロパティはパブリックフィールドよりも高いレベルのカプセル化を提供します。」 MSDNはさらに背景を追加します。 「プロパティは技術的にはメソッドに非常によく似ていますが、使用シナリオの点ではまったく異なります。スマートフィールドと見なすべきです。フィールドの呼び出し構文とメソッドの柔軟性があります。」 カプセル化のこの中間レベルが一般的なプログラミングに有用であることが判明したことを知りたいと思います。この概念は、OOPパラダイムを表現したプログラミング言語の最初の化身には存在しなかったと思います。

2
JavaFX-ドメインオブジェクトでプロパティを使用する正しい方法
JavaFXには、javafx.beans.property.DoubleProperty自動的に監視および同期できるフィールドを定義できるなど、新しいPropertyオブジェクトがたくさん用意されています。 多くのJFXの例では、MVCモデルクラスにこれらのプロパティフィールドがいくつかあり、これらを自動的にビューにバインドできます。 ただし、これは、JFXプロパティをドメインオブジェクトに配置することを奨励しているようです(Modelクラスがドメインオブジェクトになると想定している場合)。これは、懸念の分離が不十分である(つまり、GUIコードをドメインに配置する)と思われます。 )。 この問題が「現実の生活」で解決されているのを見た人はいますか?

4
不変性を保証することは、プロパティではなくフィールドを公開する正当な理由ですか?
C#の一般的なガイダンスは、常にパブリックフィールドではなくプロパティを使用することです。これは理にかなっています。フィールドを公開することで、実装の詳細の多くを公開することになります。プロパティを使用すると、その詳細をカプセル化して、コードを消費しないようにし、実装の変更をインターフェイスの変更から切り離します。 ただし、readonlyキーワードを処理するときに、このルールに有効な例外が時々あるかどうか疑問に思っています。このキーワードをパブリックフィールドに適用すると、不変性が保証されます。これは単なる実装の詳細ではなく、不変性は消費者が関心を持つ可能性のあるものです。readonlyフィールドを使用すると、フィールドがパブリックコントラクトの一部になり、パブリックインターフェースを変更することなく、将来の変更または継承によって破壊されないものになります。プロパティが提供できないものです。 それでは、不変性を保証することが、readonly場合によってはプロパティよりもフィールドを選択する正当な理由でしょうか? (明確にするために、クラスの設計の一部として意味があり、契約に不変性を含めることが意図されている場合にのみ、現時点でフィールドが不変であるという理由だけで、常にこの選択を行うべきだと言っているわけではありません。私は主に、メンバーがにある必要があるinterface場合や遅延読み込みを行う場合など、正当化できない特定のケースではなく、これが正当化されるかどうかに焦点を当てた回答に関心があります。)

2
数字で始まる文字列を表す適切な名前付け
Windowsのいくつかのカメラメタデータを見るFile Propertiesと、(さらにいくつかの)2つのProperties名前付き焦点距離と35mm焦点距離があります。 私はこれら2つを利用するソフトウェアを開発していますProperties。これまでのところ、最初のProperty名前FocalLengthを作成しましたが、他の名前の適切な名前を見つけることができません。 私が考えている_35MmFocalLengthかThirtyFiveMmFocalLength、私はより良い提案があるかもしれないと思います。 何か案は?

2
ARCのプロパティ:常時またはパブリックのみ?
Robert McNallyによる「The Code Commandments:Best Practices for Objective-C Coding」という謙虚に名付けられた記事を2年ほど前に読んだ後、Objective-Cクラスのほとんどすべてのデータメンバーにプロパティを使用するという慣習を採用しました( 2012年5月の第3の戒め)。マクナリーはそうするためのこれらの理由をリストします(私の強調): プロパティはアクセス制限を強制します(読み取り専用など) プロパティはメモリ管理ポリシーを適用します(強い、弱い) プロパティは、カスタムセッターとゲッターを透過的に実装する機会を提供します。 カスタムセッターまたはゲッターを持つプロパティを使用して、スレッドセーフティ戦略を実施できます。 インスタンス変数にアクセスする単一の方法があると、コードが読みやすくなります。 私はほとんどの物件をプライベートカテゴリに分類しているので、1と4は通常、私が遭遇する問題ではありません。引数3と5はより「やわらかい」ものであり、適切なツールと他の一貫性があれば問題にならない可能性があります。最後に、私にとってこれらの議論の中で最も影響力があったのは、2番目のメモリ管理でした。それ以来、私はこれを続けています。 @property (nonatomic, strong) id object; // Properties became my friends. 最後のいくつかのプロジェクトでは、ARCを使用するように切り替えました。そのため、ほとんどすべてのプロパティを作成することは、それでも良いアイデアなのか、それとも少し不必要なのか疑問に思いました。ARCは、Objective-Cオブジェクトのメモリ管理を担当してくれます。ほとんどのstrongメンバーにとって、ivarを宣言するだけで問題なく機能します。とにかく、ARCの前後に手動で管理する必要があったCタイプであり、weakプロパティはほとんどパブリックプロパティです。 もちろん、クラスの外部からのアクセスが必要なものには、まだプロパティを使用していますが、ほとんどのプロパティはほんの一握りのプロパティであり、ほとんどのデータメンバーは、実装ヘッダーの下にivarとしてリストされています。 @implementation GTWeekViewController { UILongPressGestureRecognizer *_pressRecognizer; GTPagingGestureRecognizer *_pagingRecognizer; UITapGestureRecognizer *_tapRecognizer; } 実験として、私はこれをもう少し厳密に行っており、すべてのプロパティから離れると、いくつかの良い肯定的な副作用があります。 データメンバーコードの要件(@property/ @synthesize)は、ivar宣言だけに縮小されます。 私のself.something参照のほとんどは、ちょうどにクリーンアップされました_something。 プライベート(ivars)とパブリック(プロパティ)のデータメンバーは簡単に区別できます。 最後に、これはAppleがプロパティを意図した目的であるように「感じている」が、それは主観的な推測である。 質問に移ります。私は徐々にダークサイドに向かってスライドしており、implementation-ivarsを優先して、使用するプロパティを減らしています。すべてのプロパティを使用することに固執する必要がある理由について少し説明してください。または、必要な場合にのみivarを増やし、プロパティを減らす理由について、現在の一連の考えを確認してください。どちらか一方の最も説得力のある答えが私のマークを受け取ります。 編集:マクナリーはTwitterで、「プロパティにこだわる主な理由は、すべてを実行する1つの方法、すべてを実行する1つの方法(KVC / KVOを含む)だと思います」と言います。

3
プロパティが暗黙的にデリゲートに変換できないのはなぜですか
C#のプロパティは、実際の単純な古いメソッドにコンパイルされることは誰でも知っています。しかし、method(-group)とは異なり、Func<T>orまたはAction<T>(getterおよびsetter)のようなデリゲートを期待する他のメソッドへの引数としてそれらを与えることはできません。これを禁止する特別なものはありますか、それともメソッドグループをデリゲートに暗黙的に変換可能にするときに「無料」で提供されなかった機能だけですか? コード例: public class MyClass { public static int X { get; set; } } private static void Foo<T>(Func<T> f) { Console.WriteLine(f()); } private static void Bar<T>(Action<T> f) { f(default(T)); } private static void Test() { // neither of these lines compile, even with an explicit type-cast. Foo(MyClass.X); Bar(MyClass.X); } …

4
ささいな保護されたゲッターは過剰に露骨ですか?
私が以前に本当に考えたことがないもの(AS3構文): private var m_obj:Object; protected function get obj():Object { return m_obj; } private var m_str:String; protected function get str():String { return m_str; } 少なくともサブクラスはm_objまたはm_strを設定できません(ただし、m_objを変更することはできます)。 私の質問:これは単なる露骨なやりすぎですか? このプログラマーの質問: 単純にパブリックプロパティにするのではなく、クラスプロパティのゲッター/セッターをいつまたはなぜ使用する必要があるのでしょうか。 重複として提案されています。 その質問は、パブリックプロパティとプライベートプロパティのみを扱い、プロパティをゲッターとセッターでラップする必要があるかどうかという点で異なります。私の質問では、保護された変数と、継承するクラスがそれらの変数とどのように相互作用するかに焦点を当てています。 したがって、代替実装は次のようになります。 protected var m_obj:Object; //more accessible than a private variable with a protected getter protected var m_str:String; //more accessible than a …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.