問題タブ [coupling]

私は、バックエンドとフロントエンドの間の緊密な結合という異端的な考えを固く信じています。ユーザーインターフェイスを生成するときに、バックエンドに関する既存の暗黙の知識を自動的に利用したいと考えています。たとえば、VARCHAR列の最大文字数が20文字の場合、GUIは、ユーザーが関連するフォームフィールドに20文字を超えて入力することを自動的に制限する必要があります。

また、データベーステーブルを定義したいORMや、ORMのためにすべてのテーブルに追加の数値ID列が必要なハックに基づいているORMには強い反感があります。

私はPythonデータベースフレームワークを少し調べましたが、SQLAlchemyが私の考え方に最も適していると結論付けることができると思います。

ここで、SQLAlchemy（または同等のもの）に自然に適合し、おそらく結合への欲求にも適合するWebアプリケーションフレームワークを見つける必要があります。「Webアプリケーションフレームワーク」とは、Pyhons、Django、TurboGears、web2pyなどの製品/プロジェクトを意味します。

たとえば、理想的には次のことができるはずです。

• 指示された場合、特定の列に入力するデータに適したフォームウィジェットを自動的に選択します。たとえば、列に10個の異なる値を持つ列への外部キーがある場合、ウィジェットは10個の可能な値をドロップダウンとして表示する必要があります
• INTEGER列などに文字列が入力されようとしているフィールドに文字列が入力された場合に、エンドユーザーに迅速なエラーフィードバックを提供するjavascriptフォーム検証コードを自動生成します。
• 最終的にDATE列になるデータのカレンダーウィジェットを自動生成します
• 関連する入力フィールドの空または空白のみのデータについて文句を言うjavascriptとしてNOTNULL制約をヒントします
• 関連する（単純な） CHECK制約に一致するjavascript検証コードを生成します
• プリペアドステートメントや外部から派生したデータの検証を使用して、SQLインジェクションを簡単に回避できるようにします
• 必要に応じて発信文字列を自動的にエスケープすることにより、クロスサイトスクリプティングを簡単に回避できます
• 制約に違反した場合に備えて、制約名を使用して、ユーザーフレンドリーなエラーメッセージを生成します。

これはすべて動的に行われる必要があるため、テーブルの調整はフロントエンドに自動的に反映されます。おそらくキャッシュメカニズムを使用して、すべてのモデルのイントロスペクションによってパフォーマンスが低下することはありません。つまり、データベースでモデル定義がすでに慎重に定義されている場合は、XMLファイル（または同様のファイル）でモデル定義を繰り返したくありません。

そのようなフレームワークはPython（またはそれに関しては任意の言語）に存在しますか？そうでない場合：上記の機能の一部を自分で追加した場合、いくつかのPython Webアプリケーションフレームワークのどれが最も邪魔になりませんか？

私はカップリングのメトリックを調べており、 DSMも調べています。

私が使用してきたツールの 1 つは、配布の単位であるモジュール (この場合は .net アセンブリ) との「モジュール」間の結合を調べます。

配布単位よりも、パッケージ (または名前空間) 間の結合に関心を持つべきだと思います。

パッケージ/名前空間間の結合にもっと関心を持つべきですか (抽象化は抽象化のみに依存し、具象型は抽象化に依存し、リファクタリングと拡張が容易になるように依存関係に循環がないことを確認してください)、または私ができるかどうかに関心を持つべきですか?変更されていない配布単位を更新する必要なく、新しいバージョンを展開できますか?

他の人は何を測定しますか？

価値があるのは、パッケージ/名前空間のカップリングに焦点を当てれば、ディストリビューションのカップリングのユニットが無料になるか、少なくとも簡単になるというのが私の直感です。

デメテルの法則は、自分が直接知っている対象にのみ話しかけるべきであることを示しています。つまり、他のオブジェクトと通信するためにメソッド チェーンを実行しないでください。これを行うと、中間オブジェクトとの不適切なリンクが確立され、コードが他のコードに不適切に結合されます。

良くないね。

解決策は、あなたが知っているクラスが、関係のあるオブジェクトに責任を委任する単純なラッパーを本質的に公開することです。

