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

システムを設計するとき、他のモジュールで使用されているモジュール（ロギング、データベースアクセスなど）の問題にしばしば直面します。問題は、これらのコンポーネントを他のコンポーネントに提供する方法です。依存性の注入またはファクトリパターンの使用の2つの答えが考えられます。ただし、両方とも間違っているようです： 工場はテストを困難にし、実装の簡単な交換を許可しません。また、依存関係を明示しません（たとえば、データベースを使用するメソッドを呼び出すメソッドを呼び出すメソッドを呼び出すという事実を知らないメソッドを調べています）。 Dependecyインジェクションは、コンストラクター引数リストを大幅に膨張させ、コード全体にいくつかの側面を塗りつけます。典型的な状況は、半分以上のクラスのコンストラクターがこのように見える場合です(....., LoggingProvider l, DbSessionProvider db, ExceptionFactory d, UserSession sess, Descriptions d) 問題がある典型的な状況を次に示します。データベースからロードされたエラー記述を使用する例外クラスがあり、ユーザーセッションオブジェクトにあるユーザー言語設定のパラメーターを持つクエリを使用します。したがって、新しい例外を作成するには、データベースセッションとユーザーセッションを必要とする説明が必要です。したがって、例外をスローする必要がある場合に備えて、これらすべてのオブジェクトをすべてのメソッドにドラッグする運命にあります。 このような問題にどのように取り組むのですか？

81 design  dependency-injection  dependencies 

私が所属するチームは、当社のプラットフォームと統合するために会社のパートナーが使用できるコンポーネントを作成します。 そのため、（サードパーティの）依存関係を導入する際には細心の注意を払う必要があることに同意します。現在、サードパーティの依存関係はなく、フレームワークの最も低いAPIレベルを維持する必要があります。 いくつかの例： フレームワークの最も低いAPIレベル（.NET標準）を維持する必要があります。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があるということです。 JSONを（デ）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを実行中です。これは、フレームワークAPIの上位レベルで利用可能です。 標準ライブラリのHTTP実装に依存したくないため、標準ライブラリのHTTPフレームワークのラッパーを実装しました。 同じ理由で、XMLとの間でマッピングするためのコードはすべて「手作業で」記述されます。 私たちはそれをやりすぎだと感じています。これは私たちの速度に大きな影響を与えると思うので、これにどう対処するのか疑問に思っています。

54 architecture  .net  dependencies  third-party-libraries  code-ownership 

2つの異なるコードベース（AndroidとNode.js Webアプリ）を使用した2つの主要な依存関係関連の危機がありました。AndroidリポジトリはFlurryからFirebaseに移行する必要がありました。これには、Google Play Servicesライブラリの4つのメジャーバージョンの更新が必要でした。同様のことが、HerokuがホストするNodeアプリでも発生しました。このアプリでは、実稼働スタック（cedar）が廃止され、cedar-14にアップグレードする必要がありました。PostgreSQLデータベースも9.2から9.6に更新する必要がありました。 これらのアプリの各依存関係はほぼ2年間古く、一部が廃止されて「日没」期間に達したとき、それらを更新または置換することは大きな頭痛の種でした。過去1〜2か月で30時間以上かけて、すべての競合と壊れたコードをゆっくりと解決してきました。 明らかに物事を2年間放置するのは長すぎます。特に、Herokuのようなプラットフォームプロバイダーを使用している場合、テクノロジーは急速に動きます。本格的なテストスイートと、Travis CIのようなCIプロセスがあり、更新から多くの当て推量を取り除くと仮定しましょう。たとえば、アップグレード後に関数が削除され、それを使用している場合、テストは失敗します。 依存関係を更新する頻度、または依存関係を更新するタイミング 強制されたため更新しましたが、何らかの先制的なアプローチの方が良いようです。マイナーバージョンがリリースされたら更新する必要がありますか？メジャーバージョン？更新が利用可能な場合、毎月ですか？どうしても犠牲になったような状況を避けたい。 PS-私の個人的なRailsプロジェクトの1 つでは、Gemnasiumと呼ばれるサービスを使用します。これは、セキュリティの脆弱性などを通知できるように、依存関係を追跡します。これは素晴らしいサービスですが、私が言及したプロジェクトの依存関係を手動で確認する必要があります。

30 dependencies  dependency-management 

