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

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 この質問はもう少し主観的ですが、私はいくつかの新しい視点を得ることを望んでいます。私は特定の画面サイズ（通常は1024x768）の設計に慣れているので、そのサイズは問題にはなりません。サイズを1280x1024に拡大しても、かなりの違いを生み出すのに十分な画面領域は購入できませんが、少し余裕ができます。基本的には、「グリッドサイズ」を拡張するだけで、わずかに小さい画面でも同じ基本設計が機能します。 ただし、最後の2つのプロジェクトでは、私のクライアントはすべて1080p（1920x1080）画面を使用しており、可能な限り多くの不動産を使用するソリューションを求めていました。幅1920ピクセルの幅は、私が慣れている幅の2倍をわずかに下回っています。ワイドスクリーンを使用すると、昔の設計の一部がうまく機能しなくなります。私が遭遇している問題は、非常に多くのスペースが提示されると、いくつかの大きな問題に直面することです。 いくつの列を使用する必要がありますか？ワイドフォーマットは、2：1：1の分割（つまり、コンテンツ列が他の2つよりも大きい）での3列の分割に適しています。ただし、3つの列を使用する場合、その追加の列はどうすればよいですか？ 画面の領域を効率的に使用するにはどうすればよいですか？すべてを一度に画面に表示したいという誘惑はありますが、情報が多すぎると、実際にはアプリケーションが使いにくくなります。空白は、複雑な情報を理解するために重要ですが、多すぎると、関連する概念の分離が強すぎます。 私は通常、複雑なデータを持つWebアプリケーションを使用しています。生データを理解するには、視覚化とプレゼンテーションが重要です。ユーザーも大画面（少なくとも24インチ）を使用している場合、一部の情報は視界の外にあり、ポインターを遠くに移動する必要があります。必要なものすべてを視覚的なホットポイント内に確実に収めるにはどうすればよいですか？ ブログのような単純なサイトは、幅が制限されていると実際にパフォーマンスが向上し、その結果、多くの無駄な不動産が発生します。テキストボックスとテキストプレビューを並べて表示することは、そのタイプの画面の管理者側にとって大きなメリットになるのでしょうか。（1：1 2列分割）。 あなたの答えとして、私はデザインのほとんどすべてが「依存する」ことを知っています。私が探しているのは： 使用する一般原則 デザインへのアプローチがどのように変わったか この異なる形式での作業方法を自分で再訓練する必要があることがわかりました。私がこれまで取り組んできた解像度のすべてのバンプは、約25％です。640〜800（25％増加）、800〜1024（28％増加）、1024〜1280（25％増加）。ただし、1280から1920へのジャンプは、スペースの50％の増加に相当します。640から1024へのジャンプに相当します。レッスンを徐々に学習するために一般的に使用される中間サイズはありませんでした。

10 design  gui  usability 

多くの場合、私のビジネスオブジェクトは、情報がオブジェクトの境界を頻繁に越える必要がある状況にあります。オブジェクト指向を実行するときは、情報を1つのオブジェクトに入れ、その情報を処理するすべてのコードをできるだけそのオブジェクトに含める必要があります。ただし、ビジネスルールはこの原則に従っていないため、問題が発生します。 例として、価格を持つInventoryItemを参照するOrderItemの数を持つOrderがあるとします。数量をInventoryItem.GetPrice（）で乗算するOrderItem.GetPrice（）の結果を合計するOrder.GetTotal（）を呼び出します。ここまでは順調ですね。 しかし、その後、一部の商品が2対1で販売されていることがわかりました。OrderItem.GetPrice（）にInventoryItem.GetPrice（quantity）のような処理を行わせ、InventoryItemにこれを処理させることで、これを処理できます。 ただし、2対1の取引は特定の期間のみ続くことがわかります。この期間は、注文の日付に基づく必要があります。次にOrderItem.GetPrice（）をInventoryItem.GetPrice（quatity、order.GetDate（））に変更します。 ただし、お客様がシステムに滞在している期間に応じて、さまざまな価格をサポートする必要があります。 しかし、2対1の取引は、同じ在庫アイテムを複数購入するだけでなく、InventoryCategory内のアイテムの複数購入にも適用されることがわかります。この時点で、私たちは手を挙げて、InventoryItemに注文アイテムを与え、それがアクセサーを介してオブジェクト参照グラフ上を移動できるようにし、必要な情報を取得します：InventoryItem.GetPrice（this） TL; DRオブジェクトの結合を低くしたいのですが、ビジネスルールでは、特定の決定を行うために、多くの場合、どこからでも情報にアクセスする必要があります。 これに対処するための良いテクニックはありますか？他の人が同じ問題を見つけますか？

