問題タブ [design-principles]

私はSOLIDやDRYなどのソフトウェア設計原則の大ファンです。オブジェクト指向ソフトウェアの設計には、他にどのような原則が存在しますか?

ノート。「コードにコメントしてください」のような答えを探しているのではなく、代わりにUncle Bobで議論されているようなオブジェクト指向の設計原則を探しています。

データ入力ツールであるアプリを書き直しています。既存のアプリはAccessにあり、複数のグリッドを持つフォームで構成されています。各グリッドには多くの列が含まれているため、ユーザーは列を表示するために水平方向にスクロールする必要があります。

フォーム上の現在のグリッドは、親子関係で階層的に配置されます。上のグリッドはプロジェクトを表し、下のグリッドは選択したプロジェクトのSKUを表し、下のグリッドは上の選択したSKUのシーズンデータ（価格、出荷情報など）を表します。

この種のアプリの優れたUIデザイン原則に関するアドバイスを探しています。それほどスクロールしなくても、フォーム上のデータのすべての列を表示できる柔軟性をユーザーに提供するフォームを設計するにはどうすればよいですか？

ビジネスアプリのUI原則に関する優れたオンラインリソースは何ですか？

ありがとう！

実装する適切な OO 設計を解読しようとしています。基本的なシナリオは、基本的に常に 0 で始まる 10 桁の電話番号である PstnNumber があることです (例: 0195550000)。先頭の 0 がない場合に数値の自動修正を許可するルールが導入されました (例: 195550000)。

編集開始

元の質問が誤解されている可能性があることに気付きました (すでに回答してくださった方に感謝します)。そのため、シナリオをより適切に説明するために編集しました。

編集終了

私はいくつかの予備的な概念で遊んでみましたが、より適切な方法があるかどうか、またはこれらのいずれかを (あるレベルで) 十分に実行できるかどうかを尋ねると思いましたか?

コンセプト1

コンセプト 2 (削除済み)

コンセプト3

サブクラスが Number プロパティの動作を変更するため、コンセプト 1 は Liskov Substitution ルールに違反する可能性があると思います (誤解していた場合は幸いです)。

代わりの提案は喜んで受け取られます。

ビジネス クラスで System.Windows.Forms を参照し、MessageBox.Show を使用するのは間違っていますか?

現在、サービス クラスを装飾するイベント処理デコレータ クラスがあります。特定のイベントが発生すると、デコレータはユーザーに特定の機能の処理を続行するかどうかを尋ねます。

このデコレータ クラスにこれらのメッセージ ボックスがあっても大丈夫ですか?

ハローみんな

最近私は本を読んでいます：

ボブ・マーチンによる「機敏なソフトウェア開発、原則、パターンおよび実践」

次の（SOLID）アジャイル設計の原則が本の中にリストされています：

• 単一責任の原則
• オープンクローズドプリンシパル原則
• リスコフの置換原則
• インターフェイス分離の原則
• 依存性逆転の原則

この本はかなり古い（2003年）という事実のために、私は質問があります：

1. SOLIDメソッド以外に新しく開発された原則はありますか？もしそうなら、あなたが私に勧めることができる実用的なコード例でこれらの新しい新しい原則をカバーする本/サイトはありますか？

もちろん、私はこれらのいくつかをグーグルで検索することができます。

ただし、stackoverflowでは多くのprofiを読み書きできるので、彼らの意見も聞きたいです：D

オブジェクト指向コンポーネントで、クラスに使用できる実装が1つだけで、そのクラスが他のコンポーネントに「公開」されていない場合でも、インターフェイスを用意して、代わりにインターフェイスを操作することをお勧めしますか？

私は「インターフェースへのプログラミング」の設計原理を十分に認識しており、それを広く使用しています。

最近、私はほとんどの場合、（可能であり、理にかなっているとはいえ）別の実装が必要になることはないことを観察しています。常にインターフェイスを操作する結果として、アプリケーションコードにはかなりの量のインターフェイスがあり、それぞれに1つの実装しかなく、インターフェイスは一種のオーバーヘッドのように見えます。

代わりに、具象クラスを操作して、2番目の実装が必要な場合にのみインターフェースを導入することが望ましいですか？とにかく、最近ではIDEを使用してインターフェイスを抽出するのは簡単です。また、新しいインターフェイスが導入されたときに、古い具象クラスへの参照を変更して、代わりに新しいインターフェイスを使用することができます。

どう思いますか？

つまり、コードを DRY することは良いことだと思われますよね? 私が取り組んでいたプロジェクトの 1 つに、使用されているコンテキストを除いて多かれ少なかれ同じモデル/エンティティが存在する状況がありました。つまり、そのようなすべてのエンティティには、タイトル、説明、タグ、user_id など、その他の属性がありました。したがって、それぞれのコントローラーでの CRUD アクションは非常に似ています。

