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

私が持っているabstract class A抽象メソッドを宣言しているがdoStuff。現在、を継承しAて実装するクラスが多数ありますdoStuff。 クラスのインスタンスはAFactory、ユーザー入力に基づいて実行時に初期化されます。元々、すべてのクラスには同じ単一のパラメーター（ユーザー入力）がありました。しかし今、私はAニーズを継承する新しいクラスだけである追加のパラメーターを持っています。 だから私はそれを次のロジックで分解します： ユーザー入力（AFactoryもちろん使用）に基づいてインスタンスを生成するインタープリタークラスは、この追加のパラメーターを認識していませんでした。 それをクラスインタープリタクラスにプッシュしようとすると、本当に厄介なことになります。それは、いつファクトリーに渡すかを知らなければならず、そもそもファクトリーを持つという全体の目的に反するためです。 それを何かに使うかもしれないと期待して盲目的にファクトリーに送ることも、かなり醜いようです。 私の現在の解決策：一方、にリファクタリングA.doStuff(Param param)することにしましたA.doStuff(AParams params)。 AParams必要なパラメータをすべて保持doStuffでき、興味がない場合は無視できます。これは私にとっても少し厄介なようで、WIN32APIで構造体を送信することを抑制します。この構造体は、醜く役に立たない多くのパラメーターを保持する可能性があり、私はそれが好きではありません。 この問題に取り組むよりエレガントな方法はありますか？それとも私が見落とし、これを解決したいくつかのデザインパターン？ 注： Java 1.7を使用しています クラスの名前は、理論上の設計上の問題を強調するためにばかげていますが、実際には、わかりやすく意味のある名前が付けられています。 私はかなり多くのことを検索しましたが、（このコードをXスローしている理由とは対照的に）特定の抽象的な理論的な問題をWebで検索するのは非常に難しいことがわかったExceptionので、とにかく尋ねることにしたので、これが複製。 編集1： 明確化：サブクラス固有の引数をdoStuffメソッドに渡す必要があります。 編集2： 私はKilian Fothの意図を完全には理解していなかったので、問題をよりよく説明し、解決策を理解するのに役立つJava疑似コードをいくつか書きました。そう： これは私の問題の骨組みです。 これは私のソリューションの骨組みです。 これは キリアンフォスの解決策かもしれないと思いますが、よくわかりません。

8 java  design  design-patterns  abstraction  abstract-class 

私は最近この例に出くわしました： 1,000回のうち999回の例外がスローされない場合、例外は1回だけ生成されます。一方、条件文は不必要に999回呼び出されているため、この場合は例外が優先されます。 このインスタンスではC＃ですが、一般的に言ってこれは本当ですか？以前は、try / catchステートメントには、条件の処理に費やされる時間と同じ独自のオーバーヘッドがあると想定していました。 確かに、通常は条件付きの場所にtry / catchブロックを投げるだけでコードを書くのはひどい方法ですが、リソースの観点からこのステートメントは成り立ちますか？

8 design  object-oriented 

私は単純なウィジェットシステム（単一ウィンドウ、固定サイズ）に取り組んでいます。各ウィジェットは、その親（つまり、ウィジェットを含むウィジェット）をコンストラクターに渡します。ただし、私がScreenと呼んだルートウィジェットを除きます。 そのアプローチが理にかなっているかどうか、私にはいくつかの疑問があります。以前使用したほとんどのウィジェットシステム（Qt、GTKなど）で実行したためですが、これらは私のものよりもかなり複雑であることに気付きました。 ウィンドウのサイズ変更はありません 子供のサイズに基づいてコンテナのサイズを設定する予定はありません メモリ管理には必要ないと思います（C ++を使用しています）。代わりに共有ポインタを使用できます（基本的にはJavaでの動作） ウィジェットがその親への参照を必要とする理由はありますか？ これを変更することは大きなリファクタリングです。そのため、先に進んでコンテナーとレイアウトを実装する前に、その親が必要かどうかをよく理解したいと思います。 編集：親はとにかくそのすべての子を知っていることに注意してください。子供も親を知る必要があるのか​​と思っています。

8 design  code-quality  gui  toolkit 