それは良い。

でも、それだとクラスの結束が弱くなるらしい。もはや、それが何をするかについて正確に責任を負うだけではなく、関連するオブジェクトのインターフェースの一部を複製することによって、ある意味でコードのまとまりをなくすデリゲートも持っています。

良くないね。

それは本当に結束力を低下させるのでしょうか？それは2つの悪の小さい方ですか？

これは開発の灰色の領域の 1 つで、境界線がどこにあるかを議論できる場所ですか、それとも、どこに境界線を引くか、その決定を下すために使用できる基準を決定するための強力で原則に基づいた方法はありますか?

コードで FxCop を実行すると、次の警告が表示されます。

Microsoft.Maintainability : 'FooBar.ctor は、9 つ​​の異なる名前空間からの 99 の異なる型と結合されています。メソッドを書き直すかリファクタリングして、クラスの結合を減らすか、メソッドを他の型のいずれかに移動することを検討してください。40 を超えるクラス結合は保守性が低いことを示し、クラス結合が 40 から 30 の間の場合は保守性が中程度であることを示し、クラス結合が 30 未満である場合は保守性が良好であることを示します。

私のクラスは、サーバーからのすべてのメッセージのランディング ゾーンです。サーバーは、さまざまな EventArgs タイプのメッセージを送信できます。

「HandleSignOut」および「HandleConnectionTest」メソッドにはほとんどコードが含まれていません。通常、別のクラスの関数に作業を渡します。

低結合でこのクラスを改善するにはどうすればよいですか?

基本的に低レベルのSlimDXラッパー ライブラリをラップし、XBOX 360 コントローラー用の簡単なマネージド API を提供する小さな XBox 360 ワイヤレス コントローラー マネージド インターフェイスを作成しました。

内部的には、クラスは N ミリ秒ごとにゲームパッドをポーリングし、コントローラーの基本的な状態の変化を検出するとイベントを発生させます。

私は、基本的に2つの悪のどちらか少ない方を選択することを余儀なくされているタイマーで行き詰まりを経験しています:

• XBox360GamePad クラス UI フレームワーク固有のものを作成します (つまり、WPF/WinForms のサポートはクラスでハードコーディングされ、クラスはこれらのフレームワークを参照する必要があります...)

• クラスを完全にフレームワークにとらわれないようにしますが、生成されたイベントに応じて UI を更新できるように、ユーザーに Dispatcher.Invoke / Invoke() 呼び出しをコードに振りかけるように強制します。

後者のオプション (コードを UI に依存しないものにする) を選択した場合、基本的には「汎用」の System.Timers.Timer または UI に依存しない任意のタイマーを使用します。その場合、UI を直接更新できないスレッドからイベントが生成/呼び出されることになります。つまり、WPF では、(醜い) Dispatcher.Invoke を使用して、360 コントローラー クラスから発生したすべての更新を発行する必要があります。 .

一方、XBox 360 Controller クラス内で DispatcherTimer を使用すると、大騒ぎせずに UI を直接更新できる作業コンポーネントがありますが、今ではコントローラー クラス全体が WPF に結合されており、それなしでは使用できません。 WPF に依存 (つまり、純粋なコンソール アプリ)

私が探しているのは、フレームワークにとらわれず、あらゆる種類の Dispatcher.Invoke() 手法に頼らなくても UI を更新できる、ある種のソリューションです...たとえば、共有ベースがあった場合すべてのタイマーのクラス、関連するシナリオに従って、タイマーを依存関係として何らかの形で注入できます..誰かがこの種の問題にうまく対処したことがありますか?

互いにデータを必要とすることが多いが、必ずしも同じカテゴリに属していない疎結合システムを設計するにはどうすればよいでしょうか?

たとえば、古いペット ショップの例をさらに一歩進めて、ペット ショップのフランチャイズを作成してみましょう。各ペットショップには、連絡先情報、プロモーション、現在の在庫を掲載した独自の Web サイトがあります。

