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

現在、ビデオ監視映像の圧縮とインデックス作成を実行するソフトウェアプロジェクトに取り組んでいます。圧縮は、背景オブジェクトと前景オブジェクトを分割し、背景を静的画像として保存し、前景をスプライトとして保存することで機能します。 最近、私はプロジェクトのために設計したいくつかのクラスのレビューに着手しました。 パブリックメソッドが1つしかないクラスがたくさんあることに気付きました。これらのクラスの一部は次のとおりです。 VideoCompressor（compressタイプの入力ビデオを取り込み、タイプRawVideoの出力ビデオを返すメソッドを使用CompressedVideo）。 VideoSplitter（splitタイプの入力ビデオを取り込みRawVideo、それぞれタイプの2つの出力ビデオのベクトルを返すメソッドを使用RawVideo）。 VideoIndexer（indexタイプの入力ビデオを取り込み、タイプRawVideoのビデオインデックスを返すメソッドを使用VideoIndex）。 私は自分自身だけのような呼び出しを行うために、各クラスをインスタンス化見つけますVideoCompressor.compress(...)、VideoSplitter.split(...)、VideoIndexer.index(...)。 表面的には、クラス名は意図する機能を十分に説明していると思います。実際には名詞です。同様に、それらのメソッドも動詞です。 これは実際に問題ですか？

51 design  object-oriented-design 

Model-View-Controller（MVC）およびModel-View-Presenter（MVP）パターンについて3日間読んでいます。そして、私を非常に悩ませる1つの質問があります。既にMVCがあったのに、ソフトウェアデザイナーがMVPを発明したのはなぜですか？ MVCが解決しなかった（またはひどく解決した）が、MVPが解決できる問題は何ですか？MVPが解決するのはどの問題ですか？ MVPの歴史と説明、またはMVCとMVPの違いに関する記事をたくさん読んでいますが、私の質問に対する明確な答えがありませんでした。 私が読んだ記事の1つで、次のように言われました。 次に、Model View Presenterを使用します。これは、最新のコンポーネントベースのグラフィカルユーザーインターフェイスに適用した場合のMVCパターンの不備に対する応答でした。最新のGUIシステムでは、GUIコンポーネント自体が、中央のコントローラーではなく、マウスの動きやクリックなどのユーザー入力を処理します。 だから、理解できませんが、実際には別の方法で、GUIコンポーネントがユーザー入力を自分で処理しないようにすることはできますか？そして、「自分で処理する」とはどういう意味ですか？

49 design  design-patterns  mvc  mvp 

私は極座標とデカルト座標の両方を扱うプログラムを書いています。 それがポイント、との1の種類ごとに二つの異なる構造体を作成しても意味がないXし、Yメンバーと1はであるRとThetaメンバー。 それとも、あまりにも多くのことをされ、でちょうど1構造体を持っている方が良いですfirstし、secondメンバーとして。 私が書いているのは簡単で、あまり変わりません。しかし、私はデザインの観点から何が良いのか興味があります。 最初のオプションの方が良いと思います。より読みやすく、型チェックの利点が得られます。

49 design 

