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

私は現在、書いているクラスへのインターフェースについて考えています。このクラスには、キャラクターのスタイル、たとえば、キャラクターが太字、斜体、下線などが含まれます。これらのスタイル。私は論理名を好む傾向がありますが、それは効率的でも論理的でもないコードを書くことを意味します。例を挙げましょう。 私はクラスの持っているCharacterStylesメンバ変数があるbold、italic、underline（およびいくつかの他の人を、私はそれをシンプルに保つためにそれらを残しておきます）。最も簡単な方法は、あなたが行うことができるように、書き込みgetter / setterメソッドになり、これらの変数にアクセスするには、プログラムの他の部分を可能にstyles.setBold(true)してstyles.setItalic(false)。 しかし、私はこれが好きではありません。多くの人がゲッター/セッターがカプセル化を破ると言っているだけでなく（それは本当にそんなに悪いのですか？）私は、styles.format("bold", true)これらのすべての方法ではなく、1つの方法などでキャラクターのスタイルを設定することを期待しています。 ただし、1つの問題があります。C ++の文字列の内容ではオブジェクトメンバー変数にアクセスできないため、すべてのスタイルに対して大きなifステートメント/スイッチコンテナーを記述するか、スタイルを連想配列に格納する必要があります（地図）。 最善の方法がわからない。ある瞬間、私はゲッター/セッターを書くべきだと思い、次の瞬間、私は他の方法に傾く。私の質問は：あなたは何をしますか？そして、なぜあなたはそれをするのでしょうか？

12 c++  object-oriented  class-design 

