タグ付けされた質問 「class-design」

私にはEnemyクラスがあり、コンストラクタは次のようになります。 public Enemy(String name, float width, float height, Vector2 position, float speed, int maxHp, int attackDamage, int defense... etc.){} コンストラクターには非常に多くのパラメーターがあるため、これは悪いように見えますが、Enemyインスタンスを作成するときは、これらすべてを指定する必要があります。また、これらの属性をEnemyクラスに含めて、それらのリストを反復処理し、これらのパラメーターを取得/設定できるようにします。EnemyをEnemyB、EnemyAにサブクラス化して、maxHpなどの特定の属性をハードコーディングすることを考えていましたが、Enemyのリスト（EnemyA、EnemyB、およびEnemyC's）。 私はただきれいにコーディングする方法を学ぼうとしています。違いがあれば、Java / C ++ / C＃で作業しています。正しい方向の任意のポイントが高く評価されています。

21 coding-style  class-design  constructors 

明確にするために、私が尋ねているのは public class A{ private/*or public*/ B b; } 対 public class A{ private/*or public*/ class B{ .... } } どちらか一方を使用するいくつかの理由を明確に考えることができますが、私が本当に見たいのは、長所と短所が単なる学術的ではないことを示す説得力のある例です。

21 object-oriented-design  class-design 

私は物理デバイスを扱うプロジェクトに取り組んでおり、このプロジェクトのいくつかのクラスに適切な名前を付ける方法として混乱しています。 実際のデバイス（センサーとレシーバー）を考慮することと、ソフトウェアでそれらを表現することは別のことであるため、「Info」という接尾辞の名前パターンでクラスに名前を付けることを考えています。 たとえば、a Sensorは実際のセンサーを表すクラスですが（実際に動作するデバイスに実際に接続されている場合）、SensorInfoそのようなセンサーの特性のみを表すために使用されます。たとえば、ファイルの保存時に、をシリアル化するのではSensorInfoなく、ファイルヘッダーにをシリアル化しますSensor。これは意味がありません。 しかし、今私は混乱しています。なぜなら、オブジェクトのライフサイクルには、どちらを使用するべきか、どのように別のものを取得するか、または両方のバリアントを実際に1つのクラスのみに折りたたむかどうかを判断できない中間点があるためです。 また、あまりにも一般的なEmployeeクラスの例は、明らかに実在の人物の表現にすぎませんがEmployeeInfo、私の知る限り、クラスに名前を付けることを提案する人はいません。 私が使用している言語は.NETです。この命名パターンは、これらのクラスの例として、フレームワーク全体で共通しているようです。 DirectoryおよびDirectoryInfoクラス; FileおよびFileInfoクラス; ConnectionInfoクラス（対応するConnectionクラスなし）; DeviceInfoクラス（対応するDeviceクラスなし）; だから私の質問は次のとおりです。この命名パターンを使用することについて共通の根拠がありますか？名前のペア（ThingとThingInfo）を使用するのが理にかなっている場合ThingInfoや、Thingクラスが存在しない、またはクラスが存在しない他の場合がありますか？

20 c#  .net  naming  class-design  naming-standards 

ほとんどのJavaコードでは、次のようにJavaオブジェクトを宣言する人がいます。 Map<String, String> hashMap = new HashMap<>(); List<String> list = new ArrayList<>(); の代わりに： HashMap<String, String> hashMap = new HashMap<>(); ArrayList<String> list = new ArrayList<>(); 実際に使用される実装ではなく、インターフェースを使用してJavaオブジェクトを定義する設定があるのはなぜですか？

17 java  object-oriented  class-design 

データモデルを保持するクラスを設計するとき、不変オブジェクトを作成すると便利ですが、どの時点でコンストラクターパラメーターリストとディープコピーの負荷が大きくなりすぎて、不変の制限を放棄する必要があるのでしょうか？ たとえば、名前付きのものを表す不変のクラスを次に示します（C＃構文を使用していますが、原則はすべてのOO言語に適用されます） class NamedThing { private string _name; public NamedThing(string name) { _name = name; } public NamedThing(NamedThing other) { this._name = other._name; } public string Name { get { return _name; } } } 名前付きのものは、新しい名前付きのものに作成、クエリ、コピーできますが、名前は変更できません。 これはすべて良いですが、別の属性を追加したい場合はどうなりますか？コンストラクターにパラメーターを追加し、コピーコンストラクターを更新する必要があります。これはあまり手間がかかりませんが、複雑なオブジェクトを不変にしたいときに、問題が発生するのはわかります。 クラスに他の複雑なクラスを含むmay属性とコレクションが含まれている場合、コンストラクターのパラメーターリストは悪夢のように思えます。 では、どの時点でクラスが複雑すぎて不変にならないのでしょうか？