現在、次のような組織でプロジェクトに取り組んでいます。 クライアント -REST APIを介してメインサーバーからデータを取得します。 サーバー -サードパーティAPIを介して他のさまざまなサーバーからデータを要求します サードパーティ API-サーバーにデータを提供する私の制御できないサービス（Reddit、Hackernews、Quoraなど） 議論のために、クライアントが最初に各サードパーティAPIからのアイテムのリストを必要とするとしましょう。このリストからアイテムが選択されます。この時点で、クライアントはアイテムの完全なコンテンツとアイテムへの応答（コメント）を表示する必要があります。私は3つのオプションの間で決定しようとしています： アラカルト このアプローチでは、サーバーに3つのエンドポイントがあります。1つはアイテムのリストを取得し、1つはアイテムのメインコンテンツを取得し、もう1つはアイテムの応答を取得します。 長所：必要以上にリクエストを送信することはありません。リクエストは小さくなければならないので、一般的には高速になります。 短所：私は多くの要求をしなければなりません。リストから項目を選択した後、ユーザーはメインコンテンツを見る前に待たなければならない場合があり、それから応答を見るためにさらに長く待たなければならない場合があります サーバー側キャッシュ このリクエストでは、サーバーを1回呼び出して、すべてのソースのすべてのデータを「フェッチ」します。その後、データはサーバーにキャッシュされます。クライアントは以前と同じRESTエンドポイントを持つことになりますが、サーバーには既にデータがあり、それをクライアントにフィードするだけなので、呼び出しと呼び出しの間にあまり待つ必要はありません。 長所：クライアント側での実装は依然として簡単ですが、遅延の問題はありません 短所：サーバー側が少し複雑で、最初の呼び出しには本当に長い時間がかかる可能性があります。 クライアント側キャッシュ このシナリオは前のシナリオと似ていますが、クライアントがサーバーに対して1回だけ要求を行うという点が異なります。つまり、すべてのデータを提供します。ここから、データを保存して適切に使用するのはクライアントの責任です。 長所：簡単なサーバー実装、最初の呼び出し後は非常に高速 短所：最初の呼び出しは非常に遅く、より複雑なクライアント側の実装になります どちらが最善のアプローチであるのか、あるいは明らかな解決策が欠けているのかもしれません。どんなアドバイスも大歓迎です！

49 design  rest  api-design  server 

理由はわかりませんが、リフレクションを使用するときは常に「ごまかし」のような気がします-おそらく、自分が取っているパフォーマンスヒットのせいでしょう。 私の一部は、それがあなたが使用している言語の一部であり、あなたがしようとしていることを達成できるなら、なぜそれを使用しないのかと言います。私の他の部分は、リフレクションを使用せずにこれを行うことができる方法がある必要があると言います。多分それは状況次第だと思います。 リフレクションを使用する際に注意する必要のある潜在的な問題は何ですか？従来の解決策を見つけようとするのにどれだけの労力を費やす価値がありますか？

49 design  programming-practices  architecture  code-quality 

StackOverflowの興味深い問題を扱っています。 私たちには、「すぐにやる必要がある」小さなタスクがたくさんあります。例は、「関連する質問」リストの更新です。過去に行ったことは、これらのタスクを一部のユーザーのページロードにピギーバックすることです。 これは決して理想的ではありませんでしたが、それほど目立ちませんでした。SOが1,000,000の疑問符を通過したので、それらの不運なユーザーはそれを感じ始めています。 自然な解決策は、これらのタスクを実際にバックグラウンドにプッシュすることです。私が検討しているこれを行うには2つの広い方法があります。 1. IISでカスタムスレッドプール/ワークキューとして 基本的に、IISに干渉しないようにいくつかのスレッド（非ThreadPool）をスピンアップし、Funcsを入れているコレクションにサービスを提供します。 ここでの大きな利点はシンプルです。マーシャリングについて心配する必要も、外部サービスが起動して応答することを確認する必要もありません。 また、すべての共通コードにアクセスできます。 欠点は、バックグラウンドスレッドを使用しないことです。私が知っている異議はすべて、IISの飢star（ThreadPoolを使用している場合）とスレッドのランダムな消滅（AppPoolのリサイクルのため）に集中しています。 ランダムスレッドデスを非問題にするための既存のインフラストラクチャがあり（基本的にタスクの検出は中止されています）、スレッド数の制限（および非スレッドプールスレッドの使用）も難しくありません。 IISプロセスのスレッドプーリング/ワークキューに他の異議がありませんか？ ここでは実際には対処されなかったため、StackOverflowに移動しました。 2.サービスとして サードパーティのソリューション、またはカスタムソリューションのいずれか。 基本的に、プロセスの境界を越えて何らかのサービスにタスクをマーシャリングし、それを忘れます。おそらく、生のSQL +接続文字列の一部のコードをリンクしている、または制限しているのでしょう。 プロは、これを行うための「正しい方法」であるということです。 短所は、できることが非常に制限されているか、このサービスをコードベースと同期させるために何らかのシステムを作成する必要があることです。また、監視とエラーログのすべてをなんらかの方法で接続する必要があります。これは、「IIS内」オプションで無料で取得できます。 サービスアプローチには他の利点や問題がありますか？ 簡単に言えば、アプローチ＃1を実行不可能にする予測不可能で克服できない問題がありますか。もしそうなら、アプローチ＃2を検討する必要がある優れたサードパーティサービスはありますか。

