依存関係逆転の原則とは何ですか? なぜ重要なのですか?

実用的で使いやすいユーザー インターフェイスの設計または原則は何ですか?

あなたが実際に物事を本当に役立つと思う実践を提出してください - それがあなたのユーザーにとってうまくいくなら、それを共有してください!

まとめ・照合

原則

1. 接吻。
2. オプションが何を達成するかを明確かつ具体的にしてください。たとえば、選択に続くアクションを示す動詞を使用します (Impl. 1 を参照)。
3. ユーザーが必要としている/達成したいものに適した、明白な既定のアクションを使用します。
4. UI の外観と動作を環境/プロセス/視聴者に合わせる: スタンドアロン アプリケーション、Web ページ、ポータブル、科学分析、フラッシュ ゲーム、専門家/子供など...
5. 新規ユーザーの学習曲線を短縮します。
6. オプションを無効にしたり非表示にしたりするのではなく、ユーザーが代替手段を持つことができる場合に役立つメッセージを提供することを検討してください。代替手段がない場合は、オプションを無効にすることをお勧めします - オプションが使用できないことを視覚的に示します - 使用できないオプションを非表示にせず、マウスオーバー ポップアップで無効にする理由を説明します。
7. 広く使用されている成功したアプリケーションで実装されているように、一貫性を保ち、プラクティスとコントロールの配置に準拠します。
8. ユーザーの期待に応え、プログラムをその期待どおりに動作させます。
9. ユーザーの語彙と知識に固執し、プログラマー/実装の用語は使用しないでください。
10. コントラスト (明白さ)、繰り返し (一貫性)、整列 (外観)、および近接 (グループ化) という基本的な設計原則に従います。

実装

1. (paiNie の回答を参照) 「ダイアログ ボックスで動詞を使用してみてください。」
2. 元に戻すとやり直しを許可/実装します。

参考文献

