什么是依赖倒置原则，为什么它很重要？

您最实用的用户友好用户界面设计或原则是什么？

请提交您发现实际上使事情真正有用的那些实践 - 无论如何 - 如果它对您的用户有用，请分享它！

摘要/整理

原则

1. 吻。
2. 清楚和具体地说明一个选项将实现什么：例如，使用动词来指示将遵循一个选择的动作（参见：Impl. 1）。
3. 使用适合用户需要/想要实现的明显默认操作。
4. 使 UI 的外观和行为适合环境/流程/受众：独立应用程序、网页、便携、科学分析、flash 游戏、专业人士/儿童……
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]

在进行班级设计时，您通常遵循哪些原则？

I was listening to a podcast. Where they talked about principles Toyota was using:

Never do anything until you are ready to use it.

I think this tells us to look in other places, to learn what other practices have been known for years.

在丰田生产线中，他们总是知道零件经过了什么路径。这样他们就可以确定他们可以解决问题。这也适用于软件吗？

所有错误消息都应该准确地告诉我他们走过的路径。有些会，带有堆栈跟踪的错误消息。这是一个正确的解释吗？它可以在其他地方使用吗？

好的，这是播客。我觉得很有趣

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

我出去跑步了……听一个关于丰田的播客……无论如何。

我认为这个原则不会在软件项目中使用。（也许是项目管理）。艺术还很年轻。目前，我们不知道我们在做什么。但最终，我们会的。

或者，有人知道如何使用这个核心原则吗？

好的，这是播客。我觉得很有趣

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

我找不到对它的引用，但我记得读过在析构函数或 IDisposable 的 Dispose() 方法中调用虚拟（多态）方法不是一个好主意。

这是真的吗，如果是这样，有人可以解释为什么吗？

将类组织到命名空间中是否有一些原则？

例如，如果命名空间 N 中的类依赖于 NX 中的类，是否可以？如果来自 NX 的类依赖于来自 N 的类？

前提

我相信有一种方法可以客观地定义“好”和“坏”的面向对象设计技术，并且作为一个社区，我们可以确定它们是什么。这是一个学术练习。如果以认真和决心完成，我相信这将对整个社区大有裨益。社区将受益于拥有一个我们都可以指出的地方，“这种技术是‘好’或‘坏’，除非有特殊情况，否则我们应该或不应该使用它。”

计划

对于这项工作，我们应该关注面向对象的原则（而不是函数式、基于集合或其他类型的语言）。

我不打算接受一个答案，而是希望这些答案有助于最终收集或成为对问题的理性辩论。

我意识到这可能会引起争议，但我相信我们可以解决一些问题。大多数规则都有例外，我相信这就是分歧所在。我们应该作出声明，然后注意相关的例外情况和反对者的反对意见。

基础

我想尝试定义“好”和“坏”：

• “好” - 这种技术将第一次起作用，并且是一个持久的解决方案。以后很容易更改，并且会很快支付其实施的时间投资。它可以在未来得到维护程序员的一致应用和轻松识别。总体而言，它有助于实现良好的功能并降低产品生命周期内的维护成本。

• “坏” - 这种技术可能在短期内有效，但很快就会成为一种负担。很难立即改变或随着时间的推移变得更加困难。初始投资可大可小，但很快就会成为不断增长的成本，最终成为沉没成本，必须不断消除或解决。它是主观应用且不一致的，将来可能会令人惊讶或不容易被维护程序员识别。总体而言，它会导致最终增加维护和/或操作产品的成本，并抑制或阻止对产品的更改。通过抑制或阻止变化，它不仅成为直接成本，而且成为机会成本和重大责任。

起动机

作为一个我认为好的贡献应该是什么样子的例子，我想提出一个“好的”原则：

关注点分离

[简短的介绍]

例子

[代码或其他类型的示例]

目标

[解释这个原则可以防止什么问题]

适用性

[为什么，在哪里，什么时候使用这个原则？]

例外

[我什么时候不使用这个原理，或者它实际上在哪里有害？]

异议

[请在此处注意来自社区的任何不同意见或反对意见]

由于这是一个使用各种不同技术的广泛社区，因此提出这个问题似乎是合适的地方。

您喜欢编译还是喜欢编写脚本？

我问这个是因为我倾向于用我实际需要的选定模块（如 Lua、Awk、AutoHotKey ......）用小型脚本语言来编写东西，而不是用成熟的非便携式 IDE 和大的一刀切的主流语言来编程每一个小改动都需要加载和重新编译项目的库。

我喜欢我真正需要更改/修复/更新项目的唯一工具是我碰巧运行脚本的任何系统上可用的任何编辑器（当然，解释器是我可以随身携带的单个可执行文件或立即从 Internet 下载并保存在磁盘上，无需任何安装程序）。

我也很高兴知道任何想要更新项目的人除了编辑器之外不需要任何其他东西——没有臭名昭著的编译问题、依赖问题等，而且任何不喜欢我放在那里的按钮的人都可以打开文件并将其放在他想要的任何地方，甚至在几分钟内将其删除。

我问这个是因为我注意到有些程序员倾向于认为任何不是本机可执行文件的东西都不够好。我什至记得论坛上的一篇帖子，我保存了我的一个开源应用程序 - 另一位程序员说“好应用程序，但它不是 .exe ”