何年にもわたる社内プロジェクトでC＃/。NETを使用してきた数年間で、1つのライブラリが有機的に成長して1つの巨大なものになりました。それは「Util」と呼ばれ、あなたの多くがあなたのキャリアでこれらの獣の1つを見たと確信しています。 このライブラリの多くの部分は非常にスタンドアロンであり、別々のプロジェクトに分割することができます（オープンソースにしたい）。ただし、これらを個別のライブラリとしてリリースする前に解決する必要がある大きな問題が1つあります。基本的に、これらのライブラリ間に「オプションの依存関係」と呼ぶものがたくさんあります。 これをより適切に説明するには、スタンドアロンライブラリになるのに適したモジュールのいくつかを検討してください。CommandLineParserコマンドラインの解析用です。XmlClassifyクラスをXMLにシリアル化するためのものです。PostBuildCheckコンパイルされたアセンブリに対してチェックを実行し、失敗した場合はコンパイルエラーを報告します。ConsoleColoredString色付きの文字列リテラルのライブラリです。Lingoユーザーインターフェイスの翻訳用です。 これらのライブラリはそれぞれ完全にスタンドアロンで使用できますが、一緒に使用する場合は、便利な追加機能が必要です。たとえば、との両方が必要なビルド後のチェック機能CommandLineParserをXmlClassify公開しますPostBuildCheck。同様に、はCommandLineParser、を必要とする色付き文字列リテラルを使用してオプションドキュメントを提供することを許可し、をConsoleColoredString介して翻訳可能なドキュメントをサポートしLingoます。 したがって、重要な違いは、これらがオプション機能であることです。ドキュメントを翻訳したり、ビルド後のチェックを実行したりせずに、プレーンで色付けされていない文字列でコマンドラインパーサーを使用できます。または、ドキュメントを翻訳可能にすることもできますが、それでも色付けされません。または、色付きで翻訳可能です。等。 この「Util」ライブラリに目を通すと、ほとんどすべての潜在的に分離可能なライブラリには、それらを他のライブラリに結び付けるようなオプション機能があります。これらのライブラリを依存関係として実際に必要とする場合、このものはまったく解りません。1つだけを使用する場合は、基本的にすべてのライブラリが必要です。 .NETでこのようなオプションの依存関係を管理する確立されたアプローチはありますか？

26 .net  dependencies  modules 

これと似たような質問がありますが、まったく同じではありません。 私のアプリのユーザーは、使用したい方法に必要な依存関係でアプリをインストールしたいと思います。そのため、たとえば、MongoDBに永続化する場合はMongo関連のライブラリのみがインストールされますが、Redisに永続化する場合はRedis関連のライブラリのみがインストールされます。使用しないライブラリをダウンロードしてインストールさせたくありません。 を使用して開発目的でそれを行うことができることは知っていますがdevDependencies、これはそれよりもさらに進んでいます。上記の質問の答えが示すように、これはPython setuptools extras_requireとClojureのleiningenプロファイルにより密接に関連しています。npmでそのようなことはありますか？依存関係を指定するより汎用性の高い方法のプロファイルにdevDependenciesすべきだと本当に思いdevます。

23 node.js  dependencies 

オープンソースプロジェクトを作成し、Google CodeまたはGitHubを使用していて、Luaなどのライブラリを使用したい場合、どのようにすればよいですか？ 依存関係をリポジトリに含める必要がありますか？ 依存関係は、プロジェクトの他の部分と同じビルドスクリプト内からビルドする必要がありますか、それとも別のビルドスクリプトからビルドする必要がありますか？ ライブラリをコンパイルする前にインストールする必要はありません。

23 open-source  version-control  dependencies 

私はSOまたはここでいくつかの答えを探していましたが、結果なしで、あなたに尋ねる理由です。 アプリのサーバー部分とクライアント部分など、2つの異なるプロジェクトがあると仮定しましょう。私は自分のパートを開発していますが、友人は2番目のパートを作成しています。しかし、私たちの両方のようないくつかの共通のインターフェイスを使用する必要があるUserか、AccountInfoまたはChangableAccount順番に互換性を確保するために何でも...。たとえば、クライアントがユーザーデータをサーバーに送信する場合、サーバーは同じクラスで動作する必要があります。インターフェイスなどでも同じです。さらに、共通のインターフェイスに変更がある場合は、両方のプロジェクトでコードを新しい状況に合わせて調整する必要があります。 私が今見ることができる唯一の解決策は、すべての一般的なものが定義されている1つの余分なプロジェクトを作成することです。私たちと私の友人は、このプロジェクトをメインプロジェクト（クライアントまたはサーバー）への依存関係として追加する必要があります。共有プロジェクトは何らかのバージョン管理システムで管理できるため、常に最新の状態になります。 他にどのような解決策を提案しますか？このような問題はプロのアプリでどのように解決されますか？

