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

メソッド自体からメソッドに渡される値を変更する必要がある場合があります。例として、このメソッドのような文字列をサニタイズします： void SanitizeName(string Name) { Name = Name.ToUpper(); //now do something here with name } Name引数は参照渡しではないため、これはまったく無害です。ただし、何らかの理由で、将来開発者がすべての値をrefで渡すことにした場合、文字列のサニタイズはメソッドの外部の値に影響を及ぼし、有害な結果を招く可能性があります。 したがって、引数自体に再割り当てする代わりに、常に次のようなローカルコピーを作成します。 void SanitizeName(string Name) { var SanitizedName = Name.ToUpper(); //now do something here with name } これにより、値が渡される方法を変更してもメソッドの外での進行に影響を与えないことが保証されますが、これについて過度に妄想を立てているのではないかと思います。

12 design  programming-practices 

私はアプリケーションを書いていますが、このポイントに到達しました： private void SomeMethod() { if (Settings.GiveApples) { GiveApples(); } if (Settings.GiveBananas) { GiveBananas(); } } private void GiveApples() { ... } private void GiveBananas() { ... } これは非常に簡単です。いくつかの条件があり、それらが真である場合、メソッドが呼び出されています。しかし、私は考えていました、このようにするのがむしろ良いですか？ private void SomeMethod() { GiveApples(); GiveBananas(); } private void GiveApples() { if (!Settings.GiveApples) { return; } ... } private void GiveBananas() …

12 design  conditions 

C ++ 11（つまり-std=c++11）でライブラリをテストしています。ライブラリはauto_ptr次のパターンを使用します： Foo* GetFoo() { autoptr<Foo> ptr(new Foo); // Initialize Foo ptr->Initialize(...); // Now configure remaining attributes ptr->SomeSetting(...); return ptr.release(); } C ++ 11は非推奨auto_ptrになったため、それから離れたいと思います。 ただし、コードはC ++ 03とC ++ 11の両方をサポートしているため、ヤンクするほど単純ではありませんauto_ptr。また、ライブラリに外部依存関係がないことにも言及する価値があります。C ++ 03を使用します。Autotools、Cmake、Boostなどを使用しません... auto_ptrC ++ 03との互換性を維持しながら、C ++ 11 から移行するための設計変更をどのように処理する必要がありますか？

12 design  c++  c++11 

ユーザー、ユーザーアカウント、ユーザーライセンス、ライセンス価格、請求書など、さまざまなデータにMS SQLを使用するWebアプリケーションを開発しています。 ユーザーのシステムのリアルタイム使用状況をログに記録し、毎月の請求に使用する必要があります。たとえば、ユーザーが特定のページ/ URLを取得するたびにログを記録し、取得したページ数に基づいて月末にユーザーに請求します。 これらのログイベントをMS SQLデータベースのテーブルに書き込む必要がありますか？ これらのログイベントをSQL以外の追加専用ログファイルに書き込む必要がありますか？ これらのログイベントをユーザーごとに異なるログファイルに書き込む必要がありますか？ これは特に大規模なWebサイトではありません。たとえば、最大10,000ユーザーが1日あたり平均5つのログ記録可能なイベントを行う=> 50,000イベント/日= 30イベント/分= 18,000,000イベント/年。 どちらかのオプションが実行可能と思われ、明確な利点があるかどうかわからないので、私は尋ねています。 請求可能なイベントに関連付けられたデータは単純です。たとえば、次のとおりです。 ユーザーID（SQLのユーザーテーブルとの外部キー関係） 日時 請求可能なページのURL この質問に対する私自身の答えは次のとおりです。 データベーステーブルにログを書き込むことの利点： 関係の整合性：たとえば、ログに記録されたイベントは有効なユーザーIDに関連付けられます（ユーザーIDをテーブル間の外部キーとして定義することにより） 課金のために読みやすい：例えばSELECT COUNT GROUP BY、ユーザーごとのログイベントの数のカウントを取得する ログファイルへの書き込みのいくつかの利点： より簡単なパフォーマンス：SQLはあまり頻繁に使用されません。たとえば、ユーザーのログインイベントにのみ使用され、ほとんどが読み取りにのみ使用されます 管理の簡素化：データベースから削除/アーカイブする代わりに古いログファイルを移動することにより、年末などに古いデータを簡単にアーカイブできます 答えが間違っている場合はお知らせください。または何かの重要性を誇張します。またはいくつかの重要な考慮事項を忘れています。 そして/またはそれが私の答えと異なる場合、あなたの答えが何であるかを教えてください。

12 design  web-development  database  performance  logging 

私は大企業で働いており、アジャイルプロセスの使用を指示しています。たとえば、プロジェクトでは、アジャイル開発の管理を特に対象としたクラウドベースのサービスを使用しています。 私が働いている特定のエンジニアリンググループは、従来ソフトウェアを開発していませんでした（代わりに、より多くの鳥瞰的な観点からプロジェクトを推進しています）が、それは変化しています。私たちには、主にデータ中心の広範囲の今後/計画中のソフトウェアプロジェクトがあります。たとえば、データの監視、収集、集計、およびいくつかのレポート作成を行います。その他のタスクには、特殊なハードウェアとさまざまなタイプのクライアント/サーバー（多層）アーキテクチャによる自動化が含まれます。私は、複数の人を採用し、前進するための多くの計画を策定するプロセスを支援します。 私の質問は、ラピッドプロトタイピング（スローアウェイコード）を行うことがアジャイル哲学に適合するかどうかです。たとえば、Pythonとその幅広いパッケージが大好きです。Pythonベースのワークフローを使用して、多くのアイデアを非常に迅速に実装できる可能性があると思います。ただし、Pythonは「エンタープライズ品質」ではないという認識が多くあり、この作業の多くはJavaまたはC ++で書き直す必要があると思います。 ただし、Pythonプロトタイプを作成することで、実際の結果を迅速に提供できるようにするための費用を大幅に削減できます。 ラピッドプロトタイピングを（できればPythonで）エンタープライズ環境の堅牢なアジャイルワークフローに組み込むことができましたか？

12 python  agile  design  prototyping  product-management 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 仕様の修正を顧客と交渉し、顧客が望んだことではなく、顧客が望んだことを行うように仕様を修正する最適な状況を知っています。それは交渉で、説明しています。 時には、クライアントを納得させることができません。設計どおりに壊れたものを生産せざるを得ません。これは魔術師と悪魔が彼らの願いを文字通りに満たして魔術師の終miseをもたらす魔術師の功績によって「悪魔学」と呼ばれ、顧客が彼らのエラーに気づいたら非常に不満を残す別のアプローチであり、もちろん開発者に責任があります。 今、私は非常に異なるアプローチに直面しました：顧客はいくつかの重要な警告を説明できない単純な仕様を作成し、それらを修正することを完全に嫌がり、明白なエラーを認め、提案された修正を受け入れます。これらの仕様に合わせて作られた製品は非常に壊れており、人命を犠牲にする可能性があります。それでも、契約を完全に解除するには遅すぎます。契約には、そのための罰則条項があり、実際に受け入れることはできません。 上司の決断？私たちは仕様通りにそれを行ったことを正しく行い、顧客に嘘をつきます。問題のアルゴリズムは表面下に十分に隠されているため、製品は問題なく動作し、警告の状況で失敗することはありません。誰かが深く掘り下げない限り、要求どおりに壊れていないことを発見することはありません。 この仕様実行の戦術には、一般的な名前がありますか？

12 design  specifications 

.NETプロパティに関する設計上の問題があります。 interface IX { Guid Id { get; } bool IsInvalidated { get; } void Invalidate(); } 問題： このインターフェイスには、2つの読み取り専用プロパティとがIdありIsInvalidatedます。ただし、それらが読み取り専用であるという事実は、それらの値が一定のままであることを保証するものではありません。 それを非常に明確にすることが私の意図だったとしましょう… Id 定数値を表します（したがって、安全にキャッシュできます）。 IsInvalidatedIXオブジェクトの存続期間中にその値を変更する可能性があります（したがって、キャッシュすべきではありません）。 interface IXその契約を十分に明確にするためにどのように変更できますか？ 私自身の解決策の3つの試み： インターフェイスはすでに適切に設計されています。呼び出されたメソッドの存在Invalidate()により、プログラマは、同様の名前のプロパティの値IsInvalidatedが影響を受ける可能性があることを推測できます。 この引数は、メソッドとプロパティの名前が似ている場合にのみ有効です。 このインターフェースをイベントで拡張しますIsInvalidatedChanged： bool IsInvalidated { get; } event EventHandler IsInvalidatedChanged; の…Changedイベントの存在は、IsInvalidatedこのプロパティがその値を変更する可能性があることを示し、同様のイベントが存在しないことは、Idそのプロパティがその値を変更しないという約束です。 私はこのソリューションが好きですが、それはまったく使われないかもしれない追加のものがたくさんあります。 プロパティIsInvalidatedをメソッドに置き換えますIsInvalidated()： bool IsInvalidated(); これはあまりにも微妙な変更かもしれません。値は毎回新しく計算されるというヒントになるはずです-定数である場合は必要ありません。MSDNのトピック「プロパティとメソッドの選択」には、次のように書かれています。 次の状況では、プロパティではなくメソッドを使用してください。[…]パラメータが変更されていなくても、操作は呼び出されるたびに異なる結果を返します。 どのような答えが期待できますか？ 私は、問題に対するまったく異なる解決策と、上記の試みをどのように打ち負かすかについての説明に最も興味があります。 私の試みが論理的に欠陥があるか、まだ言及されていない重大な欠点があり、解決策が1つしか残っていない（または何も残っていない）場合、どこで間違ったのかを聞きたいと思います。 欠陥が軽微であり、それを考慮した後、複数の解決策が残っている場合は、コメントしてください。 少なくとも、どちらがあなたの優先解決策であり、どのような理由であるかについてのフィードバックをお願いします。

12 c#  design  .net  properties 

これは、「jQueryからの」「結合された」ゲッター/セッターメソッドと呼ばれるものです。 var foo = $("<div>This is my HTML</div>"), myText; myText = foo.text(); // myHTML now equals "This is my HTML" (Getter) foo.text("This is a new value"); // The text now equals "This is a new value") これは、個別の（理論的な）メソッドを使用した同じロジックです。 var foo = $("<div>This is my HTML</div>"), myText; myText = foo.getText(); // myHTML …

12 design  javascript 

これは基本的に、弱いエンティティとは何かに関する質問ですか？それらをいつ使用する必要がありますか？どのようにモデル化する必要がありますか？ 通常のエンティティと弱いエンティティの主な違いは何ですか？ドメイン駆動設計を行う場合、脆弱なエンティティは値オブジェクトに対応しますか？ ここでトピックに関する質問を続けるのを助けるために、人々がこれらの質問に答えるために使用できるウィキペディアから取られた例です： この例でOrderItemは、弱いエンティティとしてモデル化されましたが、通常のエンティティとしてモデル化できない理由を理解できません。 もう1つの質問は、注文履歴（つまり、ステータスの変更）を追跡したい場合、それは通常のエンティティまたは脆弱なエンティティでしょうか？

12 design  database  database-design  entity 

私は組み込みシステム会社で働くソフトウェア開発者です。プロジェクトマネージャーがいて、プロジェクトの全体的なスケジュール（電気、品質、ソフトウェア、製造など）を担当しているため、ソフトウェアスケジュールは非常に短いです。 私の上司であるソフトウェアマネージャーもいます。彼は、ソフトウェアのスケジュール、設計文書（高レベルおよび低レベルの設計）、SRS、変更管理、検証計画とレポート、リリース管理、レビュー、そしてもちろんソフトウェアの作成と保守をさせてくれます。 ソフトウェアチーム全体（10人のメンバー）に対応するテストエンジニアは1人だけであり、常にいくつかのプロジェクトが進行中です。 私はこれらのドキュメントを作成するのに80％の時間を費やしています。私の上司はプロセスのバックグラウンドから来ており、必要なのはソフトウェアを改善するためのより良いドキュメントであると考えています。 彼はデザインが最重要であると考え、コーディングは「デザインを書き留める」だけで、それほど長くはかからず、「ハードウェアの準備ができる前にすべてのコードを書く」必要があります。 分散モデルとのコラボレーションが簡単だと彼に言った後でも、中央バージョンと分散バージョンコントロールの違いを理解していません。 コードを理解していないため、すべてのバグとその提案された解決策を理解したいと考えています。 検証は開発者が行い、検証はテスターが行うべきだと考えています。ただし、検証では実装が正しいかどうかのみをチェックし（単体テストは作成せず、スケジュールでは考慮されません）、検証はブラックボックステストであるため、単体テストはありません。 私は本当に混乱しています。 これらすべての文書を管理する責任はありますか？本質的に、ソフトウェアプロジェクト管理を行っているような気分になります。技術文書は問題ありませんが、開発者がスケジューリング/計画を立てるべきではないと考えています。 私はドキュメントの作成が本当に好きではありません。問題を解決してコードを書きたいです。私の経験では、設計ドキュメントの作成はある程度までしか役に立ちませんが、コードの改善や高速化の解決策になることはありません。 上司はより良い製品を作ることを本当に気にせず、経営者の目には良いマネージャーになることだけに関心があると思います。 私に何ができる？今年は3か月間実際のコーディングを行い、残りはドキュメントの作成とクライアントからのバグレポートの待機に費やしました。

12 design  project-management  development-process  documentation 

私は産業環境でバルブを開閉するために使用されるアプリを開発しており、このような単純なことを考えていました：- public static void ValveController { public static void OpenValve(string valveName) { // Implementation to open the valve } public static void CloseValve(string valveName) { // Implementation to close the valve } } （実装は、バルブを制御するためにシリアルポートに数バイトのデータを書き込みます-バルブ名から派生した「アドレス」、およびバルブを開閉する「1」または「0」）。 別の開発者は、代わりに物理的なバルブごとに個別のクラスを作成するかどうかを尋ねました。のようなコードを書く方が良いと思いますPlasmaValve.Open()がValveController.OpenValve("plasma")、これはやり過ぎですか？ また、私はいくつかの仮説的な将来の要件を念頭に置いて設計に取り組む最善の方法を疑問に思っていました： バルブの開閉に異なる値を必要とする新しいタイプのバルブ（0と1ではありません）をサポートするよう求められています。 単に「開く」または「閉じる」のではなく、0〜100の任意の位置に設定できるバルブをサポートする必要があります。 通常、この種のことには継承を使用しますが、最近、「継承を超える構成」に頭を悩まし始め、構成を使用するスリッカーソリューションがあるのではないかと考え始めました。

12 design  design-patterns  object-oriented 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 閉じた2年前。 OOPデザインを作成するのが難しいことに気付きました。このプロパティがXクラスに正しく設定されているかどうかを判断するのに多くの時間を費やしました。 たとえば、これは数日ある投稿です：https : //codereview.stackexchange.com/questions/8041/how-to-improve-my-factory-design 私は自分のコードを確信していません。だから私は自分のデザインを改善したい、それを作成する時間を短縮したい 良いデザインの作成をどのように学びましたか？あなたが私を推薦することができるいくつかの本？

12 design  object-oriented 

私はPeter Seibelの"Coders at Work：Reflections of Programming of Programming ''と呼ばれるこの素晴らしい本を読んでおり、Joshua Blochとの会話の一部であり、プログラマーにとって重要なこの答えを見つけました。段落は、このようなものになります。 この問題があります。つまり、プログラミングは非常に知的実力主義であり、多くの場合、これらの人々は組織内で最も賢い人々です。したがって、彼らはすべての決定を下せるようにすべきだと考えています。しかし、単に彼らが組織内で最も賢い人であるという事実は、彼らがすべての決定を下すべきであることを意味しません。それはベクトル量です。 ここで最後の文で、私は彼が共有しようとしている洞察を得ることはできません。誰かがそれをベクトル量によって意味するものとしてもう少し詳しく説明できますか？おそらく同じ洞察を提示しようとしています。 さらに下に、私は彼が電子メールを書くのにより多くの時間を費やすことができる何らかの理由で技術者でない人（時々無知）が技術者のマネージャーになることができる組織を持つことについて取っていないという点を得る上記の段落に続く文はそうでした。 また、共感や感情的な知性が欠けている場合は、APIやGUI、言語を設計するべきではありません。 ソフトウェアエンジニアリングでは、プログラマーはユーザーが自分の製品やデザインをどのように見るかを知る必要があると彼が言っていることを理解しています。 上記の段落は非常に興味深いと感じました。

12 design  project-management  customer-relations 

私は、統合された視聴覚システム用の信号管理およびルーティングモジュールの開発を進めており、さまざまな信号配信ネットワークにわたって可能な限り柔軟になるように設計しています。モジュールの目的は、多数のスタックマトリックススイッチャー1を経由するルーティングを処理し、必要なフォーマット変換を処理することです。 この時点で検討した最良の解決策は、ネットワークをスイッチャーでサポートされている各信号タイプの個別の頂点を持つグラフにマッピングし、フォーマット変換を処理するビデオプロセッサを表すノードを介して結合することです。 色は信号形式を表します。 ラウンドノードは、スイッチャー、ソース、またはシンクのいずれかです。 スクエアノードは、形式変換を実行するビデオプロセッサです。 そこから、ダイクストラのアルゴリズムの実装を使用して、入力Xから出力Yを取得するために形成する必要があるパスを特定できます。これにより、すべてのスイッチャーおよびプロセッサーの入力/出力構成に関するデータを渡すことができます。モジュールはそれに応じて適応します。 これは適切な解決策ですか、それとも調査する価値がある代替アプローチがありますか？ 1別名「クロスバースイッチ」、1対多の接続をサポートするM入力x N出力のビデオルーター。各物理デバイスは複数の信号形式を処理でき、形式変換を実行できる場合とできない場合があります。 編集： PéterTörökが述べたように、グラフは必ずしもツリーである必要はありません。図はアイデアを説明するための簡単な例です。「実世界」に実装すると、エッジの重みで表現することを計画していたさまざまなレベルの定義（DVI> VGA>コンポーネント>コンポジット）を提供する複数のパスが存在する場合があります。 編集2：指向性が示され、2つの信号タイプで構成されるネットワークを示す、もう少し包括的な例です。最初の例は、マトリックスルーティング/入力選択を制御するために必要なデータを提供するため、デバイスの各入力と出力が個別のノードとして定義されるようにわずかに変更されました。

12 design  algorithms 

DDDアプローチを使用して、肥大化したサービスレイヤーからドメインレイヤーにデータを移動しようとしています。現在、私たちのサービスには多くのビジネスロジックがありますが、それはいたるところに分散しており、継承の恩恵は受けません。 ほとんどの作業の中心である中央ドメインクラスがあります-貿易。Tradeオブジェクトは、それ自体の価格設定方法、リスクの推定方法、それ自体の検証方法などを知っています。その後、条件をポリモーフィズムに置き換えることができます。例えば、SimpleTradeはそれ自体の価格を設定しますが、ComplexTradeはそれ自体の価格を設定します。 ただし、これによりTradeクラスが膨張するのではないかと心配しています。本当に独自の処理を担当する必要がありますが、機能が追加されるにつれてクラスのサイズは指数関数的に増加します。 選択肢があります： Tradeクラスに処理ロジックを配置します。処理ロジックは現在、取引のタイプに基づいてポリモーフィックですが、取引クラスには複数の責任（価格、リスクなど）があり、大規模です TradePricingServiceなどの他のクラスに処理ロジックを配置します。Trade継承ツリーとポリモーフィックではなくなりましたが、クラスは小さくなり、テストが容易になりました。 推奨されるアプローチは何ですか？

12 object-oriented  design  domain-driven-design