10 design  object-oriented  business-rules 

私は過去数学期にいくつかのソフトウェア設計コースを受講してきましたが、多くの形式論にはメリットがあると思いますが、プログラム自体については何も教えてくれないように感じます。 プログラムが何ができるかを説明しているとしても、ユースケースの仕様からはプログラムがどのように動作するかはわかりません。 品質要件が含まれていても、要件ドキュメントからユーザーエクスペリエンスについて何も伝えることはできません。 シーケンス図は、ソフトウェアがコールスタックとしてどのように機能するかをよく説明していますが、非常に制限されており、システム全体の非常に部分的なビューを提供します。 クラス図は、システムがどのように構築されているかを説明するのに最適ですが、ソフトウェアが何である必要があるのか​​を理解するのにまったく役に立ちません。 この形式主義のどこが一番重要なのでしょうか。プログラムがどのように見え、動作し、どのような経験をするのでしょうか。それを元に設計するほうが理にかなっていますか？プロトタイプを介してプログラムがどのように機能するかを理解し、それを実際に実装するために努力するほうがよいのではないでしょうか。 私はおそらく理論家から工学を教えられていることに苦しんでいることを知っていますが、私は尋ねる必要があります、彼らは業界でこれを行うのですか？人々は、プログラムが何に準拠すべきかではなく、プログラムが実際に何であるかをどのように理解しますか？人々はたくさんプロトタイプを作っていますか、それともほとんどがUMLなどの正式なツールを使用していますか？

10 design  prototyping 

