問題タブ [decoupling]

JavaScript はほとんどの Web ソリューションでますます重要な役割を果たしていますが、JS コードをビューの仕様から分離することは、サーバー側のコードよりもはるかに難しいことがわかりました。

メンテナンスの負担を軽減し、マイナーなビューの変更に対して可能な限り回復力を持たせるために、JS コードを分離するために人々はどのような手法を使用していますか?

具体的な例を提供するために、次のようなビューがあります。

JS 部分は 2 つのファイルに分割されます。1 つ目は「ビジネス ロジック」クラスで、2 つ目は主に配線に使用されます。

そして配線部分：

上記のコードの問題は、ビューの外観 (存在しなければならない要素 ID、構造など) と密接に結びついていることですが、それを改善する方法については良い考えがありません。

この道を進み続けると、JS ファイルは、あらゆる種類のビュー固有のものと組み合わされた適切にカプセル化されたロジックの混乱になってしまうように思えます。

これは私が望むことができる最善の方法ですか、またはこの混乱の一部を回避するために適用できるテクニックはありますか?

これを改善する方法に関する私自身のアイデアは、サーバー側で生成されたある種の「要素セレクター」JS クラスを構築することを中心に展開しています。これにより、クラスと要素 ID への文字列参照をそれほど多く使用せずに JS を記述できます。しかし、それをどのように生成するのか、または最終的に維持するのが悪いのかどうかはわかりません。

私はこのバックボーンモデルを持っています:

対応するビュー:

アプリケーションには、csv データがロードされる一般的なデータソースもあります。

モデル属性が変更されるたびに、変更イベントを発生させる前に、その属性の組み合わせのデータがロードされているかどうかを確認したいと思います。

私の質問は次のとおりです。バックボーン モデルとビューからデータ ソースを切り離して、注入されたモック データを簡単に試すことができるようにする良い方法は何ですか?

コード例は C# ですが、これは一般的な OO の質問です。

オブジェクト指向のルールに従って、クラスの結合を最小限に抑え、可能な限りメンバーを非公開にする必要があることなどを知っています。

次の例を検討してください。

プログラムの文字通りすべての面で使用されるある種のデータセット（System.Data.DataSetについては話していません）を持つ難解なプログラムを作成しています。実際、このプログラムは基本的に、データ セットをロード、表示、操作、および保存するためだけに存在します。さらに、一度にロードできるデータセットは 1 つだけであり、プログラムが開いたときにロードされます。

オブジェクト指向のルールに厳密に従えば、

ただし、たとえば にpublic static Dataメンバーを格納する可能性があります。Program

一方で、大幅に増加したクラス結合のために、わずかに短い関数シグネチャを交換しました。一方、実質的にすべての関数にDataパラメーターを渡すことはなくなりました。

正しい答えはおそらく次のとおりです。可能な限りクラスの結合を避けます。ローカル データ変数は単なるポインターであるため、メモリ オーバーヘッドは無視できます。また、クラスが分離されているため、後で別の場所で使用できます。

現実的に言えば、Data クラスの構造は別のアプリケーションでは驚くほど異なる可能性が高いため、このプログラムからクラスを取り出して、微調整なしで別の場所にドロップできるわけではありません。ドロップインできるような方法でクラスを作成するために必要な余分な時間と労力は、利害関係者に正当化するのが難しい場合があります。

私は現在、この種のプログラムに取り組んでおり、OO-canon アプローチを使用しました。データ パラメーターは必要な場所に渡されます。将来のコードの再利用のためにデータ セットを一般化するために、IData インターフェイスとのクラス結合を最小限に抑えました。アプリケーションを考えると、このコードが再利用されることはないとほぼ確信しています。これらの追加のインターフェイスと抽象化がなければ、プログラムはエンド ユーザーに関する限りまったく同じように機能していたでしょうが、私にとっては頭痛の種と開発時間が大幅に削減されていたでしょう。

これについてあなたはどう思いますか？クラスが後で別の場所で使用されているのを確認できない場合は特に、できる限りクラスが分離されるように、インターフェイスと一般化を作成するために余分な時間を費やすことは正当だと思いますか?

クラスのシリアライゼーション コードをどこに配置するかについて、私はしばしば困惑し、この件に関する他の人の考えを知りたいと思っていました。

Bog の標準シリアライズは簡単です。問題のクラスを装飾するだけです。

