問題タブ [software-design]

私が今取り組んでいることの 1 つは、ゲームにいくつかの類似点があります。説明のために、架空の架空のゲームから引き出された例を使用して問題を説明します。

それをDeathBlaster 4: The Deatheningと呼びましょう。DB4 では、移動Ship中に定期的かつランダムに遭遇する多数のオブジェクトがありPhenomenaます。与えられた は、それに遭遇するPhenomenonに 0 個、1 個、または複数個ある場合があります。たとえば、4 種類のと 3 種類の があるとします。EffectsShipShipsPhenomena

さらに、Effects相互に作用する可能性があります。たとえば、 aと a のGreenShip両方にある a は、生成されたとの間である種の相乗効果を引き出すことができます。そのような場合、相乗効果自体が、たとえば、この相互作用の結果である可能性があります。最終結果がどうあるべきかを解決するために、a に作用するセット以外の情報は必要ありません。GravityWellNebulaFieldSpeedEffectShieldEffectEffectPowerLevelSynergyEffectEffectsShip

ここで問題が発生する可能性があります。単純な最初のアプローチとして、 everyが every の処理方法を知っている必要があるか、everyが every について知っている必要がありますShipPhenomenonPhenomenonShip。これは明らかに容認できないため、これらの責任を別の場所に移したいと考えています。明らかに、ここには少なくとも 1 つの外部クラスがあり、おそらく aMediatorまたはVisitor何らかの種類です。

しかし、それを行うための最良の方法は何ですか? 理想的なソリューションには、おそらく次の特性があります。

• 新しい を追加するのと同じくらい簡単に、新しいShipを追加できPhenomenonます。
• 効果を生み出さない相互作用はデフォルトであり、表現するための追加のコードは必要ありません。設定より規約。
• 相互にどのように相互作用するかを理解しEffects、これらの相互作用を管理して最終結果がどうなるかを決定することができます。

私は自分のアプローチがどうなるかをすでに決めていると思いますが、最良の設計のコンセンサスが何であるかを聞くことに興味があります. どこから始めますか？どのような道を探りますか?

フォローアップ更新:皆さん、ご回答ありがとうございます。これが私がやったことです。私の主な観察結果は、可能性のある×相互作用Effectsの数に比べて、異なる数が少ないように見えるということでした。つまり、相互作用の組み合わせはたくさんありますが、それらの相互作用の結果の種類の数は少なくなります。PhenomenaShips

たとえば、表には 12 の相互作用の組み合わせがありますが、効果は 5種類しかないことがわかります。速度の変更、パワーの変更、シールドの変更、無敵、死亡です。

InteractionResolver相互作用の結果を決定するために、3 番目のクラス を導入しました。Ship-Phenomenonペアをマップするディクショナリが含まれていますEffects(基本的には、エフェクトといくつかのメタデータを実行するデリゲートです)。相互作用の計算結果が完了すると、それぞれに対応するShipが渡されます。EffectStackEffects

Ships次に、 を使用して、既存の属性とプロパティに修飾子を追加することにより、それらEffectStackの の実際の結果を決定します。Effects

私はこれが好きです:

• Shipについて知る必要はありませんPhenomena。
• Ship-関係の複雑さは、 にPhenomena抽象化されますInteractionResolver。
• 複数の、場合によっては複雑な効果を解決する方法の詳細は、 によって抽象化されていInteractionResolverます。船は必要に応じて効果を適用するだけです。
• これにより、追加の便利なリファクタリングが可能になります。たとえば、船が効果を処理する方法EffectProcessorStrategyは、 . デフォルトはすべての効果を処理することかもしれませんが、たとえば、 aBossShipは異なる を持つことでマイナーな効果を無視するかもしれませんEffectProcessorStrategy。

もちろん、ほとんどの場合、この種の要求は、ユーザーが本当に望んでいるものについての手がかりも、特定のソフトウェア プロジェクトまたはソフトウェア全般を構築する技術的側面についての手がかりもない経営陣からのものです。詳細については、ディルバートのとんがり髪のボスを参照してください。

ただし、それは 1 つの側面にすぎません。構築しているシステムの全体的なパフォーマンスに悪影響を与えることがわかっている項目の要求についてはどうでしょうか? あるいは、ばかげて権限を与えられたにもかかわらず、彼らが行うことのほとんどすべてが失敗に終わっている技術的な愚か者はどうですか? （素晴らしい例については、この投稿を参照してください）

最終的に、最終的にプロジェクトに損害を与えることがわかっている構築中のものに対する要求や命令に、どのように雄弁に、専門的に、そして穏やかに対処しますか?

Dupe :クライアントがばかげたことを要求し、主張するとき

ソフトウェア設計に関する質問があります。いくつかの要素を含む Windows フォームがあり、顧客オブジェクトがあるとします。顧客は、たとえば、ビジネス、プライベート、または法人のいずれかです。

ここで、フォームで何が起こるかのすべての決定は、顧客のタイプによって異なります。たとえば、特定の要素が非表示になる、特定のラベル テキストが異なるなど、イベントの応答が異なります。

明らかに、これをコーディングする 1 つの方法は、決定を下す必要があるたびに CASE ステートメントを使用することです。もう 1 つの方法は、Customer クラスと、BusinessCustomer、PrivateCustomer、CorporateCustomer などの他の 3 つのクラスを基本クラスから継承させることです。後者の場合、疑問が生じます。どのようにしてウィンドウをそこに組み込むのでしょうか....

