什么是自以为是的软件？

Question

我经常看到人们说某些软件“非常自以为是”，或者微软倾向于编写“无意见”的框架。这究竟意味着什么？

Answer 1

如果一个框架是固执己见的，它会锁定或引导你进入他们的工作方式。

例如：有些人认为模板系统不应该提供对用户定义的方法和函数的访问，因为它使系统保持打开以返回原始HTML。因此，一个自以为是的框架开发人员只允许访问数据结构。按照设计，该软件是限制性的，并鼓励设计师以自己的方式做事。

另一个例子（taken from the signals link）是wiki的例子。维基的设计者有很多意见。他们认为HTML太复杂，人们无法写，所以他们想出了一种更自然的方式来更新内容。他们也剥夺了它的花哨设计，因为他们认为重点应该放在内容而不是设计上。

Apple在设计产品时有很强的意见。

毫无疑问的软件设计 更像是PERL / PHP。它允许开发人员并信任开发人员做出正确的决策并将更多控制权交给他们。

我还会将微软放在非意见专栏中。微软框架的一个很好的例子，它没有被贬低：.NET。通过打开CLR和规范，它打开了各种语言和实现风格。

Answer 2

意见软件意味着基本上有一种方式（正确的方式™）来做事情，尝试以不同的方式做事将是困难和令人沮丧的。另一方面，通过正确的方式™做事可以使软件开发变得非常容易，因为您必须做出的决策数量减少，软件设计人员能够专注于使软件工作增加。如果您的问题很好地映射到解决方案，那么使用意见软件可以很好用。解决问题中未映射到所提供工具的那些部分可能是一个真正的痛苦。这里的一个例子是Ruby on Rails。

另一方面，非自以为是的软件给用户（开发人员）留下了很大的灵活性。它没有禁止解决问题的一种方法，但提供了可用于以多种方式解决问题的灵活工具。这可能是因为工具非常灵活，因此开发任何解决方案可能相对困难。更多的解决方案可能必须由用户（开发人员）手动编码，因为框架没有提供足够的帮助。您还必须考虑更多关于如何提供解决方案的问题，而平庸的开发人员可能最终得到的解决方案比他们购买某些固定软件的解决方案更差。 PERL可能是非自以为是的软件的典型例子。

我的理想是一个非自以为是的框架，但具有强烈的惯例。我会把ASP.NET MVC放在这个类别中。实际上，所有软件在某种程度上都是固执的（尽管可能不是PERL）。 MVC在选择模型时有很强的约定，但提供了许多不同的方法来解决这些约定中的问题。其中一些方法甚至可能打破模型。然而，正确使用，根据在这样的框架中发展的惯例可能是一个真正的快乐。

Answer 3

它基本上是以其作者认为应该工作的方式运行的软件，而不是试图取悦所有人。这意味着很多人不会喜欢它，但那些喜欢它的人会喜欢它。

Rails可能是一个自以为是的框架的典型例子：你按照自己的方式做事，一切都很顺利。如果你不这样做，那你就会有些痛苦。但是没关系 - 如果你不想按照自己的方式做事，你不想使用Rails。

Answer 4

为了平衡，我将提供一个（相当自以为是）的描述，这种描述更有利于自以为是的方法（与其他一些答案形成鲜明对比）。

意见框架提供了一条“黄金之路”，这应该是大多数人和大多数情景的最佳实践（在作者看来）。

然而，这并不一定意味着锁定。这意味着可能需要一些额外的努力来做不同的事情。

不太自以为是的框架提供了许多不同的选项，由您决定。

意见框架通常可以减轻开发人员重新发明轮子的负担，或者一次又一次地重新考虑同样的问题，从而有助于专注于手头的真正问题。

在开源世界中，您可以找到许多自以为是的竞争框架，因此您仍然可以选择。你只需要选择自己的黄金道路。

Answer 5

Opinionated软件的构建和设计使其能够以某种方式轻松完成任务。它比其他设计模式更有利于某些设计模式。在这个过程中，它很难偏离开发它的软件开发风格。另一种表达方式是它支持“约定优于配置”。即配置选项非常有限，因为软件假设许多配置方面。一旦理解了假设，通常可以更快地掌握意见软件。

另一方面，未经宣传的软件几乎没有假设。因此，不受影响的软件/软件开发框架往往具有许多配置选项。开发人员通常必须就软件的各个方面做出很多决定。通常，开发了各种工具，以便更容易地处理这些巨大的选项。例如用于.NET的Visual Studio .NET，用于Java的Eclipse IDE等。无论是软件，通常需要更长时间才能掌握软件。

Answer 6

<强> TL;博士：

• 意见：例如 Ruby on Rails 。有一种特别优选的做事方式，你可以通过这种方式得到很多支持。以其他方式做事很难，或者某些系统不可能（Cassandra浮现在脑海中）。
• 无意见：例如 Perl 5 。你可以用任何方式做任何你喜欢的事情。所有款式均同样开放，有效且受支持。

Answer 7

很多人都将ASP.NET MVC作为一个“不受欢迎的”框架引用，我只是想对此提出几点看法。

ASP.NET MVC确实没有强制要求;您可以使用任何您喜欢的持久性解决方案，无论是Linq-to-SQL，ADO.NET实体，NHibernate等。

另一方面，MVC框架确实倾向于支持“约定优于配置”，引用Phil Haack，它强烈建议遵循用于定位控制器，视图，模型和其他代码的预定义模式。虽然你可以改变这种行为，但是用当前的游戏更容易游泳，对大多数人来说，这样做没有问题。

围绕ASP.NET MVC也是很多自以为是的人，我发现这些人会导致许多有偏见的教程，这些教程坚持覆盖，例如：单元测试和依赖注入;我都是为了进行良好的测试和关注点的分离，但我确实认为这些话题会被一点点扼杀，通常会覆盖更多有用的基础知识。

再一次，我必须承认，在这些领域内，框架本身完全可以采用您想要的任何单元测试解决方案，以及您想要使用的任何依赖注入和模拟框架，所以我想这提供了另一个灵活性的例子，即使在单元测试的“圣经抨击”等中，也似乎正在进行。

Answer 8

这是在框架中实施的约定数量以及已经采取的决策数量。

例如，如果有5种（或更多种）不同的方式将表单数据提交给控制器操作（在ASP.NET MVC中就是这种情况），那么该框架似乎非常“不言自明” - 决定取决于你！

但是，如果框架启用（通过直接禁用其他方式，或通过强烈鼓励它）只有一种方法（Fubu MVC就是这种情况），你可以说已经做出了决定通过框架，从而使框架自以为是。

Answer 9

目前您将看到很多的示例是ASP.NET MVC框架。这是令人惊讶的可扩展性，但这是它在某些方面的垮台，没有任何肉。想要进行数据访问吗？你必须自己写。想要一些AJAX吗？同上。

然而，由于它是高度可扩展的，如果你在它上构建，你可以把它变成一个自以为是的框架。这就是MVCContrib之类的行为，它们为您提供了特定的处理方法，这意味着您必须编写更少的代码。

这确实意味着，如果你想要打破这种观点，那么通常需要做的工作比你在使用香草版本时要多。这是一个80/20的场景。如果你正确地选择了自己认同的框架，那么你只想在20％的时间内从意见中脱离出来，而在其他80％的时间里你都会高效率。