フランチャイズ オーナーは、すべてのフランチャイズ ペット ショップのリストと、連絡先情報、および場合によっては企業サイトで利用できる数枚の写真を掲載したいと考えています。彼らは、この情報を更新できるようにしたいと考えており、更新があれば自動的に双方向にプッシュされます。また、自動化された方法ですべての店舗のサイトにプロモーション情報を提供したいと考えています。

したがって、この例では、在庫リストは店舗によって「所有」され、連絡先情報は両方のエンティティによって部分的に「所有」され、プロモーション情報は HQ によって「所有」されます。任意の理由により、このすべてのデータを同じ場所に保存することはできません。

このような状況に対処するためのベスト プラクティスや一般的な戦略はありますか?

管理されたアセンブリのセットを調べて、ある名前空間のタイプのいずれかが別の名前空間のタイプに依存しているかどうかを通知できるユーティリティはありますか？たとえば、名前空間があり、内のMyApp.BusinessRules何にも直接アクセスしたくないMyApp.GUIが、両方の名前空間が同じアセンブリにあるとします。私の目標は、さまざまな結合ルールが破られていないことを確認するカスタムMSBuildタスクを記述できるようにすることです。

これまでのところ、これを行う可能性があると思われる唯一のツールはNDependですが、もっと簡単な解決策があるかどうか疑問に思っています。

デザインの問題に直面しているプロジェクトのようなグラフィックボードを構築しています。

メイン クラスは Board で、形状を描画するときにマウス イベントを処理するキャンバスです。また、グリッド磁気を有効にする currentShape や snapFlag などのコンテキスト変数もあります。

形状の移動/サイズ変更/回転を処理するために、ObjectHandles (flex) と呼ばれるサードパーティのオープン ソース ツールを継承します。

onMove 関数などの内部関数の一部をオーバーライドするために、ObjectHandles メイン クラスを拡張する baseShape があります。

シェイプを作成するとき (マウス ダウン、移動、マウス アップ)、これはボードによって処理され、ボード自身のスナップ フラグを認識します。

var mouseUpPoint:Point = boardCanvas.globalToLocal(new Point(event.stageX, event.stageY)); var snapMouseUpPoint = snapPoint(mouseUpPoint.x, mouseUpPoint.y);

私のオーバーライドされた onMove メソッドでは、形状が Board snap フラグとその変化を認識できるようにしたいと考えています。これを行うにはどうすればよいですか?

snap をチェックできるように、basicShape コンストラクターのパラメーターとして Board を渡しますか?

フラグをパラメーターとして渡し、何らかの方法ですべての形状が変更をリッスンするようにしますか?

最もクリーンなソリューションは何ですか?

どうもありがとう。

以下に示すように、コンストラクターで検証オブジェクトをインスタンス化しているため、set メソッドでユーザーの電子メールを検証できます。このアーキテクチャはベスト プラクティスですか、それとも欠陥がありますか? User クラスを Validation クラスに直接依存させないようにすることはできますか?

関連する質問: set メソッドが無効な値を受け取った場合、適切な応答は何ですか? 2 つのオプションが表示されます

1. 値を設定せずに false を返す
2. とにかく値を設定しますが、オブジェクトのエラー プロパティを設定します。（したがって、 User.Error が設定されている場合、何か問題が発生したことがわかります）

オブジェクト プロパティの値が常に有効であることを保証できるので、#1 がベスト プラクティスだと思います。正しい？

私は C++ の経験を積むために単純なゲームを書いていますが、ポリモーフィズムがほとんど機能するのに機能しないという考えがあります。このゲームでは、Partyは をかなり直線的に移動しますが、道路で にMap遭遇することがあります。Forkフォークは (基本的に)です。当初は、メンバー関数std::vector<location*>に次のようなコードを作成する予定でした。Party

しかし、次のいくつかの変形がより良いのではないかと思っていました:

Fork は実際には Location から派生しており、いくつかの新しい function をオーバーロードしていますgetNext()。しかし後者の場合、location(低レベルの構造) は、「これをバックアップする」のではなく、ユーザーにメッセージを表示するものでなければなりませlocationんUserInterface::*。

あなたの意見は？