編集済み

フォーム内にフォームを埋め込むことはできますか? 私の要件では、一度に 2 つのウィンドウを表示する必要はありません。そのため、MDI を使用する必要はありません。しかし、ここでいくつかの ppl のコメントに基づいて設計を簡素化するために、3 つの異なる顧客フォームを維持し、その場でメイン フォーム内に埋め込みたいと考えています。そうすれば、3 つの GUI が分離され、すべてのコントロールの可視性に対処する必要がなくなります。

次のように、フォームを別のフォームに追加できると仮定しています。

UIKit リファレンスは、UIView は UIWindow のスーパークラスであると述べていますが、この親子関係にもかかわらず、UIWindow は実際には UIView を管理します。これは私にはとても珍しいように聞こえます。

ソフトウェア設計の観点から、これの重要性を知っている人はいますか?

どうもありがとう。

編集:
iPhone プログラミング ガイドの関連する段落を読みました。UIWindow を UIView の親にします。Apple がクラス階層をこのように設計することを余儀なくされた何かがあったに違いありません。

デザインの質問があります。一部の属性を共有し、GUI (Windows フォーム) とバックエンドの両方の点で他のコンポーネントが異なる複数のコンポーネントがあるアプリケーションを作成する場合、理論的にはどのようにアプローチしますか?

たとえば、4 種類の製品があるアプリケーションがあります。製品の詳細を入力するフォームはすべて、3 つの異なるフィールドを共有しています。ここまでは簡単です。基本クラスを作成し、この基本クラスから 4 つのフォームを派生させます。ただし、2 つの製品が特定の動作を共有しているとします。これは両方で同じです。もちろん、メソッドを定義するインターフェースを用意して、この 2 つの製品入力フォームにこのインターフェースを実装させることもできますが、インターフェースにはデフォルトの実装がないため、それを行うのはもったいないのではないでしょうか。各クラスに実装を提供する必要があるため、まったく同じ場合はコードの繰り返しになります。

もちろん、このメソッドを基本クラスに配置して、そこから 2 つのフォームを派生させることもできます。私のフォームが複数の共通要素を共有し、他の要素を共有していない場合、髪の毛を引き裂くことなくこれを表現するための最も健全で論理的な方法は何でしょうか?

高レベルの要件から低レベルのクラスや関数に至るまで、ソフトウェアの設計に役立つ作図プログラムを探しています。

多くの UML プログラムを見てきましたが、「拡大」してパーツの詳細を設計できる場合のように、同じマップ内で複数の詳細レベルで設計することはできません。

そのような設計に役立つプログラムは存在しますか? 同じマップ上で高レベルと低レベルで設計できるプログラムはありますか?

設計で直面している問題と非常によく似ているため、さまざまな形式の実数を検証する問題を検討しています。

実数は、さまざまな形式の組み合わせで提供されます。たとえば、次のようになります。1.先頭に符号がある/ない2.小数点がある/ない（小数点がない場合は、小数点以下の桁数を事前に合意できます）3.基数10またはベース16

各組み合わせを許可する必要があるため、2x2x2=8の組み合わせがあります。新しい条件が課されるたびに、複雑さが指数関数的に増加することがわかります。

オブジェクト指向デザインでは、通常、数値形式ごとにクラスを割り当て（たとえば、この場合は8つのクラスがあります）、各クラスには個別の検証関数があります。ただし、新しい条件ごとに、必要なクラスの数を2倍にする必要があり、すぐに悪夢になります。

手続き型プログラミングでは、3つのフラグ（つまり、has_sign、has_decimal_point、number_base）を使用して、検証する実数のプロパティを識別します。検証用の単一の関数があります。そこでは、フラグを使用してその動作を制御します。

}

繰り返しになりますが、関数がifステートメントとフラグで雑然となると、複雑さはすぐに手に負えなくなります。

私はあなたが以前にこの性質の設計問題に出くわしたと確信しています-振る舞いの違いをもたらす多くの独立した違い。コードを完全に保守不可能にすることなく、どのようにしてソリューションを実装できたのか、非常に興味があります。

ブリッジパターンのようなものが役に立ちましたか？

私は従業員の目標 Web アプリケーションに取り組んでいます。

リード/マネージャーは、チーム メンバーと話し合った後、チーム メンバーの目標を設定します。これは、組織が従う評価サイクルに応じて、毎年/半年ごと/四半期ごとです。

問題は、期間ベースのフィールドを追加するか、前四半期/年のデータをアーカイブするためのより良いアプローチです。ユーザーが以前の目標 (それほど頻繁ではないアクティビティ) を見たい場合、その日付に属するアーカイブを一時テーブルに復元し、従業員に表示することができます。

始めるべきポイント

アーカイブ: データベースのサイズを縮小し、データベース クエリを簡素化し、誰かが古いデータを見ようとしたときにオーバーヘッドを追加します。

期間ベースのフィールド/テーブル: クエリでの 1 つ以上の追加の結合。以前のデータは現在のデータと同様に扱われるため、古いデータを取得する際のオーバーヘッドはありません。

PS: これはスペース コストではありません。私のポイントは、これは Web アプリであり、組織内のすべての従業員がピーク時に検索/更新するため、パフォーマンスに関して何らかの最適化を達成できるかどうかです。期間を削除すると、クエリがはるかに簡単になります。ありがとう