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

相互に循環依存する3つのクラスがあります。 TestExecuterはTestScenarioのリクエストを実行し、ReportGeneratorクラスを使用してレポートファイルを保存します。そう： TestExecuterはReportGeneratorに依存してレポートを生成します ReportGeneratorは、TestScenarioおよびTestExecuterから設定されたパラメーターに依存します。 TestScenarioはTestExecuterに依存しています。 それらの依存関係を削除する方法がわかりません。 public class TestExecuter { ReportGenerator reportGenerator; public void getReportGenerator() { reportGenerator = ReportGenerator.getInstance(); reportGenerator.setParams(this.params); /* this.params several parameters from TestExecuter class example this.owner */ } public void setTestScenario (TestScenario ts) { reportGenerator.setTestScenario(ts); } public void saveReport() { reportGenerator.saveReport(); } public void executeRequest() { /* …

33 design  object-oriented-design  circular-dependency  dependency-analysis 

私は自分のアプリケーションに取り組んでおり、立ち往生しています。機能を実装する必要がありますが、この機能を実装するための適切なアプローチが見つかりません。私は数日間それについて考えていました、そして、良い考えは来ませんでした。インターネットを検索してもインスピレーションは得られませんでした。 先に進む必要がありますが、何が最良かを知りたいです。 もっと考え、もっと待って、最良のアプローチを探し続けてください 時間を無駄にするのをやめて、貧弱なデザインから始め、すべてをテストでカバーする どう思いますか？前にも言ったように、私は自分のアプリケーションに取り組んでいます。期限はありませんが、できるだけ早くアプリのコーディングを終了したいと思います。

32 design 

プログラミングでは、最小原理の原理と呼ばれるものは何ですか？この概念は、優れたAPIの設計にどのように関係していますか？これはオブジェクト指向プログラミングのみに適用されるものですか、それとも他のプログラミング手法にも浸透していますか？これは、「メソッドで1つのことを実行し、それをうまく実行する」という原則に関連していますか？

32 design  design-patterns  object-oriented 

通知システムマネージャーを作成する必要があります。 私の要件は次のとおりです。 異なるプラットフォームで通知を送信できる必要がありますが、これは完全に異なる場合があります（たとえば、SMSまたはEメールのいずれかを送信できる必要があります）。 通知は、特定のプラットフォームのすべての受信者で同じ場合もありますが、プラットフォームごとの受信者（または複数）ごとの通知である場合もあります。 各通知にはプラットフォーム固有のペイロードを含めることができます（たとえば、MMSにはサウンドまたは画像を含めることができます）。 システムはスケーラブルである必要があり、アプリケーションまたはサーバーをクラッシュさせることなく、非常に大量の通知を送信できる必要があります。 これは2段階のプロセスです。最初に顧客がメッセージを入力し、送信先のプラットフォームを選択します。その後、リアルタイムで処理されるように通知を作成する必要があります。 次に、システムはプラットフォームプロバイダーに通知を送信する必要があります。 今のところ、私はいくつかの結果になりますが、どれだけスケーラブルであるか、またはそれが良いデザインであるかどうかはわかりません。 私は次のオブジェクトを（疑似言語で）しました： 汎用Notificationオブジェクト： class Notification { String $message; Payload $payload; Collection<Recipient> $recipients; } 次のオブジェクトの問題は、受信者が1.000.000だったらどうなりますか？Recipientオブジェクトが非常に小さい場合でも、メモリを大量に消費します。 受信者ごとに1つの通知を作成することもできますが、一部のプラットフォームプロバイダーはバッチで送信する必要があるため、複数の受信者で1つの通知を定義する必要があります。 作成された各通知は、DBやRedisなどの永続ストレージに保存できます。 これを後で集約してスケーラブルであることを確認するのは良いことでしょうか？ 2番目のステップで、この通知を処理する必要があります。 しかし、適切なプラットフォームプロバイダーへの通知をどのように区別できますか？ をMMSNotification拡張するようなオブジェクトを使用する必要がありabstract Notificationますか？または何かのようなNotification.setType('MMS')？ 大量の通知を同時に処理できるようにするには、RabbitMQのようなメッセージングキューシステムが適切なツールであると考えています。それは...ですか？ これにより、大量の通知をキューに入れ、複数のワーカーに通知をポップして処理させることができます。しかし、上記のように受信者をバッチ処理する必要がある場合はどうなりますか？ 次に、プラットフォームプロバイダーを接続して通知を実行するために、それぞれNotificationProcessor追加できるオブジェクトを担当することを想像します。NotificationHandlerNotificationHandler を使用しEventManagerて、プラグイン可能な動作を許可することもできます。 フィードバックやアイデアはありますか？ お時間をいただきありがとうございます。 注：私はPHPでの作業に慣れており、おそらく選択した言語です。 編集 （morphunrealの答えによる） 1秒間に送信するメッセージの数（現在/初期レベルを定義し、再設計する前にシステムが処理する必要がある最大レベルを定義します） システムのハードウェア制約（システムで使用可能なメモリ、CPUなど） ハードウェアはどのように拡張されますか（つまり、サーバーの追加、クラウドコンピューティングなど） どの言語/システムが通知を生成しますか？ 通知はプログラムで作成しますが、UIから作成するのは私自身です。 ジェネレーターはメッセージの受信者を知っていますか（？）、または他の手段で提供されていますか（つまり、特定のアラートタイプのビジネスルールは特定の受信者に送信されます） 特定の受信者、受信者のグループ（たとえば、タグシステムを使用）、またはプラットフォーム全体に対して通知を作成できる必要があります。 CC / BCC /開封確認を追加するためのビジネスルールはありますか はい。これは実際にはプラットフォーム固有であり、readまたはccはすべてのプラットフォームで利用できるわけではないことに注意してください。 …

32 design  architecture  performance  object-oriented-design  scalability 

私は、ソフトウェアデザインの観点から分析するオープンソースソフトウェアを選択する必要があるソフトウェアデザインクラスを受講しています。 それは大きなプロジェクトでなければなりません：100,000行以上のコード。 優れたソフトウェア設計に関する優れた洞察を得るために、非常によく設計され、設計されたソフトウェアを選択したいと考えています。 良い設計とは、意味のあるクラスとアーキテクチャ、（設計）パターンの適切な使用、抽象化の適切な使用、コンポーネントの適切な編成、コンポーネント間の高い凝集性と低い結合などを意味します。 私に提案するソフトウェアはありますか？ ソフトウェアには適切な設計が必要なだけで、設計を文書化する必要はありません。:) エンドユーザー用のアプリケーションである必要はありません...また、ライブラリ、ツールなどにすることもできます...

32 design  design-patterns  architecture 

新しい機能、つまり非重要/疑わしい機能について議論するとき、開発者からの良い態度は何ですか？ ある種のJavaのような言語を開発しているとします。上司は、「開発者がオブジェクトメモリを直接操作するにはポインターが必要です」と言っています。 開発者は想像を絶する複雑さとセキュリティの脆弱性を追加するため、アイデアを打ち倒すべきですか、それとも彼は求められていることをすべきですか？ これは良い例ではないかもしれませんが、ワークフローを中断するボタンを追加したり、プログラムの内部構造に反するなど、灰色の領域にあるものについてはどうでしょうか？ 通常のプログラマーにとって最適な「できる」対「できない」配布は何ですか？ 編集：質問は悪いボスに関するものではありません：D わずかに役立つかもしれないが、目立った量の問題を追加する新しい問題に人々がどのように取り組むのか、私はもっと興味があった。 一般的な態度は次のとおりです。 はい、それを行います、複雑さを台無しにします 多分 いいえ、一般的な手直しと含意は変更を正当化しません 優れた開発者の反応はどうでしょうか？

32 design 

「ビルダー」パターンは「テレスコープコンストラクター」アンチパターンに対処することに制限されていますか、それとも不変オブジェクトの複雑な作成のより一般的な問題に対処すると言うことができますか？ StringBuilderクラスは、その名の単語「ビルダー」を持っているが、それは伸縮コンストラクタとは何の関係もありません、それは単に私たちは不変オブジェクトのコンストラクタに渡す必要があることを、すべてのデータを収集するのに役立ちます。 私には、答えは非常に明確な「はい」のように見えますが、このトピックについては意見の相違があるようです。 私はこの質問に答えていました：プログラマーSE：コンストラクターでの正当な「本物の仕事」？OPが複雑なツリーを含む（おそらく不変の）オブジェクトを作成したい場合、「ビルダー」パターンのアイデアがポップアップし、それを調査中に「StringBuilder」スタイルのオブジェクト作成と言われるこのQ＆Aを見つけましたではない私には明確ではない理由のために、「ビルダー」パターンの適用、：stackoverflowの-のStringBuilderとビルダパターン。（その質問に答えた人は、私が知る限り説得力のあるポイントを作ることができませんでした。）

31 design  design-patterns  builder-pattern 

JDKの元のバイナリ検索アルゴリズムは32ビット整数を使用し、次の場合にオーバーフローバグがありました(low + high) > INT_MAX（http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html） 。 （符号付き）64ビット整数を使用して同じバイナリ検索アルゴリズムを書き換えた場合、low + high10 ^ 18バイトのメモリを持つことは物理的に不可能であるため、INT64_MAXを決して超えないと想定できますか？ （符号付き）64ビット整数を使用して物理量を表す場合、アンダーフローとオーバーフローは発生しないと想定するのは合理的ですか？

31 design  algorithms 

私が理解しているように、トップダウン設計は、最小の構成要素が定義されるまで、抽象的な高レベルの概念をより小さなコンクリートのわかりやすい部品に改良することです。一方、ボトムアップは低レベルのパーツを定義し、システム全体が形成されるまで徐々に高レベルのブロックを構築します。 実際には、2つの方法を組み合わせることをお勧めします。ドメインの知識、その関係、および制約を完全に指定するために、高レベルの仕様から始めます。問題が十分に理解されると、最小の構成要素が作成されてシステムが構築されます。 のプロセス： 要件仕様の作成 設計仕様を作成します（図を使用） 実装する 届ける 繰り返します（反復開発では、各フェーズでチャンク全体を行うのではなく、少しずつ繰り返し行い、顧客の動的な要件に適応するために毎日ミーティングを行います） 私には完全に正常に見えます（仕様としての計画）。それには欠点がありますが、それが反復開発を行った理由です：1つのフェーズに時間を費やす代わりに、変更（場合によっては毎日）を受けるドメイン知識のあらゆる可能性を調査するための要件分析ではなく、少し分析します、少し設計してから実装します。 別の方法は、各反復がミニウォーターフォール形式であり、分析が数日（または1週間）で行われることです。同じことが設計にも当てはまります。残りの時間は実装に費やされます。反復的な開発と組み合わせたトップダウンアプローチには本質的に何か問題がありますか？ 彼のエッセイであるプログラミングボトムアップでは、ポール・グラハムは完全にボトムアップからビルドを奨励するか、ボトムアップからプログラムするように思われますが、要件分析/設計段階ではありません。 経験豊富なLispプログラマーは、プログラムを異なる方法で分割します。トップダウン設計と同様に、彼らはボトムアップ設計と呼ばれる原則に従います-問題に合うように言語を変更します。 私が知る限り、彼が意味したのは、Lisperがまだトップダウン設計を実行しているが、プログラムはボトムアップであるということです。彼が書いた別のポイント： ボトムアップ設計とは、同じプログラムを異なる順序で書くだけではないことを強調する価値があります。ボトムアップで作業すると、通常は別のプログラムになります。単一のモノリシックプログラムの代わりに、より抽象的な演算子を備えたより大きな言語と、その中に記述されたより小さなプログラムを取得します。まぐさの代わりに、アーチを取得します。 これは、Lispでプログラムを作成している間に、一般的なツールになるということですか？

31 design  c++  lisp 

ソフトウェアの設計と開発の原則について同僚と話したとき、類推の最も一般的なソースの1つは建設業界であることに気付きました。私たちはソフトウェアを構築し、設計と構造をアーキテクチャと見なします。 学ぶ（または教える）ための最良の方法の1つは、類推を分析することです。他の類推は構築から引き出すことができますか？ （ソフトウェアですでに一般的に使用されているかどうか）。 プログラミングコンセプトが構築コンセプトにどのように似ているかについて、説明または個人的な経験を提供してください。 [ アイデアに対する芸術と人文科学から得られたクレジットからプログラミングへの概念 ]

31 design  architecture  development-process 

とても簡単です。私はインターフェイスを実装していますが、このクラスには不要なプロパティが1つあり、実際には使用しないでください。私の最初のアイデアは、次のようなことをすることでした。 int IFoo.Bar { get { raise new NotImplementedException(); } } これ自体に問題はないと思いますが、「正しい」とは感じません。他の誰かが以前に同様の状況に遭遇したことはありますか？もしそうなら、どのようにアプローチしましたか？

31 c#  design  interfaces  implementations 

モジュールとコンポーネントという用語に少し問題があります。私の考えでは、モジュールはバンドルされたクラスであり、明確に定義されたインターフェースを介してのみアクセス可能です。それらはすべての実装の詳細を隠し、再利用可能です。モジュールは、依存するモジュールを定義します。 コンポーネントとの違いは何ですか？いくつかの本で調べましたが、コンポーネントの説明は非常に似ています。

31 design  architecture 

たとえば、広く共有されているクラスと呼ばれるアプリケーションがあるとしUserます。このクラスは、ユーザー、ID、名前、各モジュールへのアクセスレベル、タイムゾーンなどに関するすべての情報を公開します。 ユーザーデータは明らかにシステム全体で広く参照されていますが、何らかの理由で、このユーザーオブジェクトをそれに依存するクラスに渡すのではなく、個々のプロパティを単に渡すようにシステムが設定されています。 ユーザーIDを必要とするクラスは、userIdパラメーターとしてGUID を必要としますが、ユーザー名も必要な場合があります。そのため、別のパラメーターとして渡されます。場合によっては、これは個々のメソッドに渡されるため、値はクラスレベルでまったく保持されません。 Userクラスから別の情報にアクセスする必要があるたびに、パラメーターを追加して変更する必要があり、新しいオーバーロードの追加が適切でない場合は、メソッドまたはクラスコンストラクターへのすべての参照も変更する必要があります。 ユーザーはほんの一例です。これは、コードで広く実践されています。 これはオープン/クローズの原則に違反していると思うのは正しいですか？既存のクラスを変更するだけでなく、そもそもクラスを設定して、将来的に広範囲の変更が必要になる可能性が非常に高くなりますか？ Userオブジェクトを渡したばかりの場合は、作業しているクラスに少し変更を加えることができます。パラメータを追加する必要がある場合は、クラスへの参照に数十の変更を加える必要があります。 この慣行によって他の原則が破られていますか？おそらく依存関係の逆転？抽象化を参照しているわけではありませんが、ユーザーは1種類しかないため、ユーザーインターフェイスを持つ必要はありません。 基本的な防衛プログラミングの原則など、違反している他の非ソリッドの原則はありますか？ 私のコンストラクタは次のようになります： MyConstructor(GUID userid, String username) またはこれ： MyConstructor(User theUser) 投稿編集： 「パスIDまたはオブジェクト？」で質問に回答することが提案されています。これは、どちらの方向に進むかの決定が、この質問の中心にあるSOLID原則に従う試みにどのように影響するかという質問には答えません。

30 java  c#  design  solid 

当社では、製品設計文書を使用していません。合計3人の従業員がいるため、製品設計に関するすべての議論は直接、またはSlackで行われます。（最新のメッセージの表示のみを許可する基本的なSlackパッケージも使用しています。） 当社の製品はまだ初期段階にあり、数か月前に決定された設計要素を頻繁に再検討しています。 私たちが悲惨なほど頻繁に直面する問題は、製品設計の決定が下された理由を忘れることです。これにより、同じ地面をリトレッドするのに何時間も無駄になります。 設計決定の背後にある理論的根拠をどのように効果的に記録できますか？ ワークフローはPivotal Trackerに基づいています。私に起こる解決策の1つは、関連するすべての設計決定の理論的根拠をユーザーストーリー自体へのコメントとして記録することですが、これは信頼できないようです。 100％明確にするために：私はコードの設計について話しているのではありません。私は、コードによって実現される製品の設計について話している。言い換えれば、「多重継承ではなく構成を使用してこのクラスを構成すべきか？」などの決定について話しているのではありません。「ログインする前に、ユーザーにメールアドレスを確認してもらう必要がありますか？」などの決定について話している。 ドキュメントの目的は、ビジネスが意思決定が行われた理由の記録を表示できるようにし、同じトピックに関するさらなる意思決定を支援することです。

30 design  communication  design-decisions 

上記の質問は、レガシーコードで発生する一般的な問題、またはより正確には、この問題を解決するための以前の試みに起因する問題の抽象的な例です。 Enumerable.OfType<T>メソッドのように、この問題に対処することを目的とした少なくとも1つの.NETフレームワークメソッドを考えることができます。しかし、最終的に実行時にオブジェクトの型を調べることになってしまうという事実は、私には正しくありません。 それぞれの馬に「ユニコーンですか？」次のアプローチも思い浮かびます。 ユニコーン以外の角の長さを取得しようとすると例外がスローされます（各馬に適切でない機能が公開されます） 非ユニコーンの角の長さのデフォルト値または魔法の値を返します（すべてユニコーンではない可能性のある馬のグループでホーンの統計情報をクランチするコード全体にデフォルトチェックが必要です） 継承を廃止して、馬がユニコーンであるかどうかを示す別のオブジェクトを馬に作成します（潜在的に同じ問題をレイヤーに押し込んでいます）。 これは「無回答」で最もよく答えられると感じています。しかし、この問題にどのようにアプローチし、それが依存する場合、あなたの決定の背景は何ですか？ また、この問題が関数型コードにまだ存在するかどうか（または、可変性をサポートする関数型言語にのみ存在するかどうかに関する洞察にも興味がありますか？） これは、次の質問の重複の可能性としてフラグが立てられました： ダウンキャストを回避する方法 その質問への答えは、HornMeasurerすべてのホーン測定を行わなければならないaを所有していることを前提としています。しかし、それは、誰もが馬の角を自由に測定できるという平等主義の原則の下で形成されたコードベースに対する非常に強い課しです。 aがないHornMeasurer場合、受け入れられる回答のアプローチは、上記の例外ベースのアプローチを反映しています。 また、馬とユニコーンが両方とも馬であるかどうか、またはユニコーンが馬の魔法の亜種であるかどうかについてのコメントにもいくらか混乱がありました。両方の可能性を考慮する必要があります-おそらく一方が他方よりも望ましいですか？

30 design  object-oriented  functional-programming