アプリの無料版と有料版があるとしましょう。有料版は、ユーザーが利用できる機能に関する無料版のスーパーセットです。つまり、有料版は無料アプリのすべての機能に加えて追加機能を備えています。 起動時にロードされるフラグ（無料/有料など）に基づいて機能の可用性を切り替えるパターンはありますか？ どこにでも以下のコードブロックを用意するのは好きではありません。 if(isFreeVersion){ // ... } else { // ... } すべてのバージョンのために2つの別々のgitのブランチを持つことは、それは2を維持（またはそれ以上）のコードのソースを意味しますので、オプションではありません、一般的には非現実的と思われる、よりここで議論されています。バージョン管理で同じコードベースから二つの個別のソフトウェアバージョンを維持します。 これを行う方法はありますか？それでも、単一のコードベースがあり、無料/有料フラグをチェックする条件ステートメントでコードを散らかしていませんか？ これは以前に何度も議論されたと確信しており、この問題に取り組むためのいくつかのパターンがあると確信していますが、それを見つけることができません。 Android / Javaを使用しています。

10 design  design-patterns  programming-practices 

SQLiteでは、次のステートメントが成功し、文字列がSALARYタイプの列に挿入/更新されますINTEGER。 update employee set salary='TOO MUCH' where emp_id=1; ゼロは挿入/更新されませんが、実際の"TOO MUCH"文字列なので、これは自動型変換に関するものではないことに注意してください。 FAQは述べています： これは機能であり、バグではありません。SQLiteは動的型付けを使用します。データ型の制約は適用されません。任意のタイプのデータを（通常は）任意の列に挿入できます。任意の長さの文字列を整数列に入れたり、浮動小数点数をブール列に入れたり、日付を文字列に入れたりできます。CREATE TABLEコマンドで列に割り当てるデータ型は、その列に入れることができるデータを制限しません。すべての列は、任意の長さの文字列を保持できます。（例外が1つあります。INTEGERPRIMARY KEYタイプの列は64ビットの符号付き整数しか保持できません。整数以外のものをINTEGER PRIMARY KEY列に挿入しようとすると、エラーが発生します。） したがって、この動作は明らかに意図的なものですが、 SQLiteがこの動作をするのはなぜでしょうか。私が知っている他のほとんどのSQLデータベースはまったく異なる動作をするため、非数値文字列を挿入しようとすると、エラーが発生するか、文字列0に変換されます。数値列。 SQLiteライブラリは、この振る舞いなしではあまり役に立ちませんか？ これは、ライブラリを小さく高速に保つために設計されたものですか？ 文字列を数値列に挿入しようとするとエラーが発生するために、SQLiteライブラリは大幅に遅くなったり大きくなったりしますか？

10 design  sqlite 

休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 6年前休業。 私はウェブ開発の経験から、PHP、Java、Pythonなどの言語がバックエンド開発のもの（サーバーで実行されるソフトウェア）に使用され、フロントエンド言語にはJS / HTML / CSSが使用されることを知っています。 しかし、多くの企業が、たとえばフロントエンド開発にPHPを、バックエンドにpythonを使用していると言っているのを目にします。 それは、PHPがREST、RPCなどを介して他の言語で書かれた他のサービスを呼び出すためのフロントエンドであることを意味しますか？

10 web-development  architecture  server  design  front-end 

でヘッドファーストデザインパターンでは教えて戦略パターンをダックの異なるサブクラスは、実行時に特定の動作を割り当てることができダックの例を使用して。私の理解では、戦略パターンの目的は実行時に単一のオブジェクトの動作を変更することですが、Duckの継承を使用してさまざまなタイプのDuckの動作を変更しています。 関連性？ Duckのコンテキスト継承は戦略パターンと無関係であるか、またはDuckのタイプを変更し、それらの動作も変更することは、戦略パターンを採用する正当な理由ですか？両方を変化させる必要がある状況は、戦略パターンを使用する正当な理由になりますか？なぜこれを戦略パターンの例として含めるのですか？ より簡単な例 Duckクラス（派生クラスなし）だけでこの例をさらに簡略化できますか？次に、1つのduckオブジェクトを実装するときに、独自のオブジェクトタイプに依存しない特定の状況に基づいて、異なる動作を割り当てることができます。例：FlyBehaviorは天気に基づいて変化し、QuackBehaviorは時刻またはアヒルの空腹度に基づいて変化します。これは本の問題とは異なる問題を解決することになると思いますが、私が探しているのは、頼りになる適切な戦略パターンの例です。 上記の私の例も戦略パターンを構成しますか？ 編集： 私は、コンテキストを継承しない単なる戦略パターンであるHunter.javaとsolver.pyに厳密に準拠する2つの単純な戦略パターンの例を見つけることに成功しました。

10 design  design-patterns  strategy  behavior 

ドメイン駆動設計のアイデアは本当に大好きですが、Goを学んでいるときに、より効果的な関数型言語を目的としたDDDに相当するものがあるかどうか疑問に思っています。

10 functional-programming  domain-driven-design  go  design 

私はキャッシュメカニズムを使用していないので、次のシナリオで.netの世界で私のオプションは何なのかと思っていました。 基本的に、ユーザーがカテゴリー（フォルダーと考える）のIDを渡すRESTサービスがあり、このカテゴリーには多数のサブカテゴリーがあり、各サブカテゴリーには1000のメディアコンテナー（ファイル参照オブジェクトと思う）があり、 NASまたはSANサーバー上にある可能性のあるファイル（この場合、ファイルはビデオです）。これらのカテゴリ間の関係は、いくつかの権限ルールとサブカテゴリに関するメタデータとともにデータベースに保存されます。 したがって、UIの観点からは、遅延して読み込まれたツリーコントロールがあり、これはユーザーが各サブフォルダーをクリックすることによって駆動されます（Windowsエクスプローラーと考えてください）。ビデオファイルのURLにアクセスすると、ビデオを見ることができます。 システムが成長するにつれて、ユーザー数は1000に増加し、サブカテゴリとビデオは10000になる可能性があります。 問題は、各リクエストがデータベースにヒットする現在の動作方法を続行する必要があるか、それともデータのキャッシュについて考える必要があるかです。 IIS 6/7とAsp.netを使用しています。

10 design  architecture  asp.net  enterprise-architecture  iis 

最初に少し背景を説明します。Age-> Rateからルックアップをコーディングしています。年齢層は7つあるため、ルックアップテーブルは3列（From | To | Rate）で7行になります。値はめったに変化しません-それらは3年間同じままであった法定レート（最初と3列目）です。このテーブルをハードコーディングせずに保存する最も簡単な方法は、CSVを含む単一のテキスト値として、グローバル構成テーブルのデータベースにあると考えました（「65,69,0.05,70,74,0.06」は、 65-69および70-74の階層が格納されます）。比較的簡単に解析して使用できます。 次に、これを実装するには、新しいテーブル、それをラップするリポジトリ、リポジトリのデータレイヤーテスト、CSVをテーブルに展開するコードの単体テスト、ルックアップ自体のテストを作成する必要があることに気付きました。このすべての作業の唯一の利点は、ルックアップテーブルのハードコーディングを回避することです。 ユーザー（現在、ルックアップテーブルを直接使用している-ハードコピーを見る）と話すとき、「レートは決して変わらない」という意見がほとんどです。明らかにそれは実際には正しくありません-レートは3年前に作成されただけであり、過去に「決して変化しない」という変化の傾向があったため、これを防御的にプログラミングするには、ルックアップテーブルを絶対に保存しないでくださいアプリケーション。 YAGNIだと思う時を除いて。私が実装している機能は、レートが変更されることを指定していません。レートが変更されても、レートが変更されることはめったにないため、メンテナンスが考慮されることすらありません。また、レートの変更と更新されたアプリケーションとの間に遅延があった場合に影響が及ぶほどの重要な機能ではありません。 ルックアップをハードコーディングしても値が失われることはほとんどないと判断し、この特定の機能への私のアプローチについてあまり心配していません。私の質問は、専門家としてその決定を適切に正当化したかどうかです。値をハードコーディングすることは悪い設計ですが、アプリケーションから値を削除するという面倒を見ると、YAGNIの原則に違反するようです。 編集質問を明確にするために、私は実際の実装について心配していません。私は、素早く悪いことをして、YAGNIと言って正当化できるか、または最も防御力のある、努力の行き届いたアプローチをとることができるか心配しています。プロのプログラマーとして、欠陥があるとわかっている設計を実装するという私の決定は、単にコスト/利益分析に帰着しますか？ 編集個人のデザインの選択に帰着すると思うので、すべての回答は非常に興味深いものでしたが、@ Corbinと@EZ Hartが私が質問で考慮していなかったことを提示するので、最良の回答があったと思います。 データベースに移動することによる「ハードコードされた値の正しい削除」と、ハードコーディングを使用した「YAGNIの効率的な適用」の誤った二分法。ルックアップテーブルをアプリの構成に追加する3番目のオプションがありましたが、これは正しい方法のオーバーヘッドを発生させず、YAGNIの効率がありません。私たちは通常、どちらか一方または両方の決定に限定されず、コスト/利益の決定に帰着します。 コード生成により、ハードコードされた値をデータベースに移動するオーバーヘッドを削減できます。また、CSVをテーブルに処理するという過度に設計された決定も削除されます。これにより、ルックアップメソッドの基本的な要件が変更された場合、生成されたコードに長期的なメンテナンスの問題が追加される可能性があります。これはすべて費用対効果分析に影響を与えるだけであり、その自動化が利用可能だったとしたら、このようなものをハードコーディングすることさえ考えていなかっただろう。 @Corbinの答えを正しいとマークしています。これは、開発コストの想定を変更するためです。近い将来、いくつかのコード生成ツールを武器に追加する予定です。

10 design 

私たちのチームは次の議論をしています： 次の2つのメソッドがあるとします。 public Response Withdraw(int clubId, int terminalId,int cardId, string invoice, decimal amount); public Response Withdraw(Club club, Terminal terminal,Card card, string invoice, decimal amount); 送信されたものは単なるIDです。 片方は、最初の方法が正しいと言います。ターミナルとクラブのIDしかないので、他に何もないことは明らかです。これが私のアプローチです。 反対側は、2番目の方法の方が柔軟性があるため、正しいと言います。 私たちはオブジェクトパラメータのアイデアに精通していますが、反対側もオブジェクトパラメータはオブジェクトをプロパティとして持つべきだと考えています。 正しいアプローチはどれですか？ たぶん3番目のさらに良いアプローチがありますか？

10 design  methods 

現在、コーディングでこのDRY（Do n't Repeat Yourself）の概念に取り組んでいます。この関数を作成していますが、複雑になりすぎるのではないかと心配していますが、DRYの原則に従っています。 createTrajectoryFromPoint(A a,B b,C c,boolean doesSomething,boolean doesSomething2) 私が言ったこの関数は3つの入力パラメーターを取り、ブール関数の組み合わせdoesSomethingとを指定すると、関数は少し異なる動作をしdoesSomething2ます。しかし、私が抱えている問題は、このブール関数が追加されるたびに、この関数が非常に複雑になることです。 だから私の質問は、多くの同じロジックを共有するさまざまな関数（したがってDRYの原則に違反している）や、いくつかのパラメーターを指定した場合にわずかに異なる動作をするが、はるかに複雑にする1つの関数（しかし、 DRYを保存する）？

10 java  design  dry 

私はインターフェースを「発見」し、それらを愛するようになりました。インターフェイスの優れた点は、それがコントラクトであることであり、そのコントラクトを満たすオブジェクトは、そのインターフェイスが必要な場所であればどこでも使用できます。 インターフェースの問題は、それがデフォルトの実装を持つことができないことです。これは、ありふれたプロパティの苦痛であり、DRYを無効にします。これは、実装とシステムの分離を維持するため、これも良い方法です。一方、継承はより緊密な結合を維持し、カプセル化を壊す可能性があります。 ケース1（プライベートメンバーによる継承、適切なカプセル化、密結合） class Employee { int money_earned; string name; public: void do_work(){money_earned++;}; string get_name(return name;); }; class Nurse : public Employee: { public: void do_work(/*do work. Oops, can't update money_earned. Unaware I have to call superclass' do_work()*/); }; void HireNurse(Nurse *n) { nurse->do_work(); ) ケース2（単なるインターフェース） class IEmployee { virtual …

10 c++  design  interfaces  class-design  inheritance 

コーディングはできますが、大規模なプロジェクトでの作業経験はまだありません。私がこれまでに行ったことは、数秒でコンパイルされる小さなプログラム（アルゴリズム、プログラミングの原則、アイデア、パラダイムなどのさまざまなc / c ++の演習、または単にapiを試す...）をコーディングするか、コンパイルが不要なスクリプト言語（python、php、js）で作成。 問題は、スクリプト言語でコーディングするとき、何かがうまくいったかどうかを試したいときはいつでも、スクリプトを実行して何が起こるかを確認することです。うまくいかない場合は、コードを変更し、スクリプトを再度実行してもう一度試すことができます。必要な結果が得られるまでそれを続けます。私のポイントは、待つ必要がないということです。コンパイルするものは何でも、そのため、大きなコードベースを取得、変更、何かを追加、または単に操作するのは非常に簡単です。変更を即座に確認できます。 例として、Wordpressを取り上げます。プラグインを作成する方法を理解するのはとても簡単です。最初に単純な「Hello World」プラグインを作成することから始め、次に管理パネルの単純なインターフェースを作成してAPIに慣れ、次にそれを構築してより複雑なものにし、その間にいくつかの外観を変更します回.. WPと同じくらい大きなものを何度も再コンパイルしなければならないという考えは、マイナーな変更を行うたびに、「動作するかどうか」と「動作するかどうか」を試すために、効率が悪く、遅くて間違っているように思えます。 さて、コンパイルされた言語で書かれたプロジェクトでどうすればいいですか？いくつかのオープンソースプロジェクトに貢献したいのですが、この質問は私を悩ませ続けています。状況はおそらくプロジェクトごとに異なり、事前に賢明に考えられていたもののいくつかは何らかの方法で「モジュラー」になる一方で、他のものは何度も再コンパイルする必要がある1つの大きなblobになるだけです。 これが適切に行われる方法について、もっと知りたいのですが。これに対処するためのいくつかの一般的な実践、アプローチ、およびプロジェクト設計（パターン？）は何ですか？この「モジュール性」はプログラマーの世界でどのように呼ばれていますか？これについてもっと知るために何をググる必要がありますか？プロジェクトが最初の思考の比率から大きくなり、しばらくすると面倒になることがよくありますか？うまく設計されていないプロジェクトの長いコンパイルを回避する方法はありますか？どういうわけかそれらをモジュール化する方法（開発中にプログラムの重要でない部分を除外する可能性があります（他のアイデア？））？ ありがとう。

10 design  productivity  build-system 

私は現在、制御の反転（IoC）コンテナーを既存のアプリケーションに統合することに直面しており、カップリングを減らし、それによってテスト容易性を高めるという最終的な目標でそれを最も簡単に達成できる方法に関するいくつかの推奨事項を探しています。私は通常、ほとんどのクラスを神のオブジェクトとして分類しませんが、静的、シングルトン、およびインターフェイスの欠如により、それぞれに責任が多すぎ、依存関係が隠されています。 以下は、直面する必要があるいくつかの課題の背景です。 依存性注入はほとんど使用されません 静的メソッドが豊富-ファクトリーメソッドとヘルパーメソッドの両方として シングルトンはかなり普及しています インターフェースを使用すると、きめ細かすぎない オブジェクトは多くの場合、基本クラスを通じて不要な依存関係を取り込みます 私たちの意図は、次に特定の領域で変更を加える必要があるときに、実際には存在するが、シングルトンやスタティックなどのグローバルの背後に隠されている依存関係を取り除くことを試みることです。 IoCコンテナが依存性注入の導入の副次的な要素になると思いますが、これらの依存関係を打開するのに役立つ、実行または推奨できる一連のプラクティスと推奨事項があると思います。

10 design  dependency-injection  maintenance