問題タブ [tightly-coupled-code]

OSをサポートしていない組み込みシステム用のプロジェクトをC++で書いています。ライブラリのサポートはほとんどありません。非常にベアメタル。したがって、かなりの量のコードが緊密に結合されています（たとえば、ソフトウェアによってトリガーされる割り込みとそのすぐ上のレイヤー）。

私が行っていることの一部には、シリアルポート構成の変更が含まれます。これにより、PC側（UI側）とマイクロプロセッサー（アクティビティ側）で同時に変更が行われます。私はこれまでのところ、非常に注意深いインクリメンタルタイプの開発（ピースごとにそれをはめ込む）で大丈夫です。ただし、エンジニアリングの意味でコードが機能することについて、より自信を持ってやりたいと思います。

このような状況では、どのような方法論/フレームワークをお勧めしますか？

編集：

Tern、Inc.製のACore86ボードでAMD186 ESを使用しています。コンパイラ：パラダイム、無料版（ボードに同梱）。残念ながら、作業内容を変更するオプションはありません。

この Flex の質問に触発されて、モジュール内から親アプリのインスタンスでメソッドを呼び出すのではなく、親アプリにイベントをディスパッチすることをお勧めしますか? 私には、モジュールは親で利用可能なメソッドを認識すべきではないようです。そのようなアプローチは密結合につながるためです。

考え？

自己記述型/自動記述型のサービスは、SOA アーキテクチャの優れた点だと考えています。これは、(ほとんど) サービスを呼び出すために知っていることはすべてサービス コントラクト (WSDL など) に含まれているためです。