16 class-design  immutability 

Javaコードベースでは、次のパターンを見続けています。 /** This is a stateless utility class that groups useful foo-related operations, often with side effects. */ public class FooUtil { public int foo(...) {...} public void bar(...) {...} } /** This class does applied foo-related things. */ class FooSomething { int DoBusinessWithFoo(FooUtil fooUtil, ...) { if (fooUtil.foo(...)) fooUtil.bar(...); …

15 java  class-design  anti-patterns 

Excel（C＃および.Net 4）から読み取るクラスがあり、そのクラスには、UIの応答性を維持しながらExcelからデータをロードするバックグラウンドワーカーがあります。私の質問は次のとおりです。クラスにバックグラウンドワーカーを配置するのは悪い設計ですか。クラスなしでクラスを作成し、バックグラウンドワーカーを使用してそのクラスを操作する必要がありますか？この方法でクラスを作成することに関する問題は実際にはありませんが、それでも私は初心者なので、先に進む前に確認することを考えました。 私のコードが機能するので、これはスタックオーバーフローではないはずだと思うので、この質問がここで関連することを願っています。これは単なる設計上の問題です。

15 c#  design  multithreading  class-design 

ここに私が意味するものがあります： class MyClass { int arr1[100]; int arr2[100]; int len = 100; void add(int* x1, int* x2, int size) { for (int i = 0; i < size; i++) { x1[i] += x2[i]; } } }; int main() { MyClass myInstance; // Fill the arrays... myInstance.add(myInstance.arr1, myInstance.arr2, myInstance.len); } addクラスメソッドなので、必要なすべての変数に既にアクセスできますが、これは悪い考えですか？これを行うべき、またはすべきでない理由はありますか？

14 object-oriented  c++  class-design  methods  encapsulation 

JavaのReactiveX （RxおよびReactive Extensionsとも呼ばれます）の実装であるRxJavaを始めたばかりです。本当に私を襲った何かがの巨大な大きさだったRxJavaのフロアブルクラス：それは460個のメソッドを持っています！ 公平であるために： オーバーロードされたメソッドが多数あり、メソッドの総数が大幅に増えます。 おそらくこのクラスは分割されるべきですが、RxJavaに関する私の知識と理解は非常に限られています。RxJavaを作成した人々は確かに非常にスマートであり、それらは作成するために選択するための有効な引数を、おそらくを提供することができますフロアブル剤を非常に多くの方法で。 一方： RxJavaはのJava実装であるMicrosoftの反応性の拡張機能、およびそれがさえ持っていないフロアブルクラスを、ので、これは盲目的に既存のクラスを移植し、Javaでそれを実施する場合ではありません。 [ 更新：イタリック体の前のポイントは事実正しくありません。マイクロソフトの観察可能な 400以上のメソッドを持つクラスは、RxJavaのための基礎として使用された観察可能なクラス、および流動性は、に似て観察可能な大量のデータのためではなく、ハンドル背圧。そのため、RxJavaチームは既存のクラスを移植していました。この投稿は、元のデザインに挑戦されている必要があり、観察可能マイクロソフトによってクラスではなく、RxJavaのフロアブルクラスを。] RxJavaはわずか3年以上前であるため、これは（Javaの初期リリースの場合のように）優れた（SOLID）クラス設計原則に関する知識が不足しているためにコードが誤って設計されている例ではありません。 Flowableほどの大きさのクラスでは、その設計は本質的に間違っているように見えますが、そうではないかもしれません。このSEの質問に対する1つの答えクラスメソッドの数の制限は何ですか？答えは「必要な数のメソッドを用意する」ことです。 明らかに、言語に関係なくそれらをサポートするためにかなりの数のメソッドを必要とするクラスがいくつかあります。それらは簡単に小さなものに分解されず、かなりの数の特性と属性を持っているからです。例：文字列、色、スプレッドシートセル、データベース結果セット、HTTPリクエスト。これらのことを表現するためのクラス用のメソッドをおそらく数十個用意することは、理不尽に思えません。 しかし、Flowableには460個のメソッドが本当に必要なのでしょうか、それとも非常に巨大なために、必ずしもクラスの設計が悪い例ですか？ [明確にするには：この質問は、具体的RxJavaのに関し、フロアブルクラスではなく、神は、一般的にオブジェクト。]

14 java  object-oriented  class-design  solid  reactive 

たとえば、コンソールとの間のあらゆる種類の入出力メソッドを備えたコンソールゲームプログラムがあるとします。でしょうが、すべてのシングルでそれらを保つためにスマートにinputOutputクラスなど、より具体的なクラスにそれらを打破startMenuIO、inGameIO、playerIO、gameBoardIO各クラスが1-5程度のメソッドを持っていることなど、？ また、同じメモで、それらを分解する方が良い場合は、IO名前空間に配置して、呼び出しをもう少し冗長にするのが賢明でしょうIO.inGameか？

14 design-patterns  object-oriented  class-design  solid  single-responsibility 

私は週末にいくつかのコードを書いていましたが、ファクトリを基本クラスの静的メソッドとして書きたいと思いました。 私の質問は、これが独創的なアプローチであるかどうかを知ることですか？ 基本クラスが派生クラスの知識を持っているという事実からではないかもしれないという私の感覚です。 そうは言っても、同じ結果を得るためのもっと簡単な方法はわかりません。他のファクトリクラス全体は（少なくとも私には）不要な複雑さ（？） 何かのようなもの： class Animal { public static Animal CreateAnimal(string name) { switch(name) { case "Shark": return new SeaAnimal(); break; case "Dog": return new LandAnimal(); break; default: throw new Exception("unknown animal"); } } } class LandAnimal : Animal { } class SeaAnimal : Animal { }

14 c#  class-design 

C＃プロジェクトのクラス階層を設計する必要があります。基本的に、クラスの機能はWinFormsクラスに似ているため、WinFormsツールキットを例に取りましょう。（ただし、WinFormsやWPFは使用できません。） すべてのクラスが提供する必要があるいくつかのコアプロパティと機能があります。寸法、位置、色、可視性（true / false）、Drawメソッドなど。 設計上のアドバイスが必要です。抽象ベースクラスと実際には型ではなく、動作に似たインターフェイスを持つ設計を使用しました。これは良いデザインですか？そうでない場合、より良いデザインになります。 コードは次のようになります。 abstract class Control { public int Width { get; set; } public int Height { get; set; } public int BackColor { get; set; } public int X { get; set; } public int Y { get; set; } public int BorderWidth { get; …

14 c#  object-oriented  design-patterns  class-design 

たとえば、行う方が良いですか： Pdf pdf = new Pdf(); pdf.Print(); または： Pdf pdf = new Pdf(); PdfPrinter printer = new PdfPrinter(); printer.Print(pdf); もう一つの例： Country m = new Country("Mexico"); double ratio = m.GetDebtToGDPRatio(); または： Country m = new Country("Mexico"); Country us = new Country("US"); DebtStatistics ds = new DebtStatistics(); double usRatio = ds.GetDebtToGDPRatio(us); double …

14 functions  statistics  methods  object-oriented-design  class-design 

2500行のCharacterクラスがあります。 ゲーム内のキャラクターの内部状態を追跡します。 その状態をロードして永続化します。 〜30個の着信コマンドを処理します（通常=に転送しますGameが、一部の読み取り専用コマンドはすぐに応答します）。 Game実行中のアクションと他のユーザーの関連アクションに関する〜80の呼び出しを受け取ります。 私にCharacterは、単一の責任があるように思われます。キャラクターの状態を管理し、受信コマンドとゲームを仲介することです。 既に分割されている他のいくつかの責任があります。 CharacterOutgoingクライアントアプリケーションの発信更新を生成するために呼び出すがあります。 Characterは、Timer次に何ができるかを追跡するを持っています。着信コマンドはこれに対して検証されます。 だから私の質問は、SRPや同様の原則の下でこのような大規模なクラスを持つことは容認できますか？煩雑さを軽減するためのベストプラクティスはありますか（メソッドを個別のファイルに分割するなど）。それとも、私は何かを見逃していますか？それを分割する本当に良い方法はありますか？これは非常に主観的なものであり、他の人からのフィードバックが欲しいと思います。 サンプルを次に示します。 class Character(object): def __init__(self): self.game = None self.health = 1000 self.successful_attacks = 0 self.points = 0 self.timer = Timer() self.outgoing = Outgoing(self) def load(self, db, id): self.health, self.successful_attacks, self.points = db.load_character_data(id) def save(self, db, id): db.save_character_data(self, health, self.successful_attacks, self.points) …

13 object-oriented  class-design  single-responsibility 

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 …

13 c#  design-patterns  class-design  methods  properties