什么是自以为是的软件？

我经常看到人们说某些软件“非常固执”，或者微软倾向于编写“无主见”的框架。这实际上意味着什么？ 1 如果一个框架固执己见，它会锁定或引导您进入他们的行事方式。例如：有些人认为模板系统不应该提供对用户定义的方法和函数的访问，因为它使系统对返回原始 HTML 保持开放。因此，固执的框架开发人员只允许访问数据结构。通过设计，软件限制并鼓励设计师按照他们的方式做事。另一个例子（取自信号链接）是维基的例子。 wiki 的设计者有很多意见。他们认为 HTML 对人们来说太复杂了，所以他们想出了一种他们认为更自然的方式来更新内容。他们还取消了花哨的设计，因为他们觉得重点应该更多地放在内容上而不是设计上。无主见的软件设计更像是 PERL/PHP。它允许开发人员并信任开发人员做出正确的决定，并将更多的控制权交给他们。我还将 Microsoft 置于无意见专栏中。 Microsoft 框架的一个很好的例子，它是非独立的：.NET。通过开放 CLR 和规范，它向各种语言和实现风格开放。

5 我不会说“锁定你”，而是说它不容易偏离“黄金”路径。黄金路径通常是最佳实践，应该在大多数情况下对大多数人有效。 – dpan 我同意锁有点强，但我会通过注意到许多自以为是的产品是多么成功来消除这种负面含义。 – cgp 一个自以为是的框架是这样一种设计的，当框架以不违反框架设计者的假设的方式使用时，它的用户将对该框架产生最少的摩擦。 – Crippledsmurf 我同意 altCognito。 .NET 鼓励开发人员在 WinForms 应用程序中混合模型和视图，例如，通过将业务逻辑放在按钮单击事件生成的方法中变得容易。通过这种方式，微软间接鼓励短视的开发人员将他们的代码锁定在他们的框架中。更简洁的设计将强制或鼓励更好的实践，例如强制按钮单击方法在单独的模块中使用模型逻辑调用第二个函数。并不是在 .NET 中无法实现简洁的设计，只是默认情况下不鼓励这样做。 – Jared Updike 有意见的软件意味着基本上只有一种方法（正确的方法™）来做事，而尝试以不同的方式做事将是困难和令人沮丧的。另一方面，以正确​​的方式做事™ 可以使软件开发变得非常容易，因为您必须做出的决定数量减少了，软件设计人员专注于使软件工作的能力增加了。如果做得好，如果您的问题很好地映射到解决方案上，则有意见的软件可以很好地使用。解决那些未映射到所提供工具的问题部分可能会很痛苦。这里的一个例子是 Ruby on Rails。另一方面，无意见软件为用户（开发人员）留下了很大的灵活性。它并没有禁止一种解决问题的方法，而是提供了可用于以多种方式解决问题的灵活工具。这样做的缺点可能是，由于工具非常灵活，因此开发任何解决方案可能相对困难。更多的解决方案可能必须由用户（开发人员）手动编码，因为该框架没有提供足够的帮助。您还必须更多地考虑如何提供解决方案，与购买某些固执己见的软件相比，平庸的开发人员最终可能会得到更糟糕的解决方案。 PERL 可能是无意见软件的典型例子。我的理想是一个没有意见的框架，但有很强的约定。我会把 ASP.NET MVC 放在这个类别中。实际上，所有软件都在某种程度上自以为是（尽管可能不是 PERL）。 MVC 在选择模型方面有很强的约定，但提供了许多不同的方法来解决这些约定中的问题。其中一些方法甚至可能打破模型。然而，正确地使用，按照在这样一个框架中开发的惯例可以是一种真正的乐趣。

0 它基本上是按照作者认为应该工作的方式工作的软件，而不是试图取悦所有人。这意味着很多人不会喜欢它，但喜欢它的人会喜欢它。 Rails 可能是自以为是的框架的典型例子：你按照他们的方式做事，一切都很顺利。如果你不这样做，你会很痛苦。但是没关系——如果你不想按照他们的方式做事，你就不想使用 Rails。 1 我同意这一点.... 我有一个opiniated 软件...它的opinied 因为它是我的小宠物项目...我不知道它会被广泛采用...有些人喜欢它，其他人抱怨。 .. 但他们都明白这是我的宠物项目 - TimothyP 为了平衡起见，我将提供一个（相当自以为是的）描述，它更适合自以为是的方法（与其他一些答案相反）。自以为是的框架提供了一条“黄金路径”，这应该是大多数人和大多数场景（在作者眼中）的最佳实践。然而，这并不一定意味着锁定。这意味着可能需要一些额外的努力才能以不同的方式做事。