私は従業員を管理するためのプログラムを作成しようとしています。ただし、Employeeクラスの設計方法を理解することはできません。私の目標は、Employeeオブジェクトを使用してデータベース上の従業員データを作成および操作できるようにすることです。 私が考えた基本的な実装は、この単純な実装でした： class Employee { // Employee data (let's say, dozens of properties). Employee() {} Create() {} Update() {} Delete() {} } この実装を使用すると、いくつかの問題が発生しました。 ID従業員のは、私は、新しい従業員を記述するためのオブジェクトを使用するのであれば、何があるだろう、データベースによって与えられていないID既存の従業員を表すオブジェクトはながら、まだ格納するだろう持っていますID。そのため、オブジェクトを説明するプロパティと、オブジェクトを説明しないプロパティがあります（SRPに違反していることを示すことができますか？新しいクラスと既存の従業員を表すのに同じクラスを使用しているため...）。 Create一方、この方法は、データベース上の従業員を作成することになっているUpdateとは、Delete既存の従業員（ここでも、上で動作するようになっているSRP ...）。 「作成」メソッドにはどのようなパラメーターが必要ですか？すべての従業員データまたはEmployeeオブジェクトのための数十のパラメーター？ クラスは不変であるべきですか？ どのようにUpdate動作しますか？プロパティを取得してデータベースを更新しますか？または、「古い」オブジェクトと「新しい」オブジェクトの2つのオブジェクトを取り、それらの違いでデータベースを更新しますか？（答えは、クラスの可変性に関する答えと関係があると思います）。 コンストラクターの責任は何ですか？必要なパラメーターは何ですか？idパラメーターを使用してデータベースから従業員データを取得し、プロパティを設定しますか？ それで、あなたが見ることができるように、私は私の頭の中に少し混乱を持っています、そして、私は非常に混乱しています。そのようなクラスがどのように見えるべきかを理解してください。 このような頻繁に使用されるクラスが一般的にどのように設計されているかを理解するためだけに、意見を望まないことに注意してください。

11 object-oriented  class-design  class 

1回だけインスタンス化されるPythonクラスがある場合、つまり、クラスのオブジェクトは1つだけになります。クラスを直接操作するのではなく、単一のクラスインスタンスを作成する方が理にかなっているのではないかと思いました。 同様の質問がありますが、焦点は異なります。 グローバル変数と関数をクラスにグループ化することです Python固有ではありません。後者は、（Pythonで）クラスもオブジェクトであるという事実を考慮しないことを意味します。 更新： Pythonでは、クラスとオブジェクトの両方で次のことができます。 class A(object): pass A.some_state_var = True # Then later A.some_state_var = False my_a = A() my_a.some_state_var = True # Then later my_a.some_state_var = False そのため、クラスとそのクラスのインスタンスの間の選択が（Pythonで）状態に関するものであるかどうかはわかりません。どちらかで状態を維持できます。 さらに、クラス/クラスインスタンスを作成する動機は、シングルトン要件を強制することではありません。 また、新しいTypeを作成することはそれほど重要ではありません。 動機は、関連するコードとデータをグループ化し、それへのインターフェースを持つことです。これが、最初にクラス図のクラスとしてモデル化した理由です。実装に関してのみ、このクラスをインスタンス化するかどうか疑問に思い始めました。

11 design  object-oriented  python  object-oriented-design  class-design 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私は、静的メンバーまたは静的クラス全体に関する考え方と業界のベストプラクティスについて非常に興味があります。これには欠点がありますか、それともアンチパターンに参加していますか？ これらのエンティティは、機能を提供するためにクラスをインスタンス化することを要求または要求しないという意味で、「ユーティリティクラス/メンバー」と見なされます。 これに関する一般的な考えと業界のベストプラクティスは何ですか？ 以下のクラスとメンバーの例を参照して、私が参照しているものを説明してください。 // non-static class with static members // public class Class1 { // ... other non-static members ... public static string GetSomeString() { // do something } } // static class // public static class Class2 { // ... other static members ... public …

11 c#  class-design 

私は依存関係の注入について学んでいるだけで、何かにこだわっています。依存性注入では、コンストラクターを介して依存クラスを送信することをお勧めしますが、これがデータオブジェクトに必要かどうかは疑問です。単体テストは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 

データベースにオブジェクトを保存したり、データベースからオブジェクトを取得したりするクラス（リポジトリ）がいくつかあります。それらすべてが1つのデータベースへの接続を確立する必要があります。 各クラスでConnectionStringとを再定義しないようにSqlConnection、オープン接続をそれらに渡すことを考えました。次に、その接続を定義/オープンしてクラスに渡すのに最適な場所/時間はいつ/どこですか？ この共通のリソースにアクセスするためのより良いアプローチ/パターンはありますか？

11 c#  sql  class-design 

私のC ++プロジェクトには、2つのクラスとがParticleありContactます。でParticleクラス、Iは、メンバ変数有するstd::vector<Contact> contactsのすべての連絡先含まParticleオブジェクトを、対応するメンバ関数をgetContacts()とaddContact(Contact cont)。したがって、「Particle.h」には「Contact.h」を含めます。 ではContact、クラス、私はのためのコンストラクタにコードを追加したいContactことが呼び出すParticle::addContact(Contact cont)ように、contacts両方のために更新されてParticleいる間でオブジェクトContactオブジェクトが追加されています。したがって、「Contact.cpp」に「Particle.h」を含める必要があります。 私の質問は、これが許容できる/適切なコーディングプラクティスであるかどうかであり、そうでない場合は、達成しようとしていることを実装するためのより良い方法は何ですか（簡単に言えば、新しい連絡先のたびに特定の粒子の連絡先のリストを自動的に更新します）創造された）。 これらのクラスは、NetworkN個の粒子（std::vector<Particle> particles）とNc個の接触（std::vector<Contact> contacts）を持つクラスによって結合されます。しかし、私は次のような関数を使用できるようにしたかったのです。この場合、クラスにparticles[0].getContacts()そのような関数があっても大丈夫ですParticleか、またはこの目的のためにC ++でより良い関連付け「構造」があります（別のクラスで使用されている2つの関連クラスの） 。 私はこれにどのように取り組んでいるのか、ここで視点のシフトが必要かもしれません。2つのクラスはNetworkクラスオブジェクトによって接続されているため、接続情報をNetworkオブジェクトによって完全に制御するのが一般的なコード/クラス編成ですか（パーティクルオブジェクトはその連絡先を認識してはならず、その結果、getContacts()メンバーを持つべきではありません）関数）。次に、特定の粒子が何に接触しているかを知るために、Networkオブジェクトを介して（たとえばを使用してnetwork.getContacts(Particle particle)）その情報を取得する必要があります。 Particleオブジェクトがその知識を持つこと（つまり、NetworkオブジェクトまたはParticleオブジェクトのいずれかを介して、その情報にアクセスするための複数の方法があること）は、あまり一般的ではない（おそらく推奨されない）C ++クラス設計でしょうか）？

10 c++  class-design  class 

もちろんできますが、そのようにデザインするのが合理的かどうか疑問に思っています。 私はブレイクアウトクローンを作成していて、クラスの設計を行っていました。継承する必要はありませんが、C ++で学んだことを適用するために継承を使用したいと思いました。私はクラスの設計について考えていて、次のようなものを思いつきました： GameObject->基本クラス（xオフセットとyオフセットのようなデータメンバー、およびSDL_Surface *のベクターで構成されます* MovableObject：> GameObject->抽象クラス+ GameObjectの派生クラス（1つのメソッドvoid move（）= 0;） NonMovableObject：GameObject->空のクラス...コンストラクタやデストラクタ以外のメソッドやデータメンバーはありません（少なくとも今のところは？） その後、TilesetのようなNonMovableObjectからクラスを派生することを計画していました：NonMovableObject。「空の」抽象クラスまたは単に空のクラスが頻繁に使用されるかどうか疑問に思っていました...私はこれを行っている方法で、分類のためにクラスNonMovableObjectを作成していることに気付きました。 私はブレイクアウトクローンを作成するためだけに考えすぎていることを知っていますが、私の焦点はゲームではなく、継承の使用とある種のゲームフレームワークの設計にあります。

10 class-design 

私はインターフェースを「発見」し、それらを愛するようになりました。インターフェイスの優れた点は、それがコントラクトであることであり、そのコントラクトを満たすオブジェクトは、そのインターフェイスが必要な場所であればどこでも使用できます。 インターフェースの問題は、それがデフォルトの実装を持つことができないことです。これは、ありふれたプロパティの苦痛であり、DRYを無効にします。これは、実装とシステムの分離を維持するため、これも良い方法です。一方、継承はより緊密な結合を維持し、カプセル化を壊す可能性があります。 ケース1（プライベートメンバーによる継承、適切なカプセル化、密結合） class Employee { int money_earned; string name; public: void do_work(){money_earned++;}; string get_name(return name;); }; class Nurse : public Employee: { public: void do_work(/*do work. Oops, can't update money_earned. Unaware I have to call superclass' do_work()*/); }; void HireNurse(Nurse *n) { nurse->do_work(); ) ケース2（単なるインターフェース） class IEmployee { virtual …

10 c++  design  interfaces  class-design  inheritance 

私はワードプレスサイト用にさまざまな投稿フィルターを開発しており、最初の4つを単一のクラスで構築しました。 最後の2つはスコープが十分に異なるため、クラス内で1つの関数（最終リンクを生成するための関数）のみを共有します。 このインスタンスまたはいくつかの類似の仮想インスタンスのいずれかで、その機能を実現するために元のクラスを拡張することは合理的ですか、それともより良い方法がありますか？

10 object-oriented  class-design 

ゲッター/セッターが正当化される時期についてこのページを読んでいましたが、OPは次のコードサンプルを提供しました。 class Fridge { int cheese; void set_cheese(int _cheese) { cheese = _cheese; } int get_cheese() { return cheese; } } void go_shopping(Fridge fridge) { fridge.set_cheese(fridge.get_cheese() + 5); } 受け入れ答えの状態： ちなみに、あなたの例ではFridge、putCheese()andのtakeCheese()代わりに、クラスに and メソッドを指定get_cheese() しset_cheese()ます。その後、まだカプセル化されています。 カプセル化は、名前をget / setからputCheese()/に変更することによってどのように保持さtakeCheese()れますか？ 同じ答えでそれはまた述べています： ゲッターとセッターを使用しても、カプセル化が壊れることはありません。カプセル化を解除するのは、何も考えずに、すべてのデータメンバー（Java lingoのすべてのフィールド）にゲッターとセッターを自動的に追加することです。 この場合、変数は1つだけなのでcheese、チーズを取り出して冷蔵庫に戻したい場合があるため、この場合の取得/設定ペアは正当化されます。

9 object-oriented  class-design  encapsulation  setters  getters 

コードベースの抽象化が多すぎる（または少なくともそれを処理している）と感じている問題に直面しています。コードベースのほとんどのメソッドは、コードベースの最上位の親Aを取り込むように抽象化されていますが、この親の子Bには、これらのメソッドの一部のロジックに影響を与える新しい属性があります。問題は、入力がAに抽象化されているため、これらのメソッドでこれらの属性をチェックできないことです。もちろん、Aにはこの属性がありません。Bを異なる方法で処理する新しいメソッドを作成しようとすると、コードの重複のために呼び出されます。私の技術リーダーによる提案は、ブール型パラメーターを受け取る共有メソッドを作成することですが、これの問題は、これを「隠された制御フロー」と見なす人がいることです。 、また、この共有メソッドは、小さな属性に分割されたとしても、将来の属性を追加する必要がある場合、一度複雑になりすぎたり複雑になったりします。これはまた、カップリングを増やし、結束を減らし、チームの誰かが指摘した単一責任の原則に違反します。 基本的に、このコードベースの抽象化の多くはコードの重複を減らすのに役立ちますが、メソッドの拡張/変更が最高の抽象化を行うようになっている場合は難しくなります。このような状況ではどうすればよいですか？私は非難の中心にいますが、他の誰もが彼らが良いと思うことに同意することはできませんが、それは結局私を傷つけています。

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

私たちは多くのユニットテストとビジネスオブジェクトのリファクタリングを行っており、クラスの設計について他のピアとは非常に異なる意見を持っているようです。 私がファンではないクラスの例： public class Foo { private string field1; private string field2; private string field3; private string field4; private string field5; public Foo() { } public Foo(string in1, string in2) { field1 = in1; field2 = in2; } public Foo(string in1, string in2, string in3, string in4) { field1 = …

9 c#  object-oriented-design  class-design  class 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は新しいクラスを書き始めたばかりで、厳密には必要のないメソッド引数をたくさん追加していることに気付きました。これは、クラスの一般的な構成や依存関係ではなく、特定のメソッド呼び出しに固有のクラス内の状態を回避する習慣に従っています。 そうすることは、引数を持たない可能性のある多くのメソッドが1、2、または3で終わることを意味します。 このトレードオフについてどう思うか、どのような状況でどのアプローチを取るかをどのように決定するかについて、あなたの意見を聞きたいのですが。 コードを説明するとき、コードは英語よりも理解しやすいことが多いため、両方のバリアントを含む小さな要点を作成しました：https : //gist.github.com/JeroenDeDauw/6525656

9 class-design  complexity  methods  parameters  cohesion 

オブジェクトが物理的に存在するかどうかに関係なく、さまざまな方法でモデリングすることができます。多くの場合、一般化または合成を任意に使用できます。ただし、「一般化よりも構成を優先する」というGoFの原則により、構成を使用するようにガイドされます。したがって、たとえばラインをモデル化する場合、Point（一般化）を拡張する代わりに、タイプPoint（構成）の2つのメンバーPointAおよびPointBを含むクラスを作成します。これは、オブジェクトが通常ははるかに複雑であるにもかかわらず、モデル化するための構成または継承を任意に選択できる方法の単純化された例にすぎません。 これが正しい選択であることをどのように知ることができますか？少なくとも、それが間違っている場合に実行すべき大量のリファクタリングが存在する可能性があるため、問題になりますか？

9 object-oriented  inheritance  composition  class-design