1. Windows Vista ユーザー エクスペリエンス ガイドライン [ http://msdn.microsoft.com/en-us/library/aa511258.aspx]
2. オランダのウェブサイト - 「Drempelvrij」ガイドライン [ http://www.drempelvrij.nl/richtlijnen]
3. Web コンテンツ アクセシビリティ ガイドライン (WCAG 1.0) [ http://www.w3.org/TR/WCAG10/]
4. 一貫性 [ http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746]
5. 考えさせないで [ http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pdbbssr_1?ie=UTF8&s=books&qid=1221726383&sr=8-1]
6. パワフルでシンプルであること [ http://msdn.microsoft.com/en-us/library/aa511332.aspx]
7. ゲシュタルト設計法則 [ http://www.squidoo.com/gestaltlaws ]

クラスの設計を行うとき、あなたは一般的にどのような原則に従いますか？

私はポッドキャストを聞いていました。彼らがトヨタが使用していた原則について話した場所：

使用する準備ができるまで、何もしないでください。

これは、他の場所に目を向け、何年も前から知られている他の慣行を学ぶことを私たちに教えていると思います.

トヨタの製造ラインでは、部品がどのような経路をたどったかを常に把握しています。何か問題が発生した場合に修正できることを確認できるようにするためです。これはソフトウェアにも当てはまりますか？

すべてのエラー メッセージは、移動したパスを正確に教えてくれるはずです。いくつかは、スタック トレースのエラー メッセージです。これは正しい解釈ですか？他の場所で使用できますか？

わかりました、これがポッドキャストです。面白いと思います

http://itc.conversationsnetwork.org/shows/detail3798.html

私は走っていました.. トヨタについてのポッドキャストを聞いていました.. とにかく.

この原則は、ソフトウェア プロジェクトでは使用されないと思います。（おそらくプロジェクト管理）。芸術はまだまだ未熟です。現時点では、私たちが何をしているのかわかりません。しかし、最終的にはそうするでしょう。

あるいは、この核となる原則の使い方を理解している人はいますか?

わかりました、これがポッドキャストです。面白いと思います

http://itc.conversationsnetwork.org/shows/detail3798.html

私はそれへの参照を見つけることができませんが、デストラクタ内または IDisposable の Dispose() メソッド内で仮想 (ポリモーフィック) メソッドを呼び出すことは良い考えではないことを読んだことを覚えています。

これは本当ですか?もしそうなら、誰かが理由を説明できますか?

クラスを名前空間に編成する原則はありますか?

たとえば、名前空間 N のクラスが NX のクラスに依存していても問題ないでしょうか? そして、NX のクラスが N のクラスに依存する場合は?

前提

私は、オブジェクト指向設計手法の「良い」と「悪い」を客観的に定義する方法があり、コミュニティとしてこれらが何であるかを判断できると信じています。これはアカデミックな演習です。本気でやり遂げれば、コミュニティ全体に大きな利益をもたらすと信じています。コミュニティは、「このテクニックは『良い』か『悪い』かであり、特別な状況がない限り使用すべきか、使用すべきではない」と指摘できる場所を持つことで利益を得ることができます。

プラン

この取り組みでは、(関数型、セットベース、またはその他のタイプの言語とは対照的に) オブジェクト指向の原則に焦点を当てる必要があります。

私は 1 つの回答を受け入れるつもりはありません。代わりに、回答が最終的なコレクションに貢献するか、問題の合理的な議論になることを望んでいます。

これには賛否両論があるかもしれませんが、私たちは何かを解決できると信じています. ほとんどすべてのルールには例外があり、これが意見の相違の原因になると私は信じています。私たちは宣言を行い、関連する例外と反対者からの異議に注意する必要があります。

基本

「良い」と「悪い」の定義を試してみたいと思います。

• 「良い」 - この手法は初めて機能し、永続的な解決策になります。後で簡単に変更でき、実装に費やした時間の投資をすぐに支払うことができます。これは一貫して適用でき、将来の保守プログラマーによって容易に認識されます。全体として、それは優れた機能に貢献し、製品の寿命全体にわたってメンテナンスのコストを削減します.

• 「悪い」 - この手法は短期的にはうまくいくかもしれませんが、すぐに不利になります。すぐに変更するのが難しいか、時間の経過とともにより困難になります。初期投資は少額でも多額でもかまいませんが、すぐにコストが増大し、最終的にはサンク コストになり、削除するか、常に回避する必要があります。これは主観的に適用されたものであり、一貫性がなく、将来、メンテナンス プログラマーが驚くか、容易に認識できないものになる可能性があります。全体として、それは製品の保守および/または操作の最終的な増加コストに寄与し、製品への変更を抑制または防止します。変化を阻害または防止することにより、それは単なる直接費用ではなく、機会費用および重大な責任になります。

スターター

優れた貢献とはどのようなものかを示す例として、「優れた」原則を提案したいと思います。

関心事の分離

[簡単な説明]

例

[コードまたはその他のタイプの例]

目標

【この原理で防げるトラブルの解説】

適用性

[なぜ、どこで、いつこの原則を使用するのですか?]

例外

[この原則を使用しない場合、または実際に害を及ぼす可能性があるのはどのような場合ですか?]

反対意見

[コミュニティからの反対意見や反対意見はこちらに記入してください]

これは、あらゆる種類の異なるテクノロジーを使用する幅広いコミュニティであるため、これを尋ねるのに適切な場所のようです。

コンパイルが好きですか、それともスクリプトが好きですか？

本格的な非ポータブルIDEと大きなフリーサイズの主流言語ではなく、実際に必要な選択されたモジュール（Lua、Awk、AutoHotKey ...など）を使用して小さなスクリプト言語でプログラムする傾向があるため、これを尋ねます。プロジェクトをロードして再コンパイルするために少しの変更が必要なライブラリ。

プロジェクトを実際に変更/修正/更新するために必要な唯一のツールが、スクリプトを実行するすべてのシステムで使用可能なエディター（そしてもちろん、私が持ち運ぶことができる単一の実行可能ファイルであるインタープリター）であるという機能が好きです。または、インターネットからすぐにダウンロードして、インストール手順なしでディスクに保存するだけです）。

また、プロジェクトを更新したい人はエディター以外は必要ありません-悪名高いコンパイルの問題や依存関係の問題などはありません。また、そこに置いたボタンが気に入らない人は、ファイルを作成して、好きな場所に置いたり、数分で削除したりできます。

ネイティブの実行可能ファイルではないものは十分ではないと考える傾向があるプログラマーがいることに気付いたので、これを尋ねます。オープンソースアプリケーションの1つを保持しているフォーラムへの投稿を覚えています。別のプログラマーが「良いアプリですが、.exeではありません」と言っていました。