17 java  dependencies  integration  dependency-management 

PHPフレームワークとフレームワークの上にCMSを作成しました。CMSはフレームワークに依存していますが、フレームワークはCMSファイル内の自己完結型フォルダーとして存在します。GitHubでそれらを個別のプロジェクトとして維持したいのですが、フレームワークを更新するたびにCMSプロジェクトを更新するのが面倒になりたくありません。理想的には、これらのファイルを物理的にコミットするのではなく、CMSに何らかの方法でフレームワークファイルをプルして事前定義のサブディレクトリに含めるようにしたいと思います。 これはGit / GitHubで可能ですか？もしそうなら、それを機能させるために何を知る必要がありますか？私は非常に基本的なレベルのGitを使用していることに留意してください。Eclipse用のGitプラグインを使用してリポジトリを作成し、コミットし、GitHubに接続できます。私は現在、プロジェクトでソロで作業しているので、これまでGitについてこれ以上学ぶ必要はありませんでしたが、将来的に他の人にGitを公開したいと思います。 また、依存関係のあるプロジェクトの理想的なワークフローは何でしょうか？そのテーマに関するヒントも大歓迎です。私の設定についてさらに情報が必要な場合は、コメントでお尋ねください。

14 php  git  github  dependencies 

n層アーキテクチャと依存性注入を備えた中規模のソフトウェアを考えると、ある層に属するオブジェクトは下位層のオブジェクトに依存することができますが、上位層のオブジェクトには決して依存しないと言えます。 しかし、同じレイヤーの他のオブジェクトに依存するオブジェクトについてどう考えるべきかわかりません。 例として、3つのレイヤーと画像内のオブジェクトのような複数のオブジェクトを持つアプリケーションを想定してみましょう。明らかに、トップダウンの依存関係（緑の矢印）は問題ありませんが、ボトムアップ（赤い矢印）は問題ありませんが、同じレイヤー内の依存関係（黄色の矢印）はどうでしょうか。 循環依存関係を除き、発生する可能性のある他の問題と、この場合に階層化アーキテクチャがどれだけ違反されているかについて興味があります。

12 architecture  dependencies  layers 

昨日、私はRails 5 APIプロジェクトに取り組んでいました。このプロジェクトでは、タグ付きのacts-as-taggable-onライブラリを使用して、タグを付けることができます（SEの質問など）。Rails 5は現在、アルファ版をサポートしています。現在、マスターにマージされるのを待っているバグを修正するためのPRがあります。このバグにより、機能ブランチが完了の途中で停止しました-ロードが壊れたため、ライブラリの機能を実装できませんでした。 簡単な修正として、レポジトリを複製し、PRと同じコードで問題を修正し、バグ修正が最終的にマスターにマージされるまで、Gemfile（依存バージョン管理ファイル）を自分のGithubフォークに向けました。 修正が簡単だった（そして誰かがすでにそれを行っていた）ので幸運に思ったので、問題を回避することができました。しかし、このライブラリがアプリケーションの開発にとって重要だったらどうでしょうか？私の開発を止めていたバグ修正が他の人々に広まっている問題ではなかったので、今回のようにすぐに修正が反映されなかった場合はどうでしょうか？ この機能は、他の依存機能の開発の前に完了する必要があると想像してください-その状況で何をしますか？私にとって、タグ付けが他のすべてが依存している次の開発フレーズにとって絶対に重要だった場合、どうすればタグ付けの依存関係が私の構成にバグを起こすのでしょうか？依存関係の重要な機能が機能の開発を妨げる場合、何をしますか？ そして、確かに、数時間または数日間のオフィスチェアでの剣闘は選択肢ではありません...

12 project-management  dependencies  time-management 

