问题标签 [design-principles]

我听说 Liskov 替换原则 (LSP) 是面向对象设计的基本原则。它是什么，有哪些使用示例？

接口隔离原则 (ISP) 说，许多特定于客户端的接口优于一个通用接口。为什么这很重要？

开放/封闭原则指出软件实体（类、模块等）应该对扩展开放，但对修改关闭。这是什么意思，为什么它是良好的面向对象设计的重要原则？

更新：请在设计原则、优雅、意图表达的背景下阅读此问题，尤其是通过设计选择发送给其他程序员的“信号”。

我有一组对象的两个“视图”。一种是通过字符串值索引对象的字典/地图。另一个是按序数（排序整数）索引对象的字典/地图。没有对象的“主”集合本身可以作为对象数量的权威来源，但是两个字典都应该始终包含对所有对象的引用。

当一个新项目被添加到集合中时，一个引用被添加到两个字典中，然后需要进行一些受新对象总数影响的处理。

我应该使用什么作为权威来源来参考对象集的当前大小？似乎我所有的选择在一个维度上都存在缺陷。我可以始终如一地参考其中一本词典，但这将暗示该词典优于另一本。我可以添加第三个集合，一个简单的对象列表作为权威列表，但这会增加冗余。存储运行计数似乎最简单，但也增加了冗余，并且比动态引用集合的自跟踪计数更脆弱。

是否有其他选择可以让我避免选择较小的邪恶，或者我必须接受优雅的妥协？

如果我添加一个新的案例类，这是否意味着我需要搜索所有模式匹配代码并找出需要处理新类的位置？我最近一直在学习这门语言，当我读到一些支持和反对模式匹配的论点时，我一直对应该在哪里使用它感到困惑。请参阅以下内容：

专业版： Odersky1和 Odersky2

缺点： 比斯特

每种情况下的评论也都很好。那么模式匹配是令人兴奋的东西还是我应该避免使用的东西？实际上，我想答案是“这取决于您何时使用它”，但是它有哪些积极的用例，哪些是消极的用例？

I know that the default answer is "it depends", but I want to know the feature list you are working from in developing a good application.

I'm particularly interested in features that need to be cared about at design time because adding them late will cost us a lot.

Please list one feature per answer so we can vote for the most important features.

Any extra info, like your own war stories, will be appreciated.

I ask this question to enhance my application from day zero, and I think I'm not the only one with this target, so please write whatever feature YOU think should be exist in a good application.

有谁知道为什么某些 HTML 表单控件可以使用System.Web.Mvc.HtmlHelper（隐藏、复选框、密码、文本框）呈现，而有些不能并且应该明确地用 HTML（文件、提交）编写？这种分离的原理是什么？

我是用户控件的新手，到目前为止只创建了一个，所以请耐心等待。我今天一直在阅读，用户控件应该是自包含的，不依赖于父容器中的任何信息。我明白了那部分，但我无法理解的是围绕该原则设计我的程序的“正确”方式。

我正在用 C# 制作一个 Web 表单，其中有一个页面，该页面中有一个用户控件。我已经在它的 ascx 文件中创建了 usercontrol 并将它拖到我的 aspx 页面中。用户控件是一对日期框和一个网格视图，用于显示 SQL 存储过程的结果。

我真的很想重用这个控件，但我不知道如何“告诉”用户控件我想为我所在的特定页面运行什么存储过程而不违反“不要依赖父容器”规则。

谢谢

我正在查看我正在考虑申请的职位描述，其中列出的要求之一是“熟悉元数据设计原则”。

有人可以简单解释一下吗？我可能熟悉这个概念，但我以前从未听说过这个术语。

我用谷歌搜索更多信息，但没有得到好的结果。除了这份题为“元数据原则和实用性”的白皮书。它有点重，我希望能找到一个快速的解释。

附加说明：感谢到目前为止的所有答案。他们一直很好。我想澄清一下我熟悉什么是元数据，但我从未听说过“元数据设计原则”。元数据有哪些设计原则？对于一本书来说，这是一个足够大的主题吗？小册子？正如罗伯特·哈维（Robert Harvey）指出的那样，这听起来像是人力资源部门的某个人发明的一个模糊的术语。

牛仔程序员需要一些 SO-veterans 的帮助：

我有一个给定的应用程序，它使用从文件中读取的书目（实际上，它可以是不同的文件，但我们假设只有一个文件）。

我构建了一个新的应用程序，它应该以与应用程序相同的方式使用参考书目，所以我复制了相应的类。

几天后，我开始运行 %-| ...

问题如下：

在 Bibliography 类中，有代码可以读取、编写和保存参考书目。当有一个类可以阅读参考书目和一个保存所有值的容器类时，我的工作会容易得多。我不想编写或编辑参考书目，只需将其读入并保留值。

那么我的想法是否正确，最好将参考书目类划分为 BibliographyReader、BibliographyWriter 和 Bibliography(Container) 类？

PS：有人可以创建一个标签“cowboy coder”、“cowboy coding”或类似的东西吗？我真的很想念这个标签；）