不那么自以为是的框架提供了许多不同的选择，并由您决定。自以为是的框架通常会减轻开发人员重新发明轮子或一遍又一遍地重新思考同一问题的负担，从而有助于专注于手头的真正问题。在开源世界中，您可以找到许多固执己见但相互竞争的框架，因此您仍有选择的余地。你只需要选择你自己的黄金之路。 1 +1，感觉就像你提到的企业应用程序。 Siebel 有一条不容易打破的黄金之路，尽管它可以做到，而且我在一个偶尔会这样做的团队中工作。它可以加快开发进度，因为您不必一直开发 UI 元素、数据存储和业务逻辑。 – J. Polfer Opinionated 软件的构建和设计方式使得以某种方式做事变得容易。它比其他设计模式更偏爱某些设计模式。在此过程中，很难偏离其开发所针对的软件开发风格。另一种说法是它支持“约定优于配置”。即配置选项非常有限，因为软件承担了许多配置方面。一旦理解了假设，有意见的软件通常会更快地掌握。另一方面，没有意见的软件几乎不做任何假设。因此，不受约束的软件/软件开发框架往往有很多配置选项。开发人员通常必须就软件的各个方面做出很多决定。通常，开发了各种工具以便更轻松地处理这些巨大的选择。例如，用于 .NET 的 Visual Studio .NET、用于 Java 的 Eclipse IDE 等。与固执己见的软件相比，非主见的软件通常需要更长的时间来掌握。自以为是：例如Ruby on Rails。有一种特别受欢迎的做事方式，你会在这种方式下获得很多支持。以其他方式做事很困难，或者对于某些系统来说是不可能的（想到 Cassandra）。

不自以为是：例如 Perl 5。你可以做任何你喜欢的事情，任何你喜欢的方式，任何风格。所有样式都同样开放、有效和受支持。很多人都将 ASP.NET MVC 称为“无主见”的框架，我只是想对此发表一些想法。确实，ASP.NET MVC 并没有要求太多；你可以使用任何你喜欢的持久化解决方案，无论是 Linq-to-SQL、ADO.NET 实体、NHibernate 等。另一方面，MVC 框架确实倾向于“约定优于配置”，引用 Phil Haack 的话强烈建议遵循预定义的模式来定位控制器、视图、模型和其他代码。尽管您可以改变这种行为，但顺流而下更容易，而且对大多数人来说，这样做没有问题。围绕 ASP.NET MVC 的还有很多固执己见的人，我发现这导致了很多有偏见的教程，这些教程坚持要涵盖，例如单元测试和依赖注入；我完全赞成良好的测试和关注点分离，但我确实认为这些主题被推到了喉咙里，通常在涵盖更有用的基础知识之前。再次，我必须承认，在这些领域中，框架本身完全可以采用您想要的任何单元测试解决方案，以及您想要使用的任何依赖注入和模拟框架，所以我想这提供了另一个例子灵活性，即使在单元测试等的“圣经抨击”中也是如此。它是框架中实施的约定数量和已做出的决定数量。

例如，如果有 5 种（或更多）不同的方式将表单数据提交给控制器操作（在 ASP.NET MVC 中就是这种情况），则该框架似乎非常“无主见”- 决定了给你！但是，如果框架仅启用（通过直接禁用其他方式，或通过强烈鼓励）仅一种方式来做那件事（Fubu MVC 就是这种情况），您可以说该决定已由框架做出，从而使框架自以为是。您现在会经常看到的示例是 ASP.NET MVC 框架。它具有惊人的可扩展性，但这在某些方面是它的缺点，它没有任何内容。想做数据访问？你必须自己写。想要一些 AJAX 吗？同上。然而，由于它是高度可扩展的，如果你在它的基础上构建，你可以把它变成一个固执己见的框架。这就是 MVCContrib 之类的工作，它们为您提供了特定的做事方法，这意味着您必须编写更少的代码。这确实意味着，如果您想打破这种观点，通常比使用香草版本有更多的工作要做。不过，这是一个 80/20 的场景。如果你正确地选择了你的自以为是的框架，你只会想在 20% 的时间里打破意见，而在其他 80% 的时间里你会非常高效。 1 ASP.NET MVC 似乎很自然地适合 ASP.NET AJAX 框架，甚至包括对该库的特定于 MVC 的补充，所以我不同意 Ajax 实现的选择是完全公正的。此外，该库并没有特别要求甚至推荐 jQuery 的 ue，但它确实捆绑了它，在嘴里偷偷地朝那个方向示意，“看看这个”。 – Rob 不是您要找的答案？浏览其他标记的问题或提出您自己的问题。