私の質問は、装飾されたプロパティを盲目的にシリアル化するのではなく、さまざまなプロトコルまたはさまざまな形式にシリアル化され、プロセスにいくつかの考え/最適化が必要なクラスに関するものです。

すべてのコードを独自のクラスの 1 つの形式に関連付ける方がクリーンだと感じることがよくあります。また、新しいクラスを追加するだけでフォーマットを追加することもできます。例えば。

ただし、これは多くの場合、他のクラスが効果的にシリアル化するために、MyClass がより多くの内部を外部に公開する必要があることを意味します。これは間違っていると感じ、カプセル化に反します。それを回避する方法があります。たとえば、C++ ではシリアライザーをフレンドにすることができます。また、C# では特定のメンバーを明示的なインターフェイスとして公開することもできますが、それでも気分は良くありません。

もちろん、他のオプションは、 MyClass にさまざまな形式との間でシリアル化する方法を知ってもらうことです。

これはよりカプセル化されて正しいように感じますが、書式設定をオブジェクトに結合します。MyClass が知らないコンテキストのために、外部クラスがより効率的にシリアル化する方法を知っている場合はどうなるでしょうか? (おそらく、多数の MyClass オブジェクトが同じ内部オブジェクトを参照しているため、外部シリアライザーはそれを一度だけシリアライズすることで最適化できます)。さらに、新しい形式が必要な場合は、新しいクラスを作成するだけでなく、すべてのオブジェクトにサポートを追加する必要があります。

何かご意見は？個人的には、プロジェクトの正確なニーズに応じて両方の方法を使用しましたが、特定の方法に賛成または反対する強い理由がある人がいるかどうか疑問に思いましたか?

デカップリングを最後まで行うと、DataAccess レイヤーをモデルからデカップリングする必要があるように見えます。しかし、その後、情報をデータアクセスレイヤーに渡すのは面倒になります...代わりに:

やります

それは単純化の目的を無効にしないでしょうか?

モデルをデータ アクセス レイヤーに渡すことは完全にクリーンなコードだと思いますが、分離されていません。

私はCSSコードを編集するための小さなjavascriptスクリプトに取り組んでいますが、他のブラウザーと比較して、Internet Explorerには、多くの...特殊性があることがわかりました。たとえば、document.stylesheetオブジェクトのrulesオブジェクトは、ほとんどのブラウザではcssRuleと呼ばれ、IEではruleと呼ばれます。

ここでやりたいのは、ウィンドウのサイズ（window.innerWidth＆document.body.clientWidth）を含むオブジェクトのプロパティの参照を割り当てて、IEオブジェクト名を使用する必要があるかどうかを毎回チェックしないようにすることです。 「通常の」もの。

それは良い/悪い考えですか？

質問を投稿する前に、私はそれについてもう少し考えて、解決策を思いつきました。

これを行う別の/より良い方法はありますか？

ありがとう

（ええ、これを行う必要はないことはわかっています。特に、小さなスクリプトを作成していて、パフォーマンスはそれほど問題ではないので、ほとんど興味があります。）

私は Microsoft XNA フレームワークを使用してゲーム プロジェクトに取り組んでいますが、この質問はクラス/システムの分離を伴う一般的なものです。

ここに示すように、クラス（この例に合わせて簡略化）があるとしましょう：

C# を使用する複数のプラットフォーム間で、できるだけ多くのコードを再利用したいと考えています。

Color構造体を直接参照する場合の問題は、この型が XNA アセンブリで定義され、コードと XNA の間に強い結合 (または依存関係) が作成されることです。

私が使用する他のフレームワークには、独自のプロパティと API のセットを持つ独自のColorオブジェクトがある場合とない場合があります。

XNAまたは他のフレームワークの実装を自動的に使用するために、同じソースファイルを「認識」させたいと思います。

IoC などの他のタイプのデカップリング メソッドは知っていますが、それは、異なるコンテキストで同じクラスを再利用するのではなく、異なるバージョンのシステム/クラスをプラグインすることを意味します。

これは可能ですか？そのようなシステムをポータブルに保つためにどのように提案しますか?

(ネイティブ C++ 開発で) 使用しているフレームワークが持つクラスをミラーリングする一連のクラスを定義するケースをいくつか見てきました (たとえば、ここで - Color を再度定義します)。これを後で必要に応じて異なるクラスを使用するためにマップします。

