問題タブ [decoupling]

システムAがシステムBにデータを送信する2つのシステムがあります。各システムが互いに独立して実行でき、もう一方がダウンしてもどちらも爆発しないことが要件です。問題は、デカップリング要件を満たしながら、システムAがシステムBと通信するための最良の方法は何かということです。

システムBには現在、dbテーブルのデータをポーリングし、挿入された新しい行を処理するプロセスがあります。

提案されている設計の1つは、システムAがシステムbのdbテーブルにデータを挿入し、システムBに既存のプロセスで新しい行を処理させることです。質問は、このソリューションが2つのシステムを分離する要件を満たしているかどうかです。データベースはシステムBの一部と見なされ、システムAが使用できなくなり、システムAが爆発する可能性がありますか？

もう1つの解決策は、システムAがデータをMQキューに入れ、MQから読み取り、システムBのデータベースに挿入するプロセスを用意することです。しかし、これは単なる余分なオーバーヘッドですか？最終的に、MQキューはdbテーブルよりもフォールトトレラントですか？

ロギングを行うメソッド属性がいくつかあります。私たちのロギング コードはインターフェイス (ILog) の背後にあり、実装ではなく、属性がそのインターフェイスのみに依存するようにしたいと考えています。これは、テスト容易性や依存関係の逆転に関するものではなく、コンポーネントの結合をクリーンに保つためのものです。

例として、次のような Web (Mvc) 固有の属性がある場合があります。

LogFactory は具体的な実装 Log.cs に依存しています。これは、私の Web DLL を具体的な実装を含む DLL に結合するという不幸な効果をもたらします。つまり、システム全体がより硬直的で壊れやすくなります。

このような依存関係が明らかになる他の場所では、IOC コンテナを使用して注入します。これはまさに私が属性でやりたいことですが、どうすればよいかわかりません!

それで、私の質問は次のとおりです。インターフェイスの背後にある .NET Framework 属性に具体的な依存関係をどのように注入できますか (できれば StructureMap のような IOC コンテナーを介して - しかし、機能するものは何でも問題ありません)。

アプリでNSNotificationsを使用して、コードを分離します。

通知の名前として文字列を使用するときにコンパイラが助けてくれるようにしたいのです。つまり、文字列を間違って入力した場合は、コンパイラに教えてもらいたいのです。

これに通常の文字列を使用しても機能しません。コンパイラは、入力"myNotificaion"した場合にそれが本当に意味することを認識しないため"myNotification"です。

これを行う1つの方法は、＃definesまたはconst NSString変数を使用することですが、これは、元のクラスまたはグローバルに含まれるファイルのいずれかで、ファイルで宣言する必要があることを意味します。

それらが元のクラスで宣言されることの問題は、通知がリッスンされるすべての場所に含まれる必要があるため、私が望まない結合を作成することです。

グローバルファイルの問題は、ファイルが長くて乱雑になる可能性があり、無関係なものがたくさん含まれる可能性があることです。

この結合や乱雑さなしにこれを達成する方法はありますか？

私は最近、Robert C. Martin (別名 Uncle Bob) の本を非常に熱心に読んでいます。彼が話していることの多くは、私にとって本当に命の恩人であることがわかりました (関数のサイズが小さい、物事の非常にわかりやすい名前など)。

まだ解決できていない問題の 1 つは、コードの結合です。私が何度も抱えている問題の 1 つは、たとえば配列をラップするようなオブジェクトを作成することです。あるクラスでいくつかの作業を行いますが、別のクラスで作業を行うには別のクラスを呼び出す必要があります。同じデータを 3 ～ 4 レベルの深さまで渡していますが、このオブジェクトが渡されるすべての場所を把握するのは難しいため、意味がないように思われます。私にはたくさんの依存関係があります。これは良い習慣ではないようです。

誰かがこれに対処するより良い方法を知っているかどうか疑問に思っていました.Bobのアドバイスは（おそらく私が誤解しているのですが）、より多くのクラスを作成する必要があるため、状況を悪化させているようです. ありがとうございます。

編集：実世界の例をリクエストする（そうでなければ、それを理解するのは難しいことに完全に同意します）：

これはもっと理論的な質問です。ロギングは、ロギングを主な目的としないクラス内に存在する必要がありますか？

これは、数値の計算を実行するものすべての簡単なインターフェイスです。

これは、計算を実行し、いくつかのロギングを行うICalculationインターフェースの実装です。これは非常に実用的なアプローチだと思います。コンストラクターが計算のドメインで通常は見られないものを受け入れることを除けば、インラインロギングは間違いなく邪魔になりません。

ReallyIntenseCalculationからすべてのロギングコードを削除した後、コードには明確な単一責任のように見えるものが含まれるようになりました。

さて、ReallyIntenseCalculationの内部ログ機能を削除しました。その機能を外部化する方法をどのように見つけることができますか。デコレータパターンを入力します。

ICalculationを装飾するクラスを作成することで、ログをミックスに戻すことができますが、そうすると、ReallyIntenseCalculationのプライベートメソッド内で行われていたより詳細なログの一部が損なわれます。

ロギングデコレータを持つことのその他の考えられる長所と短所は何ですか？

複数のアプリを含むプロジェクトに取り組んでおり、ニュース記事用のニュース アプリを含めたいと考えています。

ただし、ニュース記事をカスタム アプリのオブジェクトにリンクしたいのですが、オープン ソースのニュース アプリを使用してニュースを実行します。

現時点では、選択したニュース アプリをハッキングして、ForeignKey 関係をモデルに追加するだけです。

つまり、ウィジェット モデルを使用したウィジェット アプリ

次に、エントリ モデルがウィジェット モデルに直接リンクされたニュース アプリ