私のマネージャーは、コードの繰り返しであり、DRY する必要があると主張しました。includeそこで彼は、 d がこれらすべてのエンティティーのコントローラーの CRUD アクションを処理する CRUD ruby​​ モジュールを思いつきました。しかし、最終的にはシンプルさが損なわれました。すべての「もの」が「オブジェクト」と名付けられたため、コードは可読性を失いました。デバッグが難しくなり、コードを DRY する必要がなくなりました。

これはほんの一例でした。それらのいくつかは、ドライアップが複雑でデバッグしにくいコードをもたらしたものです。問題は、いつコードの DRY をやめるべきかということです。コードの単純さが失われていることに毎回気付くとは限らないためです (コードの作成者は、コードの単純さが失われていることにまったく気付かないことがよくあります)。また、シンプルさとドライ コードのどちらかを選択する必要がある場合、どちらか一方しか取得できない状況が発生した場合、何を選択する必要があります。

パフォーマンスを念頭に置いて、ソフトウェアのコンポーネントまたはアーキテクチャの設計に集中することをお勧めしますか? 私が言いたいのは、パフォーマンス集約型の環境で設計/アーキテクチャをどの程度準備する必要があるかということです。

コンポーネントを設計するときは、適切なオブジェクト指向の原則に従い、コンポーネントが「拡張可能」であることを確認する必要があります。このようにして、パフォーマンスの問題が発生したときに、設計をあちこちで少し調整します。この方法では、ソフトウェアを少し調整しても役に立たないパフォーマンスの問題に遭遇することがよくありました。

あるいは、複雑ではありますが、パフォーマンスの問題を簡単に解決できる設計を考え出す必要があります。ソフトウェアを微調整する必要がありますが、設計はパフォーマンス指向であるため、微調整は非常に簡単です。

注: 上記のいずれの場合でも、パフォーマンスの問題が発生する前にソフトウェアのパフォーマンスを調整しようとしているわけではありません。質問を言い換えると、ソフトウェアの設計はパフォーマンス指向である必要がありますか?

ソフトウェアが実行されると予想される環境にすべて依存すると言って、私に答えないでください。その理由は、産業グレードのソフトウェアのクライアントが、常にますます多くのソフトウェアを必要としているように見えるからです。パフォーマンスが重視される環境でソフトウェアを常に実行することを計画していないかもしれませんが、そうしなければならない場合はどうすればよいでしょうか? それを感じたら、ソフトウェアを再設計する必要がありますか?

この質問は 1 週間前から私を悩ませてきましたが、まだ答えがありません。これについてどう思いますか？

C＃とEmguCVを使用した画像処理プロジェクトに取り組んでいます。私たちのチームは3人で構成されています。より速く進歩させるために、私たち3人は異なるサブ問題に取り組むか、同時に異なるアルゴリズムで実験します。

現在、私たち一人一人が、作業中の主要なコードを含む関数を作成し、ドライバーに変更を加えて、新しい関数への呼び出しを追加しています。これはすべて同じファイルで発生します。ソース管理を使用しているので、まだお互いに足を踏み入れていません。しかし、私たちがさらに進歩するにつれて、これが持続可能になるとは思いません。また、コードが乱雑になっているように感じます。

ストラテジーパターンを実装し、アルゴリズムまたはサブ問題処理を独自のクラスにカプセル化し、ドライバーからそれぞれの実行メソッドを呼び出す方がよいと考えていました。

ただし、このアプローチにはいくつかの問題がある可能性があることを認識しています。

1. 異なるアルゴリズムは異なる入力を取ります（ソース画像、いくつかの異なるパラメータのセットなど）
2. 異なるアルゴリズムは異なる出力（新しい画像、機能セット、マトリックスなど）を返します

私がこのようなことをすることによって克服できると私が信じる最初の問題

さまざまな戦略のコンストラクターを変更して、さまざまなタイプの引数を受け入れることができます。

複数の型/値を返す問題に対処する方法を考えるとき、最初に考えることができるのは、executeの戻り型をvoidからハッシュテーブルのようなものに変更することです。ここでは、さまざまな戻りパラメーターを格納して返すことができます。int _returnCode別のメソッドまたはそのクラスの読み取り専用プロパティを介して取得できる""など、クラスの他のメンバーがあります。

これが設計原理の観点からどれほど優れた解決策になるかはわかりません。これについてのご意見をお聞かせいただければ幸いです。ありがとう

リスコフの置換原則についての私の理解は、真である基本クラスのいくつかのプロパティ、または基本クラスの実装された動作は、派生クラスでも真である必要があるということです。

これは、メソッドが基本クラスで定義されている場合、派生クラスでオーバーライドしてはならないことを意味すると思います。派生クラスの代わりに基本クラスを置き換えると、異なる結果が得られるためです。これはまた、（純粋でない）仮想メソッドを持つことは悪いことだと思いますか？

原理の理解が間違っているのではないかと思います。そうしないと、なぜこの原則が良い習慣であるのか理解できません。誰かが私にこれを説明できますか？ありがとう