もう 1 つのオプションは、#IFDEF を使用して、クラスのヘッダーの using ステートメントをいじることです (XNA から他のプラットフォームに切り替える)。この場合の最良の代替手段は何ですか?

バックボーンにコレクションがあります...これを行っているinitializeメソッドで...このコレクションにアイテムが追加されたときにビューを再レンダリングしたいと思います。

このソリューションは完全に機能しますが、mycoworkerは、バックボーンが実行するように設計されたものに完全に反対していると言います。これを行うためのより良いアプローチはありますか、それともこれは大丈夫ですか？質問は少し主観的ですが、実際には、このようなことを正しく行う方法を知りたいと思います。フィードバックやアドバイスをありがとうございます。

答えに答える...まあ、オブジェクトモデルはもっと深いです。DiscussionViewには、トピックモデルのバックボーンコレクションであるtopicsプロパティを持つdiscussionModelがあります。各トピックには、返信モデルの返信コレクションがあります。トピックに返信が追加されたら、ディスカッションビューを再度レンダリングする必要があります。そのチェーンを正しく設定するにはどうすればよいですか？

54:53分の時点での彼の講演で、Rich Hickeyは、依存するプログラム部分を分離する手段としてのキューの使用について話している。デザインや柔軟性を向上させるために、次のJava擬似コードを重複排除する方法の例を教えてください。

saveObjectToDatabaseとsaveObjectToDatabaseは副作用のあるメソッドと見なすことができますが、computeB'sとcomputeC'の出力はにのみ依存しaます。

私はこの質問がかなり曖昧/広範であることを知っています。プログラムを大幅に複雑にすることなく、キューイングメカニズムを活用する方法を理解したいと思います。それでも、プログラムが正しい順序で正しいことを実行することを確認します。正しい方向へのポインタはありがたいです。

いくつかのAPIを表すライブラリのセットを想像してみてください。制御メカニズムの反転を使用することにより、具体的な実装が消費プロジェクトに注入されます。

これが状況です。特定の機能について他のAPIライブラリに依存するAPIライブラリがいくつかあります。したがって、APIライブラリ自体はある時点で結合されます。1つのAPIを変更すると、依存するAPIも変更され、対応する実装も変更する必要があるため、この結合は後で問題になる可能性があります。最悪の場合、かなりの数のプロジェクトが必要になります。そのうちの1つだけからの変更を反映するように変更されました。

今、私はこれに対して2つの可能な解決策を考えています：

• 関連するAPIライブラリを統合するモノリスAPIプロジェクトを作成します。

• 各ライブラリが他のAPIに依存するすべての機能のインターフェイスを提供するようにすることで、APIをさらに分離し、直接の依存関係を削除します。これにより、両方のライブラリで同様のコードが生成される可能性がありますが、IoCメカニズムを介して選択された実装に自由が与えられ、APIが互いに独立して改善できるようになります（APIが変更された場合、変更はその実装ライブラリにのみ影響し、他のAPIまたはその実装）。

2番目のアプローチの問題はコードの複製であり、その結果、参照する必要のあるAPIライブラリが多すぎる可能性があります（たとえば、.NETアプリケーションでは、各APIは個別のDLLになります。Silverlightなどの一部のシナリオではアプリケーションの場合、これはアプリのサイズ（ダウンロード時間とクライアントのパフォーマンス全体）の問題になる可能性があります。

状況に対するより良い解決策はありますか？いくつかのAPIライブラリを1つの大きなものにマージする方が良い場合とそうでない場合はいつですか？これは私が尋ねている非常に一般的な質問ですが、期限、見積もり、クライアントの要件、テクノロジーを少し無視して、最大のスケーラビリティと最小のメンテナンス時間の両方を達成することに基づいて適切なアプローチを決定できるようにしたいと思います。それで、どちらかのアプローチ、またはあなたが私に提案するかもしれない別のアプローチを選ぶ良い理由は何でしょうか？

編集：

その質問について何かを明確にしなければならないような気がします。APIを実装から分離するのではなく、APIを相互に分離することを念頭に置いています。したがって、たとえば、アクセス許可を検証するためのセキュリティAPIと、セキュリティAPIを使用（参照）するユーザーアカウントAPIがある場合、セキュリティAPIを変更すると、ユーザーアカウントAPIとその両方の実装を変更する必要があります。このように結合されるAPIが多いほど、より多くの変更を適用する必要があります。それは私が避けたいものです。