49 web-development  design  multithreading  iis7 

最近、デザインにマネージャークラスをたくさん持つのは悪いことだと思い始めました。このアイデアは説得力のある議論をするには十分に成熟していませんが、いくつかの一般的なポイントがあります： 「マネージャー」に大きく依存しているシステムを理解することは、私にとってはるかに難しいことがわかりました。これは、実際のプログラムコンポーネントに加えて、マネージャの使用方法と理由を理解する必要があるためです。 マネージャーは、多くの場合、プログラマーがプログラムJust Work TMを作成する方法を見つけることができず、マネージャークラスに依存してすべてが正常に動作する必要がある場合など、設計の問題を軽減するために使用されるようです。 もちろん、飼い葉sは良いことができます。明らかな例は、EventManager私のお気に入りの構造の1つです。：P私のポイントは、マネージャーが多くの時間を使いすぎているように見えることであり、プログラムアーキテクチャの問題を隠す以外の正当な理由はありません。 マネージャークラスは本当に悪いアーキテクチャの兆候ですか？

49 design  architecture 

これを求める別の方法は次のとおりです。なぜプログラムはモノリシックになる傾向があるのですか？ Mayaのようなアニメーションパッケージのようなものを考えています。人々はさまざまなワークフローに使用します。 アニメーション機能とモデリング機能を独自の個別のアプリケーションに分割し、それらの間でファイルをやり取りして個別に開発した場合、それらの保守は容易ではないでしょうか？

48 design  architecture  maintainability  application-design 