これを行うより良い方法はありますか？ニュースアプリを最新バージョンに更新したい場合、明らかに私のハックを上書きしてしまうからです。

カスタム モデルからのリンクを取得できますが、ワークフローは実際には

1. ニュース記事を追加
2. リンク先のウィジェットを選択

いいえ

1. ニュース記事を追加して保存
2. リンク先のウィジェットを見つける
3. ニュース記事へのリンク

2 つのアプリを分離しようとしています。

1. 場所 - 場所 (町、国、場所など) に関する詳細を含むアプリ
2. ディレクトリ - 興味のある場所 (ショップ、鉄道駅、パブなど) の詳細を含むアプリ - すべて分類されています。

との両方locations.Locationにdirectory.Item緯度/経度座標が含まれており、特定の緯度/経度座標から一定の距離内にあるアイテムを見つけることができます。

次の URL 構造を使用したいと思います。

/locations/<location_slug>/directory/<category_slug>/

しかし、ディレクトリ アプリを位置情報アプリに依存させたくありません。

ディレクトリ アプリでこのようなビューを使用するために、この URL を変換するにはどうすればよいですか?

回避策は、これを翻訳する新しいビューをどこかに作成することですが、どこに配置すればよいでしょうか? それがディレクトリ アプリに入る場合は、それを位置情報アプリと組み合わせました。その逆も同様です。

この回避策のコードをプロジェクトの URL ファイル内に配置することをお勧めしますか? したがって、両方のアプリを避けますか? このようにすることに問題はありますか？

名前の競合を避けるために、C++ ライブラリは名前空間を使用する必要があることは理解していますが、既に次のことを行う必要があるためです。

1. #include正しいヘッダー (または、使用するクラスを前方宣言します)
2. これらのクラスを名前で使用する

これら 2 つのパラメーターは、名前空間によって伝達される同じ情報を推測しないでください。名前空間を使用すると、3 番目のパラメーター (完全修飾名) が導入されるようになりました。ライブラリの実装が変更された場合、変更が必要になる可能性があることが3 つあります。これは、定義上、ライブラリ コードと私のコードとの間の結合の増加ではありませんか?

たとえば、Xerces-C を見てください。Parser名前空間内で呼び出される純粋仮想インターフェイスを定義しますXERCES_CPP_NAMESPACE。Parser適切なヘッダー ファイルをインクルードし、名前空間をインポートするか、宣言using namespace XERCES_CPP_NAMESPACE/定義の前にXERCES_CPP_NAMESPACE::.

コードが進化するにつれて、別のパーサーを優先して Xerces を削除する必要があるかもしれません。私は、純粋仮想インターフェースによるライブラリ実装の変更から部分的に「保護」されています (ファクトリを使用してパーサーを構築する場合はなおさらです) が、Xerces から別のものに切り替えるとすぐに、次のことを行う必要があります。私のコードをくまなく調べて、すべての私のコードとコードを変更してusing namespace XERCES_CPP_NAMESPACEくださいXERCES_CPP_NAMESPACE::Parser。

最近、既存の便利な機能をライブラリに分割するために既存の C++ プロジェクトをリファクタリングしたときに、これに遭遇しました。

foo.h

foo.cpp

当時、ほとんど無知 (そして部分的に怠惰) が原因で、 のすべての機能はuseful.libグローバル名前空間に配置されていました。

の内容が大きくなるuseful.libにつれて (そしてより多くのクライアントがこの機能を使用し始めた)、 からすべてのコードをuseful.libと呼ばれる独自の名前空間に移動することが決定されました"useful"。

クライアント.cppファイルは簡単に修正できますusing namespace useful。

foo.cpp

しかし、.hファイルは本当に労働集約的でした。using namespace useful;ヘッダー ファイルを挿入してグローバル名前空間を汚染する代わりに、既存の前方宣言を名前空間にラップしました。

foo.h

数十 (そして数十) のファイルがあり、これは大きな苦痛でした! それほど難しいことではなかったはずです。明らかに、設計および/または実装のいずれかで何か間違ったことをしました。

ライブラリ コードが独自の名前空間にある必要があることはわかっていますが、ライブラリ コードがグローバル名前空間にとどまり、代わりに#includes?

(1)でListインターフェースの実装がスワップできることは理解しています。(1)は必要に応じてアプリケーションで使用されることが多いようです (私自身は常にこれを使用しています)。

誰かが（2）を使用しているかどうか疑問に思っていますか？

また、実際に (1) を (2) よりも使用する必要がある状況 (つまり、(2) では不十分な場合。インターフェースやベスト プラクティスなどへのコーディングは別として) の頻度 (例を教えてください) はどれくらいですか?

現在、いくつかのWebアプリケーションを開発しており、デザイナーがサインオフしたペーパープロトタイプを静的なWebページに変換できるようにしています。ページ間にハイパーリンクを設定することに加えて、設計者は静的jsonファイルからデータをフェッチすることでページ上の要素を更新するためのjquery呼び出しの追加を開始しました。デザイナーが完成したら、完成したWebページ、CSS、およびJavaScriptファイルを渡します。次に、サーバー側の開発者はページを編集し、ローカルの静的jsonドキュメントへの参照を、同じjsonデータ構造を返すライブjsonurlへの参照に置き換えます。

私の質問：GUI設計をサーバーサイド開発から切り離し、統合の時間と労力を削減する効率的な方法は何ですか？いくつかの例：

• 開発者に、デザイナーのプロトタイプWebページのすべてのjson参照を手動で変更してもらいますか？
• デザイナーのページを静的データと動的データの使用の間で簡単に切り替えることができるように、どこかにグローバル変数を追加しますか？
• Webサーバーから実行されているとき、またはどこかのフォルダーから提供されているときをWebページに自己認識させますか？