タグ付けされた質問 「coupling」

今週はソフトウェアパターン試験があり、研究対象のトピックの1つは、遠心性カップリングと遠心性カップリングです。 パッケージが他の多くのタイプに依存する場合、そのパッケージのCe（遠心性結合）が高いことを理解しています。 例えば： class Car{ Engine engine; Wheel wheel; Body body; } このクラスは、エンジン、ホイール、およびボディのタイプに依存するため、遠心性の高いカップリングになります。 一方、他のいくつかのパッケージ（車、飛行機、自転車）に依存している場合、タイプ「ホイール」のCa（求心性結合）は高くなります。 私たちの試験で考えられる質問の1つは、Efferent / Afferentカップリングがいつ良いか悪いかです。論理的には、プログラムが高いEfferent / Afferentカップリングのパッケージ/クラスを必要とするため、これは私には奇妙に思えます。 誰かが、高遠心性または求心性結合がいつ/どこで良い/悪いかの例を持っていますか?? ありがとう！

11 design-patterns  patterns-and-practices  coupling 

このスレッドに続いて、私は始めました シングルトンパターン クラスがどのように結合されているか、そして疎結合を達成するための最良の方法について考えさせられました。私は新しいプログラマー（最初の仕事を始めて4か月）であり、これが実際に私がこれに与えた最初の考慮事項であり、コンセプトを理解することに非常に熱心であることに留意してください。 では、疎結合と重結合を正確に構成するものは何ですか？私の現在の（そして最初のプロジェクト）では、ac＃winformsプロジェクトに取り組んでいます.GUIセクションはオブジェクトとイベントへのサブクリブを作成します標準のdatagridviewをラップして追加の機能を追加する）を作成し、それをGUIにアタッチしています。 私は本当に悪い習慣に陥り、コーディングが不十分になりたくないので、あなたの反応に感謝します。

11 language-agnostic  coupling 

主な問題 最も近代的なプログラミングプラットフォームはパッケージ管理のために持っている良いサポートを見て（と思うgem、npm、pipなど、）、それが促進し、疎結合アーキテクチャを作成するように、内部で開発されたパッケージで構成されたアプリケーションやシステムを設計する意味がありませんか？ 例 この例としては、データベースアクセス用のパッケージの作成や、システムの認証やその他のコンポーネント用のパッケージの作成があります。もちろん、これらも外部パッケージを使用します。次に、システムはこれらのパッケージをインポートして使用します-独自のコードベースにコードを含める代わりに。 考慮事項 私には、これはコードのデカップリングを促進し、保守性を支援するように思われます。ほとんどWebベースのデスクトップアプリケーションのようなものです（更新はほとんど自動的に適用され、単一のコードベースは単一の機能などに適用されます）。 これは合理的で健全なデザインコンセプトのように見えますか？これは、今日のアプリケーションを構造化する標準的な方法として実際に使用されていますか？

10 design  design-patterns  architecture  packages  coupling 

時々、オブジェクトは密結合される必要があるだけです。たとえば、CsvFileクラスはおそらくCsvRecordクラス（またはICsvRecordインターフェイス）と緊密に連携する必要があります。 ただし、私が過去に学んだことから、テスト駆動開発の主な理念の1つは、「一度に複数のクラスをテストしないこと」です。ICsvRecordつまり、の実際のインスタンスではなく、モックまたはスタブを使用する必要がありますCsvRecord。 しかし、このアプローチを試した後、CsvRecordクラスをモックアウトすると少し毛むくじゃらになることに気づきました。これにより、2つの結論のうちの1つに導かれます。 単体テストを書くのは難しい！それはコードの匂いです！リファクタリング！ すべての依存関係をモックアウトするのは不合理です。 モックを実際のCsvRecordインスタンスに置き換えると、状況ははるかにスムーズに進みました。他の人々の考えを探しているとき、私はこのブログ投稿を偶然見つけました。これは上記の＃2をサポートしているようです。自然に密結合されているオブジェクトの場合、モッキングについてそれほど心配する必要はありません。 私は道を外れていますか？上記の仮定2の欠点はありますか？デザインをリファクタリングすることを実際に考えるべきですか？

10 tdd  coupling  mocking 

最新のプログラムで人気のある高レベルのアーキテクチャの選択は、RESTベースのマイクロサービスシステムです。これには、疎結合、再利用の容易さ、使用できるテクノロジーの制限の制限、高いスケーラビリティなどのいくつかの利点があります。 しかし、そのようなアーキテクチャーで私が予測する問題の1つは、アプリケーションの依存関係が何であるかについての可視性が低いことです。たとえば、1組のREST呼び出しを毎日使用するアプリケーションがあるとします。このアプリケーションは、REST呼び出しの2番目のセットも使用しますが、四半期に1回だけです。過去1週間のログをスキャンすると、1日のカロリーはすべて表示されますが、四半期ごとの呼び出しは表示されません。リファクタリングの時期になると、四半期ごとの呼び出しが中断するリスクが高くなります。 このリスクを軽減し、疎結合アーキテクチャの依存関係をより詳細に可視化するために使用できるパターンまたはツールは何ですか？

9 architecture  rest  enterprise-architecture  microservices  coupling 

私はリアルタイムの地形レンダリングエンジンに取り組んでいます。QuadTreeクラスとNodeクラスがあります。QuadTreeクラスは、カメラの場所に応じてツリーを展開または折りたたみます。したがって、QuadTreeがNodeオブジェクトの存続期間を担当することは理にかなっています。問題は、その存続期間に関連付ける必要があり、QuadTreeとは何の関係もない多くのデータがあることです。これらのデータは相互に関連していなくてもかまいません。私は成功せずにクラスを正しく分離するクリーンな方法を探していました。すべての変更（場合によってはマイナーな変更も）には、いくつかのファイルを介した変更が必要で、ほとんどの場合、それに関連しないファイルが必要です。ようやく機能するように見えるものがありますが、それをあまりにも切り離そうとしているので、あまりメリットがないために複雑さが増しています。これは私がそれをした方法です： 私のQuadTreeクラスは、ツリー以外のものを処理するべきではありません。しかし、ノードを作成するたびに、これらのノードにデータを関連付ける必要があります。これはQuadTreeクラスで行うためにクラスを汚染するため、QuadTreeとこれらのデータを作成することを仕事とするクラスの間で通信するためのインターフェースを追加しました。この時点で、私はそれを正しい方法で行っていると思います。疑似コード： class QTInterface { virtual void nodeCreated( Node& node ) = 0; virtual void nodeDestroyed( Node& node ) = 0; }; class QuadTree { public: QuadTree( ...., QTInterface& i ) : i( i ) {} void update( Camera camera ) { // .... i.nodeCreated( node ); // .... i.nodeDestroyed( …

8 design  coupling 

通常、それらの間でリスト、セット、およびマップを交換するクラスを作成することにより、低結合を実現します。現在、Javaバッチアプリケーションを開発していますが、十分なメモリがないため、すべてのデータをデータ構造内に配置できません。データの1つのチャンクを読み取って処理し、次のチャンクに進む必要があります。したがって、読み取るデータがまだあるかどうかなどをどこかで確認する必要があるため、カップリングを低くすることははるかに困難です。 私が今使っているのは： ソース->プロセス->持続 処理するクラスは、読み込む行がまだあるかどうかをソースクラスに問い合わせる必要があります。 そのような状況でのベストプラクティスや有用なパターンは何ですか？ 私に言わなければ、自分自身を説明しているといいのですが。

8 java  design-patterns  programming-practices  patterns-and-practices  coupling