私たちはプロジェクトを行っていますが、プロジェクト間で多くのコードを再利用し、共通のコードを含むライブラリをたくさん持っています。新しいプロジェクトを実装するにつれて、一般的なコードを抽出してライブラリに追加する方法が増えています。ライブラリは互いに依存し、プロジェクトはライブラリに依存します。各プロジェクト、およびそのプロジェクトで使用されるすべてのライブラリは、参照しているすべてのライブラリの同じバージョンを使用する必要があります。ソフトウェアをリリースする場合、バグを修正する必要があり、長年、場合によっては数十年にわたって新しい機能を追加する必要があるかもしれません。約12のライブラリがあり、変更は多くの場合2つ以上にまたがり、複数のチームが複数のプロジェクトを並行して作業し、これらすべてのライブラリに同時に変更を加えます。 最近、gitに切り替えて、各ライブラリおよび各プロジェクトのリポジトリを設定しました。stashを共通のリポジトリとして使用し、機能ブランチで新しい作業を行い、プルリクエストを作成し、レビュー後にのみそれらをマージします。 プロジェクトで対処しなければならない問題の多くは、いくつかのライブラリとプロジェクト固有のコードを変更する必要があります。多くの場合、ライブラリインターフェイスの変更が含まれますが、その一部には互換性がありません。（これが怪しいと思うなら、私たちはハードウェアとインターフェイスし、特定のハードウェアを汎用インターフェイスの後ろに隠します。他のベンダーのハードウェアを統合するたびに、現在のインターフェイスが予期しなかったケースに遭遇するため、それらを改良する必要があります。）たとえば、プロジェクトを想像しP1たライブラリを使用してL1、L2とL3。L1また、使用していますL2とL3、とL2用途L3にも。依存関係グラフは次のようになります。 <-------L1<--+ P1 <----+ ^ | <-+ | | | | +--L2 | | ^ | | | | +-----L3---+ ここで、このプロジェクトの機能に変更が必要でP1ありL3、のインターフェースを変更することを想像してくださいL3。これらのライブラリを参照するプロジェクトP2をP3ミックスに追加します。それらをすべて新しいインターフェイスに切り替え、すべてのテストを実行し、新しいソフトウェアを展開する余裕はありません。それでは、代替手段は何ですか？ 新しいインターフェースを実装する L3 プルリクエストをL3してレビューを待ちます 変更をマージする の新しいリリースを作成する L3 の新しいリリースをP1参照することで機能の作業を開始し、機能のブランチにL3機能を実装しますP1 プルリクエストを行い、これをレビューして、マージします （私はちょうど私がスイッチに忘れたことに気づいたL1とL2新しいリリースに。そしてそれはと並行して行われる必要があるので、私も、どこでこれを固執するかわかりませんP1...） これは、この機能を実装するための退屈でエラーが発生しやすい非常に長いプロセスであり、独立したレビューが必要であり（レビューがはるかに困難になります）、スケーリングがまったく行われず、私たちがビジネスを停止する可能性がありますプロセスが行き詰まってしまい、何もできなくなります。 しかし、あまり多くのオーバーヘッドなしで新しいプロジェクトに新しい機能を実装できるプロセスを作成するために、どのように分岐とタグ付けを使用するのでしょうか？

11 git  branching  dependencies  scm  tagging 

私のjarを使用するすべてのJavaプロジェクトは、ほぼ確実に、私のjarにも依存関係として含まれている別のjarへの追加の依存関係があります。 問題は、他のjarに複数のバージョンがあることです。 プロジェクトの2番目のjarのバージョンが私のjarの2番目のjarのバージョンと異なる可能性が高い場合に、発生する可能性のある問題を回避するにはどうすればよいですか？ 私のjarファイルを追加するために、ユーザーが特別なクラスローディングトリックを実行するという面倒なことをしたくありません。 その共通の依存関係のすべての可能なバージョンについて、jarのさまざまなバージョンの束を作成する必要がありますか？そして、あなたはちょうどあなたがたまたま持っている2番目のjarの同じバージョンを使用する私のjarのバージョンを選択するだけですか？ これを処理するよりスマートな方法はありますか、そして人々が衝突することなく私のjarをより簡単に使用できるようにしますか？

10 java  patterns-and-practices  versioning  project-structure  dependencies 

1つのパブリックメソッドSend()といくつかのプライベートメソッドを持つクラスがあります。いくつかのWebサービスを呼び出し、応答を処理します。処理はプライベートメソッドで行われます。 コードを単体テストしたい。私の理解では、単体テストではコードを分離してテストする必要があります（つまり、サプライヤーの応答をモックアップします）。 また、プライベートメソッドを単体テストする必要はないと考えていますが、Send（）メソッドをテストするだけでは、コードは分離してテストされておらず、サプライヤの反応に依存しています。 その後、モック応答でテストできるように、プライベートメソッドを公開する必要がありますか？私はクラスだけがそれらを呼び出す必要があるので、それは悪い習慣のようです。 基本的な質問であれば、申し訳ありませんが、単体テストはかなり新しいものです。 私はc＃とVS2010を使用しています

