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

メタ手法。これにより、依存型の設定をランタイムに移すことができます。

5
C#のジェネリック型の適切な命名規則は何ですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 かなり主観的であるため、スタックオーバーフローではなく、ここでこの質問をすることにしました。 C#では、通常、非常に貧弱な名前のジェネリック型が表示されます。特に、「T」は一般的に使用されますが、それ自体では意味のある名前ではありません。例えば: class Fruit<T> { T fruit; } これは典型的なアプローチですが、これに反対する人はいますか?もしそうなら、一般的な関数とクラスのC#のコンテキストでの一般的な型の合理的な命名規則は何でしょうか? 前の例では、ジェネリック型Tは常にAppleor などの果物の型である必要があると仮定しましょうOrange。タイプは、Tそれは明らかに、それは果物の種類だことを確認する必要があるので、多分、より良い名前のようになりFruitType、我々はで終わるので、: class Fruit<FruitType> { FruitType fruit; } これは、皆さんに私が探しているもののアイデアを提供するためのものです。この問題で受け入れられる「経験則」とは何ですか?
16 c#  naming  generics 

3
インターフェースを使用する理由と一般的に制約されたタイプを使用する理由は何ですか
ジェネリック型パラメーター(クラステンプレート、およびパラメーターポリモーフィズムとも呼ばれますが、それぞれの名前には異なる意味があります)をサポートするオブジェクト指向言語では、多くの場合、型パラメーターに型制約を指定して、それを降順にすることができます別のタイプから。たとえば、これはC#の構文です。 //for classes: class ExampleClass<T> where T : I1 { } //for methods: S ExampleMethod<S>(S value) where S : I2 { ... } これらのインターフェースによって制約されるタイプよりも実際のインターフェースタイプを使用する理由は何ですか?たとえば、メソッドシグネチャを作成する理由は何I2 ExampleMethod(I2 value)ですか?

3
なぜファーストクラスのコレクションを使用する必要があるのですか?
The ThoughtWorks AnthologyのJeff Bay (RTF)によるObject Calisthenicsの規則4に従って、「ファーストクラスのコレクションを使用する」ことをお勧めします。 ルール4:ファーストクラスコレクション このルールの適用は簡単です。コレクションを含むクラスには、他のメンバー変数を含めないでください。各コレクションは独自のクラスにラップされるため、コレクションに関連する動作にはホームがあります。フィルタがこの新しいクラスの一部になることがあります。また、新しいクラスは、2つのグループを結合したり、グループの各要素にルールを適用するなどのアクティビティを処理できます。 これから理解できるのは、コレクションをラップアップする別のクラスを使用し、そのコレクションのデータを追加、削除、変更するメソッドを使用する必要があるということです。 そして、どのデータ型がコレクションに入れられ、何が出てくるかを確認するためにこれが必要です。 (適用可能な言語で)ジェネリックコレクションを使用する場合、この規則に従う必要がありますか? 重要な意味が欠けている場合は、明確にしてください。