隠されたAJAXリクエストとは何ですか？ ユーザーのアクションがすぐに発生するように見えるように設計された非表示のAJAXリクエストの使用が増加していることに気付きました。このタイプのAJAXリクエストを非ブロッキングと呼びます。これは、ユーザーに発生を認識せずに行われたAJAXリクエストであり、バックグラウンドで実行され、操作はサイレントです（AJAX呼び出しが正常に完了したことを示す詳細はありません）。目標は、操作が実際に終了していないときにすぐに発生したように見えるようにすることです。 ノンブロッキングAJAXリクエストの例を次に示します。 ユーザーがメールのコレクションで[削除]をクリックします。アイテムは受信トレイからすぐに消え、他の操作を続行できます。一方、AJAXリクエストはバックグラウンドでアイテムの削除を処理しています。 ユーザーが新しいレコードのフォームに入力します。保存をクリックします。新しいアイテムがリストにすぐに表示されます。ユーザーは引き続き新しいレコードを追加できます。 明確にするために、AJAX要求をブロックする例を次に示します。 ユーザーがメールのコレクションで[削除]をクリックします。砂時計カーソルが表示されます。AJAX要求が行われ、応答すると砂時計カーソルがオフになります。ユーザーは、操作が完了するまで1秒待つ必要があります。 ユーザーが新しいレコードのフォームに入力します。保存をクリックします。AJAXローダーをアニメーション化すると、フォームが灰色に変わります。「データが保存されました」というメッセージが表示され、新しいレコードがリストに表示されます。 上記の2つのシナリオの違いは、非ブロッキングAJAXセットアップでは動作のフィードバックが提供されないことと、ブロッキングAJAXセットアップでは提供されることです。 隠されたAJAXリクエストのリスク このスタイルのAJAX要求の最大のリスクは、AJAX要求が失敗したときにWebアプリケーションがまったく異なる状態になる可能性があることです。 たとえば、非ブロッキングの例。 ユーザーは多数のメールを選択します。削除ボタンをクリックします。操作はすぐに行われるように見えます（項目はリストから消えます）。次に、ユーザーは[作成]ボタンをクリックして、新しいメールの入力を開始します。この時点で、JavaScriptコードがAJAXリクエストが失敗したことを発見します。スクリプトはエラーメッセージを表示する可能性がありますが、現時点では本当に意味がありません。 または、ブロッキングの例。 ユーザーは多数のメールを選択します。削除ボタンをクリックします。砂時計が見えますが、操作は失敗します。「error。blah blah blah」というエラーメッセージが表示されます。それらは電子メールのリストに戻り、削除したい電子メールが選択されたままです。彼らは再びそれらを削除しようとする可能性があります。 ノンブロッキングAJAXリクエストを実行するための他の技術的リスクもあります。ユーザーはブラウザを閉じ、別のWebサイトに移動し、現在のWebの別の場所に移動して、エラー応答のコンテキストを無意味にすることができます。 それで、なぜそんなに人気が出るのでしょうか？ Facebook、Google、Microsoftなど。これらの大規模なドメインはすべて、非ブロッキングAJAXリクエストを使用して、操作が即座に実行されているように見せるようになっています。また、保存ボタンや送信ボタンのないフォームエディタが増えています。フィールドを出るかEnterキーを押すとすぐに。値が保存されます。プロフィールが更新されたというメッセージや保存手順はありません。 AJAXリクエストは確実ではなく、完了するまで成功として扱われるべきではありませんが、多くの主要なWebアプリケーションはそのように動作しています。 ノンブロッキングAJAX呼び出しを使用するこれらのWebサイトは、レスポンシブアプリケーションをシミュレートし、高速に表示されるという犠牲を払って不要なリスクを冒していますか？ これは、競争力を維持するために私たち全員が従うべき設計パターンですか？

48 design  web-development  javascript  ajax  error-handling 