私にとって自己記述的ではないサービスのサンプルは、Facebook クエリ言語 (FQL http://wiki.developers.facebook.com/index.php/FQL )、または 1 つの文字列パラメーターで XML フローを交換して解析する Web サービスです。 XML と処理の実行。

技術的には、呼び出し元に技術的な影響を与えることなく実装を切り替えることができ、実装/バージョン間の互換性をビジネスレベルで処理できるため、最後のものはさらに技術的に分離されているように見えます。一方、強力なインターフェイスがない (サービスとそのバージョンに希薄化されている) と、サービスが既存の実装に密接に結合されます (サービスを交換し、完全な互換性を確保することがより困難になります)。

この質問は、SOA アーキテクチャで疎結合を実装する方法に関連しています

では、自己記述/自動記述サービスは、SOA アーキテクチャーで疎結合または密結合ですか? ESB に関する影響は何ですか?

任意のポインタをいただければ幸いです。

あなたの仕事の90％が、非常に大規模で非常に壊れたWebサイトで問題をトリアージすることだけであると想像してください。このWebサイトが、これまでに見た中で最も緊密に結合された、最もまとまりのないPHPコードで書かれていると想像してください。これは、元の開発者を「平手打ち」リストに追加するタイプのコードです。このWebアプリケーションが、4つの非常に異なるパーツ（1つは商用、2つは「再利用」、1つはカスタム）と、1トンの仮想ダクトテープとシムで構成されていると想像してください。ウェブサイトの主要なコンポーネントが実際に正しく機能していないものに依存しているタイプのプログラミング手法が含まれていると想像してください。これらの壊れたものを修正すると、通常、他のものが壊れます。あまりにも多くの悪い経験から、「名前」を分割するなど、Webサイトの一見無害な部分を変更することを知っていると想像してみてください。フィールドを2つの別々の「最初の」フィールドと「最後の」フィールドに分割すると、サイトがひざまずき、何時間ものロールバック、マージ、およびパッチが必要になります。何年にもわたって顧客にコードを捨てて最初からやり直すように懇願することを想像してみてください。しかし、エンタープライズグレードの絶望と手絞りに遭遇しました。次に、ASAP / EMERGENCYチケットを取得して、他のWebサイトでは4時間かかる新機能を実装することを想像してみてください。ただし、このサイトの方がよくわかっているので、40時間見積もり、それをすぐに実行して80時間請求しますが、クライアントは問題ありません。彼らのウェブサイトでそれに慣れています。何年にもわたって顧客にコードを捨てて最初からやり直すように懇願することを想像してみてください。しかし、エンタープライズグレードの絶望と手絞りに遭遇しました。次に、ASAP / EMERGENCYチケットを取得して、他のWebサイトでは4時間かかる新機能を実装することを想像してみてください。ただし、このサイトの方がよくわかっているので、40時間見積もり、それをすぐに実行して80時間請求しますが、クライアントは問題ありません。彼らのウェブサイトでそれに慣れています。何年にもわたって顧客にコードを捨てて最初からやり直すように懇願することを想像してみてください。しかし、エンタープライズグレードの絶望と手絞りに遭遇しました。次に、ASAP / EMERGENCYチケットを取得して、他のWebサイトでは4時間かかる新機能を実装することを想像してみてください。ただし、このサイトの方がよくわかっているので、40時間見積もり、それをすぐに実行して80時間請求しますが、クライアントは問題ありません。彼らのウェブサイトでそれに慣れています。

他にも想像しておくべきことがいくつかあります。

• 現在、テストはまったくありません。
• ログインにはgoogleteenの異なるレイヤーがあります。一部の顧客は、実際にはWebサイトのさまざまなセクションに3つの異なるアカウントを持っています
• 私が「密結合」と言うとき、私はinclude/requireステートメントのループがおそらくケルトノットのようにマップされることを意味します
• 「最もまとまりがない」とは、MVCのように編成されているものもありますが、実際にはMVCではありません。場合によっては、URIAがファイルBにどのようにマップされているかを確認するだけで数時間かかることがあります。
• UIは「目立たない」と「アクセスできない」のように書かれており、当時の流行語でした

それをすべて想像すると、適度なレベルのテストカバレッジを達成しようとする価値さえありますか？または、この架空のシナリオで、与えられたものでできる限り最善を尽くし続け、クライアントがこれらの日のいずれかを書き直すことに同意し、それからあなたが書き始めることができることを願って、祈って、おそらく犠牲にする必要がありますテスト？

補遺

あなたの多くがそれを持ち出したので：私は私がこれまでに持っていたあらゆる機会に書き直しの可能性に近づきました。私が一緒に仕事をしているマーケティング担当者は、彼らのコードががらくたであることを知っています、そして彼らはそれが彼らが最初に行った「最低入札」会社のせいであることを知っています。私はおそらく、請負業者としての私の限界を超えて、彼らがこのサイトのホスピスケアを提供するために私に莫大なお金を費やしていること、そしてそれを最初から再開発することによって彼らは非常に迅速にROIを見るだろうと指摘しました。とにかく彼らが望んでいることを実際には行わないので、私はサイトをそのまま書き直すことを拒否するとも言いました。計画はBDDスタイルに書き直すことですが、すべての主要なプレーヤーを1か所に集めるのは困難であり、彼らが何を必要としているかはまだわかりません。いずれにせよ、私はそれが非常に大きなプロジェクトになることを完全に期待しています。

これまでのすべてのフィードバックに感謝します！

オブジェクトを処理し、それらを相互に通信させるための良い方法は何ですか？

これまでの私のゲームの趣味/学生はすべて小さいので、この問題は一般的にかなり醜い方法で解決され、緊密な統合と循環依存につながりました。これは、私が行っていたプロジェクトのサイズには問題ありませんでした。

しかし、私のプロジェクトはサイズと複雑さが増してきており、今度はコードを再利用して、頭をよりシンプルな場所にしたいと思っています。

Player私が抱えている主な問題は、一般的に、について知る必要のある線に沿っていることですMap。Enemyこれは通常、多くのポインタを設定し、多くの依存関係を持つことになり、これはすぐに混乱します。

私はメッセージスタイルシステムの方針に沿って考えてきました。しかし、ポインタをどこにでも送信しているので、これによって依存関係がどのように減少するかは実際にはわかりません。

^{PS：これは以前に議論されたと思いますが、それが私が持っている必要性だけを何と呼んでいるのかわかりません。}

これは私のオブジェクトです

Location オブジェクトと密接に結合されたビューがあります。

私は自分のproductcontentビューでProductContentと密接に結合されたビューを持っています

というエラーが表示されます

タイプ location の Model.ProductLocation を渡していますが、それでもエラーが発生するのはなぜですか?

MVC3 C# Razor を使用しています

特定のロジックがデータ アクセス層とビジネス ロジック層のどちらに属するかについて、同僚と議論しました。

シナリオは、BLL が動作するデータを必要とすることです。そのデータは主にデータベースに存在します。そのデータを (System.Runtime.Caching を使用して) キャッシュして、後続の要求ですぐに利用できるようにします。アーキテクチャは、DAL と BLL が同じボックスと異なるアセンブリ (同じソリューション内のプロジェクト) に存在するようなものです。そのため、ワイヤーを介して DAL をヒットするなどの懸念はありません。

私の主張は、キャッシュをヒットするかデータベースをヒットするかの決定は、DAL の問題であるということです。ビジネス ロジック層は、データがどこから来るかを気にする必要はなく、必要なデータを取得することだけを考えるべきです。

彼の主張は、データアクセスレイヤーは「純粋」で「愚か」であるべきであり、キャッシュとデータベースのどちらをヒットするかを決定するロジックは、ビジネスロジックレイヤーにある必要があるというものです。

私の意見では、彼が言っていることは、関心の分離を弱体化させ、目標が物事を疎結合に保つことである場合に、レイヤーをより緊密に結合させることです。データの移動先を決定する特定のプログラム/UI 関数である場合、BLL がこれを制御したい場所がわかりますが、ここではそうではありません。これは、データベースがプライマリ データ ストアである非常に単純なキャッシュ シナリオです。

考え？

私の状況でより良い解決策は何ですか、クラスがあまり結合されないようにクラスを設計する方法は何ですか？

いくつかの機能を提供するライブラリ（API）があります（たとえば、subscribeメソッドを使用してFX価格のストリーミングをサブスクライブします）。APIクライアントがあります。APIクライアントは、取得したい価格をAPIに通知します。APIは、メソッドを使用したいくつかのインターフェース（たとえばSubscriptionStatus）でフィードバックを提供しますSubscribeSuccess(Subscription) and SubscribeFailed(Subscription)。APIクライアントには、アクティブなサブスクリプションのリストがあります（List<Subscription> activeSubscriptions）。そして、APIクライアントがサブスクリプションの成功にのみ反応するようにしたい（サブスクリプションをリストに追加するだけ）。その他の場合-メッセージを印刷してログに記録するだけです。サブスクリプションリスナーとAPIクライアント間の関係を整理するための最良の方法は何ですか？オプションは次のとおりです。

1. APIクライアントインスタンスをサブスクリプションリスナーに渡して、呼び出すことができるようにしますapiClient.addSubscription(subscription)
2. APIクライアントは、実装SubscriptionStatusインターフェイスを実装し、それらのイベントを管理します（失敗、内部で成功：activeSubscriptions.add（subscription））。対照：アクションには多くの種類があり、すべてのアクションには独自のリスナーがあります。したがって、Apiクライアントは非常に大きなクラスになります。
3. 1つのメソッドで独自のインターフェースを定義SubscriptionSuccess(subscription)し、APIクライアントに実装させますか？
4. あなたのオプション？

トピックについての考えは大歓迎です！

ありがとう！

私のビジネス サービス クラスが SqlConnection を開くことを密結合と見なしますか?

実際、ビジネス サービスは具体的なデータ プロバイダーを認識する必要はありません。

パブリック クラス UnitService:

コードのカプセル化が低い場合、「密結合」の概念を理解できないようです。

誰かがこの概念を説明する「前」と「後」のコードを見せてくれませんか？