2
型自体の代わりに、型制約のあるジェネリックメソッドを使用するのはなぜですか?
別のStackExchangeの質問で、このプロトタイプを使用している人に気付きました。 void DoSomething<T>(T arg) where T: SomeSpecificReferenceType { //Code.... } 型の制約は1つだけであることに注意してください(SomeSpecificReferenceType)。単純にではなく、そのように記述することの違いと利点は何ですか? void DoSomething(SomeSpecificReferenceType arg) { //Code.... } どちらの場合も、argコンパイル時の型チェックの対象となります。どちらの場合も、メソッドの本体は、argコンパイル時に認識されている特定の型の(またはその子孫である)知識に安全に依存できます。 これは、熱心な開発者が通常の継承について学ぶ前にジェネリックについて学ぶ場合ですか?または、メソッドシグネチャがこのように記述される正当な理由がありますか?
14 c#  .net  generics 

4
IDEが非常に賢い場合、「clone()」をキャストする必要があるのはなぜですか?
コードを入力している間、IDE(NetBeans)タイプがチェックしCollectionsます。しかし、その後、返されたオブジェクトをキャストする必要があるのはなぜObject.clone()ですか?大丈夫です。害もファウルもありません。しかし、それでも理解できません。 型チェックは、キャストせずに、返されたオブジェクトをObject.clone()不可能ですか?ジェネリックフレームワークは、私はIDEがチェックできると思いますタイプ「の右側のオブジェクト参照の=私はタイピングをしていながら、キャストなし」マークを?わかりません。 補遺 私の使用例は、私がプライベートCalendarフィールドpubdateを持っていたことだけでした。私は書くつもりでした: Calendar getPubdate() { return pubdate; } しかし、呼び出し側がpubdateを変更する可能性があるため、コピーを返しました。 Calendar getPubdate() { return (Calendar) pubdate.clone(); } 次に、なぜキャストする必要があるのか​​疑問に思いましたpubdate.clone()。メソッドシグニチャにはタイプがあります。NetBeansはそれを理解できるはずです。そしてNetBeansはに関して同様のことをしているようCollectionsでした。

1
なぜより高い種類が必要なのですか?
いくつかの言語は、(例えば、型パラメータを持つクラスおよび機能を可能にするList<T>場合T、任意のタイプであってもよいです)。たとえば、次のような関数を使用できます。 List<S> Function<S, T>(List<T> list) ただし、一部の言語では、この概念を1レベル上に拡張して、署名付きの機能を使用できます。 K<S> Function<K<_>, S, T>(K<T> arg) K<_>それ自体がそのような型である場合List<_>、型パラメーターがあります。この「部分型」は、型コンストラクターとして知られています。 私の質問は、なぜこの能力が必要なのですか?List<T>すべてList<T>がほぼ同じであるが、すべてK<_>が完全に異なる可能性があるため、次のような型を持つことは理にかなっています。共通の機能をまったく持たないOption<_>とを持つことができますList<_>。

1
汎用プログラミングの言語としてのScala
ガルシアらによる論文「汎用プログラミングのための言語サポートの拡張比較研究」。汎用プログラミングのプログラミング言語機能の興味深い比較を示します。 用語の簡単な説明: 誰でもこのフレームワーク内で汎用プログラミングのScalaサポートをテストできますか?つまり、可能であれば説明付きの最初の表に列を追加します。

7
インターフェース設計でジェネリックを使用する場合
サードパーティが将来実装する予定のインターフェイスがいくつかあり、自分で基本実装を提供します。例を示すためにカップルを使用するだけです。 現在、それらは次のように定義されています 項目: public interface Item { String getId(); String getName(); } ItemStack: public interface ItemStackFactory { ItemStack createItemStack(Item item, int quantity); } ItemStackContainer: public interface ItemStackContainer { default void add(ItemStack stack) { add(stack, 1); } void add(ItemStack stack, int quantity); } 今、ItemそしてItemStackFactory私は、将来それを拡張する必要のあるサードパーティを絶対に予測することができます。ItemStackContainer将来的に拡張することもできますが、提供されているデフォルトの実装以外では、予測できる方法では拡張できません。 今、私はこのライブラリを可能な限り堅牢にしようとしています。これはまだ初期段階(プレプレアルファ)であるため、これは過剰エンジニアリング(YAGNI)の行為である可能性があります。これはジェネリックを使用するのに適切な場所ですか? public interface ItemStack<T extends Item> { …
11 java  generics 

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

3
汎用プログラミング、業界で使用される頻度
現在、アカデミックな環境でプログラミングを行っているので、好きなものを使用できます。ブーストグラフライブラリをいくつかの目的に使用していますが、GPをより深く理解するための努力に投資する価値があるかどうか疑問に思っています。 私は興味があります-ジェネリックプログラミング(GP)は業界で多く使用されていますか?私の推測では、ほとんどのプログラマーはOOPにはるかに慣れているか、GPを強調またはサポートしていない言語を使用しているため、C ++でSTLデータ構造/関数を呼び出す以外に、GPはそれほど頻繁に使用されないという印象です実際には。しかし、現時点では業界の外にいるので、これについて実務家から聞いてうれしいです。 (私がこれを書いているとき、ジェネリックプログラミングは有効なタグではないことがわかりました!)

4
Javaでの複数の汎用インターフェースの実装
特定の署名を含む特定のメソッドが利用可能であることを保証するインターフェイスが必要です。これまでのところ、彼は私が持っているものです: public interface Mappable<M> { M mapTo(M mappableEntity); } この問題は、クラスを他の複数のエンティティにマップできる場合に発生します。理想的なケースはこれです(javaではありません): public class Something implements Mappable<A>, Mappable<B> { public A mapTo(A someObject) {...} public B mapTo(B someOtherObject) {...} } これを可能な限り「一般的な」ものにするための最良の方法は何でしょうか?
10 java  generics 


1
型パラメーターの型引数を推論する手法の名前は?
セットアップ:Iterator型パラメーターを持つと呼ばれる型があるとしましょうElement: interface Iterator<Element> {} 次に、をIterable返す1つのメソッドを持つインターフェースがありますIterator。 // T has an upper bound of Iterator interface Iterable<T: Iterator> { getIterator(): T } Iteratorジェネリックであることの問題は、型引数を指定する必要があることです。 これを解決する1つのアイデアは、イテレータのタイプを「推測」することです。次の疑似コードは、Elementへの型引数であると推定される型変数があるという考えを表していますIterator。 interface <Element> Iterable<T: Iterator<Element>> { getIterator(): T } そして、次のような場所で使用します。 class Vec<Element> implements Iterable<VecIterator<Element>> {/*...*/} このの定義は、その定義の他の場所ではIterable使用していませんElementが、実際の使用例では使用しています。を使用する特定の関数は、双方向のイテレータなど、特定の種類のイテレータのみを返すs Iterableを受け入れるようにパラメータを制約できる必要もあります。そのIterableため、返されるイテレータは要素タイプだけではなくパラメータ化されます。 質問: これらの推定された型変数の確立された名前はありますか?テクニック全体についてはどうですか?特定の命名法を知らないために、この例を実際に検索したり、言語固有の機能について学ぶことが困難になっています。 総称を持つすべての言語がこの手法を備えているわけではありません。これらの言語で同様の技術の名前はありますか?

3
Java Generics-表現力とシンプルさのバランスを取る方法
私はジェネリックスを利用するコードをいくつか開発しています。私の指針となる原則の1つは、今日だけでなく、将来のシナリオでも使用できるようにすることでした。ただし、いくつかの同僚は、拡張性のために読みやすさを犠牲にしている可能性があると述べています。これを解決するために考えられる方法についてフィードバックを集めたかったのです。 具体的には、ここに変換を定義するインターフェースがあります。まず、項目のソースコレクションから開始し、各要素に変換を適用して、結果を宛先コレクションに保存します。さらに、宛先のコレクションを呼び出し元に返すことができるようにしたいのですが、コレクションの参照を使用するように強制するのではなく、宛先のコレクションに実際に提供したコレクションの種類を使用できるようにしたいと思います。 最後に、宛先のコレクション内のアイテムのタイプが、ソースのコレクション内のアイテムのタイプと異なるようにすることができます。これは、おそらく変換が行うためです。たとえば、私のコードでは、変換後にいくつかのソース項目が1つの宛先項目を構成しています。 これにより、次のインターフェースが生成されます。 interface Transform<Src, Dst> { <DstColl extends Collection<? super Dst>> DstColl transform( Collection<? extends Src> sourceCollection, DstColl destinationCollection); } インターフェースを適切にスーパータイプとサブタイプで使用できるようにするために、私はすべてがうまくいってJosh BlochのPECS原則(プロデューサー拡張、コンシューマースーパー)を適用しようとしました。最終結果は幾分怪物です。 さて、このインターフェースを拡張して、どういうわけかそれを特化できればいいのですが。たとえば、ソースアイテムのサブタイプとデスティネーションアイテムのスーパータイプをうまく使用する必要がない場合は、次のようにします。 interface SimpleTransform<Src, Dst> { <DstColl extends Collection<Dst>> DstColl transform( Collection<Src> sourceCollection, DstColl destinationCollection); } しかし、Javaでそれを行う方法はありません。私はこのインターフェースの実装を、恐怖で走るのではなく、他の人が実際に行うことを検討するようなものにしたいと考えています。私はいくつかのオプションを検討しました: 宛先のコレクションを返さないでください。変換を実行しても何も返されないことを考えると、奇妙に思えます。 このインターフェイスを実装する抽象クラスがありますが、パラメーターを使いやすいものに変換し、より単純なシグネチャを持つ別のメソッド "translateImpl()"を呼び出します。これにより、実装者の認識の負担が少なくなります。しかし、インターフェイスをユーザーフレンドリーにするためだけに抽象クラスを作成しなければならないのは奇妙です。 拡張性を忘れ、よりシンプルなインターフェースを備えています。おそらく、それを宛先のコレクションを返さないことと組み合わせます。しかし、それは将来の私の選択肢を制限します。 どう思いますか?使用できるアプローチがありませんか?

1
Java APIでタイプ弁別子よりワイルドカードを好む理由(Re:Effective Java)
Blochの効果的なJavaのジェネリックセクション(誰でも簡単に利用できる「無料」の章:http : //java.sun.com/docs/books/effective/generics.pdf)で、彼は次のように述べています。 型パラメーターがメソッド宣言に1回だけ出現する場合は、ワイルドカードに置き換えます。 (そのPDFの31-33ページを参照してください) 問題の署名は次のとおりです。 public static void swap(List<?> list, int i, int j) 対 public static void swap(List<E> list, int i, int j) 次に、実際の型パラメーターを指定した静的なプライベート「ヘルパー」関数を使用して作業を実行します。ヘルパー関数のシグネチャは、2番目のオプションのシグネチャとまったく同じです。 とにかくワイルドカードを使用して作業を完了する必要がないので、なぜワイルドカードが望ましいのですか?この場合、彼はリストを変更していて、無制限のワイルドカードを使用してコレクションに追加できないので、なぜそれを使用するのですか?
8 java  generics 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.