この質問は主観的なものですが、ほとんどのプログラマーがこれにどのようにアプローチしているかに興味がありました。以下のサンプルは擬似C＃ですが、これはJava、C ++、およびその他のOOP言語にも当てはまります。 とにかく、クラスでヘルパーメソッドを記述するとき、静的メソッドとして宣言し、ヘルパーメソッドで必要な場合はフィールドを渡すだけです。たとえば、以下のコードを考えると、メソッド呼び出し＃2を使用することを好みます。 class Foo { Bar _bar; public void DoSomethingWithBar() { // Method Call #1. DoSomethingWithBarImpl(); // Method Call #2. DoSomethingWithBarImpl(_bar); } private void DoSomethingWithBarImpl() { _bar.DoSomething(); } private static void DoSomethingWithBarImpl(Bar bar) { bar.DoSomething(); } } これを行う私の理由は、ヘルパーメソッドが実装を読み取らなくても、他のオブジェクトに副作用がある可能性があることを（少なくとも私の目には）明らかにするからです。この手法を使用するメソッドをすばやく理解できるため、デバッグに役立ちます。 あなたはどちらか好む独自のコードでやってそうするためのあなたの理由は何ですか？

48 java  c#  design  object-oriented  programming-practices 

主にクラスベースの言語のコンテキストでOOPを扱った後にJavascriptのプログラミングを始めたとき、プロトタイプベースのOOPがクラスベースのOOPよりも優先される理由について混乱していました。 プロトタイプベースのOOPを使用する場合、構造的な利点はありますか？（たとえば、特定のアプリケーションでより高速であるか、メモリ集約度が低いと予想されますか？） コーダーの観点からの利点は何ですか？（たとえば、特定のアプリケーションをコーディングしたり、プロトタイピングを使用して他の人のコードを拡張したりするのは簡単ですか？） この質問を特にJavascriptに関する質問と見なさないでください（長年にわたってプロトタイプ作成とはまったく関係のない多くの欠点がありました）。代わりに、プロトタイピングとクラスの理論的な利点のコンテキストで見てください。 ありがとうございました。

47 design  object-oriented  language-agnostic 

たとえば、RabbitMQのようなAMQPの使用を検討すべきユースケースを誰かが説明できますか？長所と短所は何ですか？

45 design  message-queue 

[免責事項：この質問は主観的ですが、事実や反射によって裏付けられた回答を得ることを希望します] 誰もがロバストネスの原則について知っていると思いますが、通常はポステルの法則によって要約されます： 送信する内容には慎重になります。あなたが受け入れるものに寛大であること。 普及している通信プロトコルの設計では、これは理にかなっているかもしれません（簡単に拡張できるようにすることを目標としています）が、HTML / CSSへのアプリケーションは完全に失敗し、各ブラウザが独自のサイレント調整を実装していると常に考えていました検出/動作。複数のブラウザで一貫したレンダリングを取得することはほぼ不可能です。 ただし、TCPプロトコルのRFCでは、特に明記されていない限り、「サイレント障害」を許容できると考えています。これは、控えめに言っても興味深い動作です。 ソフトウェアトレード全体でこの原則が適用されている他の例があります。開発者に噛み付いたために、頭の一番上から定期的に表示されます。 Javascriptセミコロン挿入 C（サイレント）組み込み変換（切り捨てられなかった場合はそれほど悪くないでしょう...） 「スマート」動作の実装を支援するツールがあります。 名前に一致する表音アルゴリズム（Double Metaphone） 文字列距離アルゴリズム（レーベンシュタイン距離） しかし、このアプローチは、技術に詳しくないユーザーを扱う場合やエラー回復のプロセスでユーザーを支援する場合には役立つかもしれませんが、ライブラリ/クラスインターフェースの設計に適用するといくつかの欠点があることがわかります。 アルゴリズムが「正しい」と推測するかどうかはやや主観的であるため、最小驚きの原則に反する可能性があります。 実装がより難しくなり、バグを導入する機会が増えます（YAGNIの違反？） 「推測」ルーチンを変更すると古いプログラムが破損する可能性があり、リファクタリングの可能性をほぼ最初から除外するため、動作が変更されやすくなります。 そして、これが私を次の質問へと導いたものです。 インターフェイス（ライブラリ、クラス、メッセージ）を設計するとき、堅牢性の原則に傾いていますか？ 私自身は非常に厳しい傾向があり、インターフェイスで広範な入力検証を使用しています。

45 design 

私の上司は長年このプロジェクトに取り組んでいます。私はここに数週間しかいませんが、それが可能かどうかはわかりません。彼は「100％データ駆動型」のシステムを設計したいと考えています。 したがって、十分なデータを入力すれば、任意のアプリケーションを定義および生成できます。私は少なくともユーザーなどのいくつかのことを認めさせることができました、またはアプリには事前定義された値が必要ですが、彼はシステムの構造、ユーザーインターフェイス、ロジックがすべてデータとして保存されるという概念が好きです。 単純なもののデモがいくつかあり、彼は基本的にオブジェクト指向プログラミングと基本的なテンプレートシステムのいくつかの単純なアイデアを再発見しましたが、この目標は実際には不可能であると思います。 システムを非常に複雑にせずに実際のプログラミングを行うことなく、データを使用してロジックを定義する方法がわかりません。 理論的には、データを解釈するものがアプリケーションを説明するために完全にチューリングする必要があるので、問題を1レベル上にシフトしてネットメリットがないからではないと思います。 このような100％データ駆動型アプリケーションは可能ですか？

44 design  domain-driven-design 

これはマーフィーの法則のようなものですか？たぶん、非常に優れたプログラミング忍者を雇いたいなら、「あなたのウェブサイトを見せてください。あなたの素晴らしさを伝えます」のように、彼のウェブサイトをチェックしてください。 編集：stackoverflowトップユーザータブに移動し、表示されます

44 design  aesthetics