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

列挙型(列挙型も)は、型の要素、メンバー、または列挙子と呼ばれる名前付きの値のセットで構成されるデータ型です。列挙子の名前は通常、言語で定数として動作する識別子であり、暗黙の順序で事前定義されていることがよくあります。

8
列挙型をDBに保存するのはなぜですか?
このように、DBに列挙型を保存する方法についてアドバイスを求める質問を数多く目にしました。しかし、なぜそうするのだろうか。したがってPerson、genderフィールドとGender列挙型を持つエンティティがあるとしましょう。次に、個人テーブルには列の性別があります。 正当性を強制する明白な理由に加えてgender、アプリケーションに既にあるものをマッピングするために余分なテーブルを作成する理由がわかりません。そして、私はその複製を持つことが本当に好きではありません。
69 database  enum 

7
C ++でビットフラグにスコープ付き列挙型を使用する
enum X : int(C#)と、またはenum class X : int(C ++ 11)の隠れた内部フィールド有するタイプであるintことは、任意の値を保持することができます。さらに、いくつかの定義済み定数がX列挙型で定義されています。列挙型を整数値にキャストしたり、その逆を行うことができます。これは、C#とC ++ 11の両方に当てはまります。 C#では、列挙型は個々の値を保持するためだけでなく、Microsoftの推奨に従って、フラグのビットごとの組み合わせを保持するためにも使用されます。このような列挙型は(通常、必ずしもそうではありませんが)[Flags]属性で装飾されています。開発者の生活を楽にするために、ビット単位の演算子(OR、ANDなど)がオーバーロードされているため、次のようなことが簡単にできます(C#)。 void M(NumericType flags); M(NumericType.Sign | NumericType.ZeroPadding); 私は経験豊富なC#開発者ですが、C ++をプログラミングしてから数日しか経っていないため、C ++の規約については知りません。C#で使用したのとまったく同じ方法でC ++ 11列挙型を使用する予定です。C ++ 11では、スコープ付き列挙型のビット演算子はオーバーロードされないため、それらをオーバーロードしたかったのです。 これは議論を呼び起こし、意見は3つの選択肢の間で異なるようです: C#と同様に、ビット型を保持するために列挙型の変数が使用されます。 void M(NumericType flags); // With operator overloading: M(NumericType::Sign | NumericType::ZeroPadding); // Without operator overloading: M(static_cast<NumericType>(static_cast<int>(NumericType::Sign) | static_cast<int>(NumericType::ZeroPadding))); しかし、これはC ++ 11のスコープ付き列挙型の厳密に型指定された列挙型の哲学に反するでしょう。 列挙型のビットごとの組み合わせを保存する場合は、プレーン整数を使用します。 void …

3
enumデータ型を使用する代わりに新しいデータベーステーブルを作成するのは無駄ですか?
私が提供する4種類のサービスがあると仮定します(それらは頻繁に変わることはほとんどありません): テスト中 設計 プログラミング その他 上記のカテゴリのいずれかに該当する実際のサービスが60〜80個あるとします。たとえば、「サービス」は「テクニックAを使用したプログラムのテスト」で、タイプは「テスト」です。 それらをデータベースにエンコードしたいです。私はいくつかのオプションを思いつきました: オプション0: VARCHAR直接使用して、サービスタイプを文字列として直接エンコードします オプション1: データベースを使用しますenum。しかし、enumは悪です オプション2: 2つのテーブルを使用します。 service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); 参照整合性も楽しむことができます: ALTER service_line_item ADD FOREIGN KEY (service_type_id) REFERENCES service_type (id); いいですね。 しかし、私はまだ物事をエンコードし、整数を処理する必要があります。つまり、テーブルにデータを入力するときです。または、テーブルにデータを入力または処理するときに、手の込んだプログラミングまたはDB構造を作成する必要があります。つまり、データベースを直接扱うとき、またはプログラミング側で新しいオブジェクト指向エンティティを作成するときにJOINし、それらを正しく操作することを確認します。 オプション3: 使用しないでくださいenum。2つのテーブルを使用せず、整数列を使用してください。 service_line_item ( id, service_type INT, -- use 0, 1, 2, 3 (for service …

5
動的に型付けされた言語で列挙型が必要なのはなぜですか?
ここでいくつかのコードを読んでいて、enumがhtmlタグの名前を保存するために使用されているのを見ました。なぜこれを行う必要があるのでしょうか?この戦略を使用するとどのようなメリットがありますか? コンパイルされた言語または静的に型付けされた言語で列挙型がどのように役立つかは知っていますが、動的に型付けされた言語で列挙型を見ると、上記のコード例のように興味があります。それで、質問は基本的に、動的に型付けされた言語で列挙型が必要なのか、それともまったく必要なのか、ということです。

3
パブリックAPIで(列挙)型を表現する方法
私は自分のクライアントに使用し、将来一般に公開したいシンプルなAPIに取り組んでいます。異なる「タイプ」を持つことができる「アイテム」オブジェクトがあります。型はCの「typedef enum」です。 typedef enum { ItemTypeBool, ItemTypeNumber, ItemTypeDate, } ItemType; (将来、いくつか追加するかもしれません) 整数として転送するのか、定義された「文字列」として転送するのかを考えています。JSONは次のようになります。 整数の場合: { "name": "The name", "type": 0, ... } 文字列の場合: { "name": "The name" "type": "boolean" ... } これにベストプラクティスがあるかどうか疑問に思っています。整数を保持すると、コードが若干単純化され、帯域幅が削減されますが、開発者は文字列を覚えやすくなります。私はプロジェクトに取り組んだことを思い出し、1 = image、2 = audio、3 = htmlを思い出さなければなりませんでした。 あなたが私が考慮すべき他の側面を知っているなら、私はあなたに尋ねています。

5
列挙型は脆弱なインターフェースを作成しますか?
以下の例を考えてください。ColorChoice列挙の変更は、すべてのIWindowColorサブクラスに影響します。 列挙型は脆弱なインターフェースを引き起こす傾向がありますか?多態的な柔軟性を可能にする列挙型よりも優れたものはありますか? enum class ColorChoice { Blue = 0, Red = 1 }; class IWindowColor { public: ColorChoice getColor() const=0; void setColor( const ColorChoice value )=0; }; 編集:私の例として色を使用して申し訳ありませんが、それは質問についてのものではありません。これは、ニシンを避け、柔軟性の意味についてより多くの情報を提供する別の例です。 enum class CharacterType { orc = 0, elf = 1 }; class ISomethingThatNeedsToKnowWhatTypeOfCharacter { public: CharacterType getCharacterType() const; void setCharacterType( const CharacterType …

6
列挙型はコードの匂いではありませんか?
ジレンマ オブジェクト指向の実践に関するベストプラクティスの本をたくさん読んでいますが、読んだ本のほとんどすべてに、enumはコードの匂いだと言う部分がありました。列挙型が有効な場合に説明する部分を見逃したと思います。 そのように、私を探していますガイドラインおよび/またはユースケースの列挙型がありませ有効な構文コードのにおいと、実際に。 ソース: 「警告経験則として、列挙型はコードの匂いであり、多態性クラスにリファクタリングする必要があります。[8]」Seemann、Mark 、. 342 [8] Martin Fowler et al。、Refactoring:Improving the Design of Existing Code(New York:Addison-Wesley、1999)、82。 環境 私のジレンマの原因は取引APIです。このメソッドを介して送信することにより、Tickデータのストリームを提供します。 void TickPrice(TickType tickType, double value) どこ enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... } 変更を壊すことがこのAPIの生き方であるため、このAPIのラッパーを作成しようとしました。ラッパーで最後に受信した各ティックタイプの値を追跡したいので、ダニタイプのディクショナリを使用してそれを行いました。 Dictionary<TickType,double> LastValues 私には、キーとして使用される場合、これは列挙型の適切な使用のように思えました。しかし、私はこのコレクションに基づいて意思決定を行う場所があり、switchステートメントを排除する方法を考えることができないため、工場を使用できますが、その工場にはまだどこかにswitchステートメント。私はただ物事を動かしているように見えましたが、まだ匂いがします。 列挙型のDO N'Tを見つけるのは簡単ですが、DOはそれほど簡単ではありません。人々が自分の専門知識、長所と短所を共有できるなら、私はそれを感謝します。 考え直し 一部の決定とアクションはこれらに基づいておりTickType、enum / switchステートメントを削除する方法を考えることはできないようです。私が考えることができる最もクリーンなソリューションは、ファクトリを使用し、に基づいて実装を返すことTickTypeです。それでも、インターフェイスの実装を返すswitchステートメントがあります。 以下は、間違った列挙型を使用しているのではないかと疑っているサンプルクラスの1つです。 public class ExecutionSimulator { …

9
単体テストを使用して列挙型の値をテストする必要がありますか?
値のみの列挙型(Javaで実行できるメソッドはない)があり、この列挙型がシステムのビジネス定義の一部である場合、単体テストを作成する必要がありますか? 単純で冗長に見えるかもしれませんが、ユニット/統合/ ui / etcに関係なく、ビジネス仕様に関係するものをテストで明示的に作成する必要があると思います。テストするか、テスト方法として言語の型システムを使用します。列挙型(Javaなど)に必要な値は、ビジネスの観点から、型システムを使用してテストできないため、そのための単体テストが必要だと思います。 この質問は類似していない、この1、それは私と同じ問題に対処していないので。その質問にはビジネス機能(savePeople)があり、その人は内部実装(forEach)について問い合わせています。そこには、言語コンストラクト(forEach)をカプセル化する中間ビジネスレイヤー(人を救う機能)があります。ここで、言語構造(enum)は、ビジネスの観点から動作を指定するために使用されるものです。 この場合、実装の詳細は、データの「真の性質」、つまり値のセット(数学的な意味で)と一致します。ほぼ間違いなく不変のセットを使用できますが、同じ値がまだ存在しているはずです。配列を使用する場合は、ビジネスロジックをテストするために同じことを行う必要があります。ここでの難問は、言語構成がデータの性質と非常によく一致するという事実であると思います。自分自身を正しく説明したかどうかわかりません

3
Javaの列挙型でシングルトンを実装することの欠点は何ですか?
従来、シングルトンは通常次のように実装されます public class Foo1 { private static final Foo1 INSTANCE = new Foo1(); public static Foo1 getInstance(){ return INSTANCE; } private Foo1(){} public void doo(){ ... } } Javaの列挙型を使用して、シングルトンを次のように実装できます。 public enum Foo2 { INSTANCE; public void doo(){ ... } } 2番目のバージョンと同じくらいすごいのですが、欠点はありますか? (私はそれにいくつかの考えを与え、私は自分の質問に答えます;うまくいけば、より良い答えがあります)
14 java  singleton  enum 

5
switchステートメント-到達できない場合のデフォルトのケースの処理
私のクラスが所有する列挙型の値を処理するためにswitchステートメントを使用していて、可能な値ごとにケースがある場合-「デフォルト」のケースを処理するコードを追加する価値はありますか? enum MyEnum { MyFoo, MyBar, MyBat } MyEnum myEnum = GetMyEnum(); switch (myEnum) { case MyFoo: DoFoo(); break; case MyBar: DoBar(); break; case MyBat: DoBat(); break; default: Log("Unexpected value"); throw new ArgumentException() } これは、このコードに到達できない(ユニットテストでも)ことが原因だとは思いません。私の同僚はこれに同意せず、これがMyEnumに追加される新しい値によって引き起こされる予期しない動作から私たちを保護すると考えています。 コミュニティとは何ですか?

5
enumの文字列表現をより単純にするために、すべて大文字のネーミングに反対してもかまいませんか?
たとえば、列挙型定数にタイトルケースまたはすべて小文字のネーミングを使用する人を見たことがあります。次に例を示します。 enum Color { red, yellow, green; } これによりthrow new IllegalStateException("Light should not be " + color + ".")、たとえば、必要に応じて、文字列形式での作業が簡単になります。 列挙型がの場合、これはより受け入れられるようですがprivate、それでも私はそれが好きではありません。次のように、Stringフィールドを使用してenumコンストラクタを作成し、toStringをオーバーライドしてその名前を返すことができることを知っています。 enum Color { RED("red"), YELLOW("yellow"), GREEN("green"); private final String name; private Color(String name) { this.name = name } @Override public String toString() { return name; } } しかし、それがどれほど長いか見てください。シンプルにしたい小さな列挙型がたくさんある場合、これを続けるのは面倒です。ここでは、型破りなケースフォーマットを使用しても大丈夫ですか?
14 java  conventions  enum 

4
「グループ化」列挙型にフラグを使用するのは間違っていますか?
私の理解では、[Flag]enumは通常、個々の値が相互に排他的でない組み合わせ可能なものに使用されるということです。 例えば: [Flags] public enum SomeAttributes { Foo = 1 << 0, Bar = 1 << 1, Baz = 1 << 2, } どこにどんなSomeAttributes値がの組み合わせとすることができるFoo、BarとBaz。 より複雑で実際のシナリオでは、列挙型を使用して以下を記述しDeclarationTypeます。 [Flags] public enum DeclarationType { Project = 1 << 0, Module = 1 << 1, ProceduralModule = 1 << 2 | Module, ClassModule = 1 …
12 c#  .net  readability  enum 

8
すべての列挙型を1つのファイルに含め、複数のクラスで使用するのは悪い習慣ですか?
私は意欲的なゲーム開発者であり、時折インディーゲームに取り組んでいます。しばらくの間、最初は悪い習慣のように思われたことをしていましたが、ここで経験豊富なプログラマーから答えをもらいたいです。 enumList.hゲームで使用するすべての列挙型を宣言するファイルがあります。 // enumList.h enum materials_t { WOOD, STONE, ETC }; enum entity_t { PLAYER, MONSTER }; enum map_t { 2D, 3D }; // and so on. // Tile.h #include "enumList.h" #include <vector> class tile { // stuff }; 主なアイデアは、1つのファイルでゲーム内のすべての列挙型を宣言し、使用する必要があるファイルで宣言するのではなく、特定の列挙型を使用する必要があるときにそのファイルをインポートすることです。これは、物事をきれいにするためです。1つの列挙にアクセスするためだけにページを開くのではなく、1か所ですべての列挙にアクセスできます。 これは悪い習慣ですか、何らかの形でパフォーマンスに影響を与えることができますか?

7
列挙に特別な値「ALL」を含めることは良い習慣ですか?
私はマイクロサービス環境で新しいサービスを開発しています。これはRESTサービスです。簡単にするために、パスが/ historyBooksであるとしましょう そして、このパスのPOSTメソッドは、新しい履歴ブックを作成します。 歴史書が歴史の1つ以上の時代をカバーしていると仮定しましょう。 簡潔にするために、人間の歴史の次の時代しかないと仮定しましょう。 古代 ポストクラシック モダン 私のコードでは、それらをで表現したいと思いenumます。 メソッドの本体(ペイロード)はJSON形式であり、フィールド名を含める必要がありますeras。このフィールドは、eraこの本で扱う値のリストです。 本体は次のようになります。 { "name": "From the cave to Einstein - a brief history review", "author": "Foo Bar", "eras": ["Ancient", "Post Classical", "Modern"] } この特定のサービスでは、ビジネスロジックは次のとおりです。 入力に時代が指定されていない場合、この本はすべての時代を網羅していると見なされます。 APIレビューでは、すべての時代が網羅されていることを明示的に示すために、時代の列挙に 別の値を含めることを提案しましたALL。 長所と短所があると思います。 長所: 明示的な入力 短所: リスト内の2つの項目が提供されている場合、と言うALLとAncient-アプリケーションから取得されますでしょうか?これでALL他の値が上書きされるはずですが、それは新しいビジネスロジックです。 特定の時代を対象とする書籍のクエリを実行する場合、すべての時代を対象とする書籍をどのように表現しますか?場合ALLも(同じロジックを使用して)出力に使用され、それが解釈する消費者の責任だALLとは["Ancient", "Post Classical", "Modern"]。 私の質問 新しいALLものを持つことは、まったく持たないことよりも混乱を引き起こすと思います。 どう思いますか?このALL値を追加しますか、それなしでAPIを保持しますか?
11 rest  api  json  enum 

1
多くのブール型プロパティを持つ列挙型
現在、ユーザーに返されるページに基づいてサーバーロジックを調整する必要があることが多いwebappに取り組んでいます。 各ページには4文字のページコードが与えられ、これらのページコードは現在、静的な文字列としてクラスにリストされています。 public class PageCodes { public static final String FOFP = "FOFP"; public static final String FOMS = "FOMS"; public static final String BKGD = "BKGD"; public static final String ITCO = "ITCO"; public static final String PURF = "PURF"; // etc.. } そして、多くの場合、コードには次のようなコードが表示されます(1番目の形式): if (PageCode.PURF.equals(destinationPageCode) || PageCodes.ITCO.equals(destinationPageCode)) { …
11 java  design  enum 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.