10 unit-testing  dependencies 

多くの（ほとんど？）AngularJSの人々は、AngularJSアプリを多くのモジュールに分割することを提唱しているようです。 Brian Fordは彼のブログで、レイヤー（コントローラー、サービスなど）ごとのパッケージ化は「ばかげた」概念であると既に述べているので、ここでは説明しません。（http://briantford.com/blog/huuuuuge-angular-appsを参照してください。） ただし、アプリを機能ごとにモジュール化するとします。おそらく、これらの機能モジュールをロードするための標準のappモジュールに加えて、usersモジュールとmessagesモジュールがあります。ユーザー機能に関連するルートをユーザーモジュールに、メッセージ関連のルートをメッセージモジュールに慎重に配置します。今、私の心の中で、あなたはngRouteの各機能モジュールに依存関係を作成しました。したがって、各モジュールは、依存関係の配列に「ngRoute」をリストする必要がありますよね？ 残念ながら、AngularJSはそれを台無しにすることを非常に簡単にします。あなたの場合はアプリのモジュールがロードの両方のユーザーとメッセージが、唯一のユーザーのリストを依存関係として「ngRoute」、それは実行時に問題ではない：$ routeProviderはまだで、あなたの設定機能の中に注入されるメッセージの本質的により解決された、ユーザーのモジュールのngRouteへの依存。 私の問題は、さまざまな機能モジュールをロード/参照する「アプリ」モジュールの一般的なパターンにある可能性があります。推移的な依存関係と同様に、このパターンは私にとって意味があります。問題なのは、Angularの特定の実装が、モジュールがそのモジュールの依存関係を間接的に参照しない場合をマスクできることです。モジュールは特定のアプリのコンテキストで機能する可能性があります（モジュールが別の「アプリ」モジュールによって参照されており、その依存関係も直接または間接的に参照されているため）。ただし、モジュールを別のアプリにコピーすると、失敗します。依存関係がないため。 ほとんどの人は、usersモジュールが基本的にmessagesモジュールの依存関係になっているという事実をあまり考慮しないだろうという印象を受けます。しかし、それは私が過去を見るのに苦労している問題です。私にとって、機能モジュール間にこれらの混乱する依存関係を作成する可能性がある場合、それはモジュール化の正味の利点を実際に減少させ、アプリのすべての機能のすべてのコンポーネントをカプセル化する単一のアプリモジュールを用意するだけです。

9 javascript  dependencies  angularjs 

数か月の間に、現在すべてのプロジェクトに組み込んでいるゲーム開発のための小さなフレームワークを作成しました。 フレームワークは、SFML、LUA、JSONcpp、およびその他のライブラリに依存しています。オーディオ、グラフィック、ネットワーキング、スレッディングを扱います。いくつかの便利なファイルシステムユーティリティとLUAラッピング機能があります。また、文字列解析ヘルパーや数学ユーティリティなど、多くの便利な「ランダム」ユーティリティメソッドがあります。 私のプロジェクトのほとんどはこれらの機能をすべて使用していますが、すべてを使用しているわけではありません。 ファイルシステムとネットワーク機能のみを使用する自動アップデーターがあります ネットワーク機能のないゲームを持っています JSONcppを必要としないプロジェクトがあります これらの文字列/数学ユーティリティのみが必要なプロジェクトがあります つまり、SFML / LUA / JSON共有ライブラリは、たとえ使用されていなくても、すべてのプロジェクトに含める必要があります。プロジェクト（非圧縮）のサイズはこのように10MB以上で、そのほとんどは未使用です。 代替策は、フレームワークを多くの小さなライブラリに分割することです。これは、はるかに効果的でエレガントになると思いますが、より多くのDLLファイルとプロジェクトを維持する必要があります。 フレームワークを多数の小さなライブラリに分割する必要があります。 グラフィックス スレッディング ネットワーキング ファイルシステム 小さいユーティリティ JSONcpp utils LUA utils これは最良の解決策ですか？

9 libraries  game-development  workflows  dependencies  utilities