C＃を使用した.NETドメイン駆動設計：問題-設計-解決策を読んだところ、作成者が各集計ルートのドメインサービスを作成していることに気付きました。 ただし、ドメインサービスは対応するリポジトリのファサードにすぎませんでした。たとえば、これは彼の本のアプリケーションのコードサンプルです。 public static class CompanyService { private static ICompanyRepository repository; private static IUnitOfWork unitOfWork; static CompanyService() { CompanyService.unitOfWork = new UnitOfWork(); CompanyService.repository = RepositoryFactory.GetRepository<ICompanyRepository, Company>(CompanyService.unitOfWork); } public static IList<Company> GetOwners() { return CompanyService.GetAllCompanies(); } public static IList<Company> GetAllCompanies() { return CompanyService.repository.FindAll(); } public static void SaveCompany(Company company) { CompanyService.repository[company.Key] …

8 java  c#  design  object-oriented  domain-driven-design 

私は現在、レガシーシステムの重要なメソッドをリファクタリングしている最中です。作業を始めるまでテストはほとんどありませんでした。リファクタリング後に正しい作業ができるように、かなりの数のテストを追加しました。 今、私は最も重要な部分に遭遇しました：インジケーターを計算するアルゴリズム。それは何かのようなものです indicator = (OneNumberFromA + AnotherNumberFromB) / elapsedTime; ユニットテストでこの関数の正しい動作をテストするにはどうすればよいですか？ 関数には、プログラムが到達するいくつかのわずかに異なるアルゴリズムもありますが、すべての場合において、これelapsedTimeは結果に不可欠です。

8 design  unit-testing  refactoring 

1つのサービス内に2つのリポジトリを持つ方法は正しいですか？それはアプリケーションまたはドメインサービスですか？ Passport（政府ID）オブジェクトを含むべきPassengerオブジェクトがあるとします。PassengerRepositoryからPassengerを取得しています。PassengerRepositoryはサーバーへのリクエストを作成し、受信したデータを解析してリポジトリ内に保存するよりもデータ（json）を取得します。 PassportをEntityとして保存してPassportRepositoryに置きたいのですが、パスワードに関するすべての情報に、上記で受け取ったものよりもjsonの内部が含まれているため、混乱しました。 removePassport, addPassport, getAllPassengerなどのいくつかのメソッドでPassengerRepositoryとPassportRepositoryを含むPassengerServiceを作成する必要があると思います。 更新： したがって、より良い方法はPassportをVOとして表し、すべてのパスポートをPassenger集約内に格納することだと思います。ただし、別の質問があります。管理乗客のパスポートのメソッド（メソッドはサーバーAPIを呼び出す）をどこに置くべきですか。乗客の集合体のほうがいいと思います。

8 design  design-patterns  object-oriented  architecture  domain-driven-design 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 JavaのBigIntegerクラスに、数値リテラルを取得できるコンストラクターがないのはなぜですか？私はBigIntegerを使用するたびに、そして多くの場合、それらについて単に考えているだけで、これは不思議に思います。 Javaの設計者は、存在するはずの1つの圧倒的な便利さにもかかわらず、1つを除外しなければならなかったのはなぜでしょうか。

8 java  design  language-design  object-oriented-design 

コードからデータ構造を保存して、独自の、まだ未定義のタイプのファイルにファイルを保存するプロセスを記述しようとしています。ただし、ファイルの種類や構造を設計したことはありません。 一般的に言えば、デザインを始める前に考慮すべきことはありますか？ ここで認められた良い習慣はありますか？避けるべき悪い習慣は？ 絶対にすべきこと、すべきでないことはありますか？

8 design  file-structure 

私がチームで取り組んでいるほぼすべてのプロジェクトで、同じ問題が侵入しているようです。誰かがデータを必要とするUIコードを書き、データアクセスメソッドを書きます。 AssetDto GetAssetById(int assetId) 1週間後、他の誰かがアプリケーションの別の部分で作業してAssetDtoいて、「承認者」を含む必要がありますが、次のように書きます： AssetDto GetAssetWithApproversById(int assetId) 1か月後、誰かがアセットを必要としていますが、現在は「質問」（または「所有者」または「実行中のリクエスト」など）が含まれています。 AssetDto GetAssetWithQuestionsById(int assetId) AssetDto GetAssetWithOwnersById(int assetId) AssetDto GetAssetWithRunningRequestsById(int assetId) そして、そのようなメソッドGetAssetWithOwnerAndQuestionsByIdが出現し始めると、さらに悪化します。 現れるパターンが表示されます。オブジェクトは大きなオブジェクトグラフにアタッチされており、このグラフのさまざまな部分をさまざまな場所に配置する必要があります。 もちろん、ほとんど同じことをするメソッドがたくさんあるのを防ぎたいです。それは単にチームの規律の問題ですか、それともこれを防ぐために使用できるパターンがありますか？場合によっては、個別のメソッドを使用することが理にかなっている可能性があります。つまり、実行中のリクエストでアセットを取得するのはコストがかかるため、常にこれらを含めたくありません。そのような場合の対処方法は？

8 design  design-patterns  methods  method-overloading 

歴史 現在、私たちはオンライン支払いにいわゆるリダイレクトモデルを使用しています（支払人を支払いゲートウェイに送信し、そこで彼は支払いの詳細を入力します-ゲートウェイは成功/失敗のコールバックページに戻ります）。これは簡単でわかりやすい方法ですが、残念ながら非常に不便であり、お客様を混乱させることがあります（サイトを離れる、別のサイトに追加ログインしてクレジットカードの詳細を変更するなど）。 意図と問題の説明 現在、XML要求と応答の交換を使用する統合アプローチに切り替える予定です。私の問題は、処理中に発生する可能性のあるすべて（またはほとんど）の要求にどのように対応するかです。通常、単純さは堅牢であり、複雑さは壊れやすいことを念頭に置いてください。 例 ユーザーによる中止：ユーザーはクレジットカードの詳細を入力し、送信を押します。プロバイダーのゲートウェイへのXMLメッセージが送信され、応答を待ちます。ユーザーがブラウザで「停止」を押すか、ウィンドウを閉じます。 PHPのignore_user_abort（）はオプションかもしれませんが、それは信頼できますか？ ユーザーを「お待ちください」ページにリダイレクトすると、接続に依存しない実際のプロセッサへのAJAXまたはその他の要求が開かれます。 データベースがなくなる 非常に複雑に聞こえますが、たとえば、米国のWebサーバーと英国のDBの場合、これは発生し、また発生します。ユーザーが注文を一緒にクリックすると、支払い要求がプロバイダーに送信されましたが、応答をデータベース。個々のステップに応じて、PHPを使用して「トランザクション」のようなSQLを開始し、最後にのみコミットまたはロールバックするアプローチを使用できますか？その後、コミットもロールバックも発生しなかった場合、ユーザーを「ロック」して、ユーザーが再度支払うことを防いだり、不適切に支払いを説明したりしないようにすることができます。 また、技術的に他に何を検討する必要がありますか？たとえば、Worldpay、Realex、SagePayの統合例では、洞察が得られません。また、私の検索エンジンまたは私の検索用語は、これについて他の誰かの考えを見つけるのに十分ではありませんでした。 これにどのように取り組むかについての洞察をありがとうございました！

8 design  php  payment 

データアクセスレイヤー（DAL）と緊密に結合されたビジネスロジックレイヤー（BLL）があります。次のように呼び出します。 using (FooData data = new FooData()) { data.DoSomething(); } internalBLLだけがDALにアクセスできるように、すべてのデータクラスはであり、それらはロジッククラスと同じアセンブリにあることに注意することが重要です。 （ユニットテストを容易にするために）これらを分離するための1つのアイデアは、IFooDataのようなIDataClassインターフェイスを作成することです。インターフェイスを実装するためにデータクラスをパブリックにする必要があるため、最初は問題だと思いました。ただし、メソッドをパブリックにする必要がある場合でも、データクラスを内部に保持できるはずです。 public interface IFooData { void DoSomething(); } internal class FooData : IFooData // Notice the class is internal { public void DoSomething(); // Method is public, but that's ok because class is internal } したがって、メソッドがパブリックであっても、クラス自体は内部であるため、BLLアクセスのみを許可する必要があります。 このアプローチには本質的に問題がありますか？DALを公開して世界に公開することなく、ユニットテストのためにDALを抽象化するより良い方法はありますか？

8 c#  design  object-oriented 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私は1年生向けにコース「プログラミング入門」を教えています。設計によって選択されたビット単位のデータ型サイズが特定の既知の制限または重要な値につながる興味深い例を見つけたいと思います。 ここではいくつかの例を示します。 Bellテレプリンターは7ビットコード（後でASCIIとして受け入れられる）を使用していたため、電子メッセージの添付ファイルを7ビットデータのみを含むようにエンコードすることがよくありました。 32ビットアドレス空間の従来の制限により、32ビットシステムで使用可能な最大4GbのRAMサイズと、FAT32で最大4Gbのファイルサイズが発生します。 データ型の選択（特にそのバイナリ長）が現代のITの世界にどのように影響したか、他に興味深い例をいくつか知っていますか。 コメントでいくつかの議論の後に追加されました： 制限を克服する方法を教えるつもりはありません。1バイトで-127..0 .. + 127 o 0..255の値を保持できること、2バイトで0..65535の範囲をカバーできることを彼らに知ってもらいたい。上記のbase64エンコーディングなど。基本的なデータ型を学習しているだけなので、これらの型の「大きさ」についての適切なリファレンスを見つけようとしています。

8 design  architecture  file-systems  data-types  32-bit 

タスクのデザインをしているとき、私はこのしつこい気持ちと戦い続けます。それは、一般的なアウトラインであるだけでなく、結局は無視されるというものです。例を挙げましょう。 読み取り/書き込み操作が可能なデバイスのフロントエンドを作成していました。クラス図では、読み取りおよび書き込み機能を提供することは完全に理にかなっています。しかし、実際にそれらを書くことになったとき、コードが1行だけ変更された（読み取りと書き込みの関数呼び出し）文字通り同じ関数であることに気づきました。コードの重複を避けるために、区別するパラメーターを持つdo_io関数を実装しました。オペレーション。さようならオリジナルデザイン。 これはひどく破壊的な変更ではありませんが、頻繁に発生し、プログラムのより重要な部分でも発生する可能性があるため、少なくとも概要の場合よりも、一般的な概要よりも詳細に設計する必要があるかどうか疑問に思わずにはいられません。プログラムのアーキテクチャーになります（明らかに、APIを指定するときは、すべてを詳しく説明する必要があります）。 これは設計の経験不足のせいかもしれませんが、一方で「はるか先の計画をあきらめて、とにかく数日ですべてが変わる」というようなアジャイルな方法論があります。私がどう感じるか。 それでは、設計をどの程度正確に「使用」する必要がありますか

8 design 

拡張可能なWebアプリケーションをどのように実装しますか？私が考えているのは、プラグインサポートを提供するJenkinsやHudsonに似たWebアプリケーションです。プラグインを見つけてロードする方法は明らかですが、プラグインをアーキテクチャ全体に統合する方法はわかりません。特に以下の点については不確かです。 プラグインはどのようにビューを変更することができますか、例えばフォームに入力要素を追加しますか？ 私の最初のアイデアは、プラグインが特定のフォームのパーシャル/フラグメントを登録できるということです。 例：ユーザー登録ビューに表示される典型的なニュースレターチェックボックスフラグメントを登録するニュースレタープラグイン。 プラグインは着信要求にどのように反応しますか？ この場合も、直接的なアプローチは、特定の要求またはアクション（/ userへのPOST要求など）のリスナーを提供することです。 プラグインはどのようにしてデータを保持できますか？ これは、NoSQLデータストレージソリューションがリレーショナルデータベースよりも優れている状況であると想定しています。 拡張可能なWebアプリケーションに関して、コメント、アイデア、経験（デザインパターンもあるかもしれません）があれば幸いです。

8 design  architecture  web  jenkins  hudson 

私の現在の開発状況では、多くのDLL、実行可能ファイル、静的ライブラリがあります。DLLに何を入れるかをどのように決定しますか？実行可能ファイルには何を入れるべきですか？異なる実行可能ファイルに別々の機能があるのはなぜですか？私は答えが簡潔になることを望んでいますが、これはそれが思われるだろう主に意見が分かれたトピックです。 大規模なプロジェクト（複数の実行可能ファイル）のどこに機能が存在するかをどのように決定しますか？「グッドデザイン」から「モジュール性」、「管理者が要件ドキュメントに入れるものは何でも」まで、さまざまな回答を期待しています。

8 design  architecture  libraries