什么是自以为是的软件?

我经常看到人们说某些软件“非常固执己见”,或者微软倾向于编写“不固执己见”的框架。这到底是什么意思呢?

87163 次浏览

如果一个框架是固执己见的,它就会把你锁定或引导到他们做事的方式中。

例如:有些人认为模板系统不应该提供对用户定义的方法和函数的访问,因为它让系统对返回原始HTML开放。因此固执己见的框架开发人员只允许访问数据结构。在设计上,软件是限制和鼓励设计师按照他们的方式做事。

另一个例子(从信号中截取链接)是维基。wiki的设计者有很多意见。他们认为HTML对人们来说太复杂了,所以他们想出了一种他们认为更自然的方式来更新内容。他们还去掉了花哨的设计,因为他们觉得重点应该更多地放在内容上而不是设计上。

苹果公司在设计产品时有很强的主见。

没有主见的软件设计更像PERL/PHP。它允许开发人员和信任开发人员做出正确的决策,并将更多的控制权交到他们手中。

我还会把微软放在不固执己见的那一栏。一个很好的微软框架的例子,它是没有意见的:通过开放CLR和规范,它向各种语言和实现风格开放了。

它基本上是一种软件,以其作者认为它应该工作的方式工作,而不是试图取悦每个人。这意味着很多人不会喜欢它,但喜欢它的人会喜欢它。

Rails可能是固执己见的框架的典型例子:您按照它们的方式做事,一切都很顺利。如果你不这样做,你就会很痛苦。但这也没关系——如果你不想按照他们的方式做事,你就不想使用Rails。

它是一个框架中实现的约定的数量和已经做出的决定的数量。

例如,如果有5种(或更多)不同的方式将表单数据提交给控制器动作(在ASP中就是这种情况)。NET MVC),框架似乎是相当“不固执己见”-决定是由你!

然而,如果框架只支持(通过直接禁用其他方式,或通过强烈鼓励)一种方式来做那件事(Fubu MVC就是这种情况),你可以说这个决定是由框架做出的,从而使框架固执己见。

固执己见的软件意味着基本上有一种方法(正确的方式™)来做事情,试图以不同的方式去做将是困难和令人沮丧的。另一方面,做正确的方式™可以使软件开发变得非常容易,因为你必须做的决定的数量减少了,软件设计师集中精力使软件工作的能力增加了。如果做得好,如果你的问题能很好地映射到解决方案上,有主见的软件会很好用。解决问题中无法映射到所提供的工具的部分可能真的很痛苦。Ruby on Rails就是一个例子。

另一方面,不固执己见的软件给用户(开发人员)留下了很大的灵活性。它没有禁止解决问题的一种方法,而是提供了灵活的工具,可以用多种方式解决问题。这样做的缺点是,由于工具非常灵活,开发任何解决方案都相对困难。由于框架没有提供足够的帮助,解决方案的更多部分可能必须由用户(开发人员)手工编码。您还必须更多地考虑如何提供解决方案,而平庸的开发人员最终可能会得到比购买一些固执己见的软件更差的解决方案。PERL可能是无主见软件的经典例子。

我的理想是一个不固执己见的框架,但有很强的惯例。我会写ASP。NET MVC在这个类别中。实际上,所有的软件在某种程度上都是固执己见的(尽管PERL可能不是)。MVC在模型的选择上有很强的约定,但在这些约定中提供了许多不同的解决问题的方法。其中一些方式甚至可能会打破模式。然而,正确地使用,按照在这样的框架中开发的约定可以是一种真正的乐趣。

目前您将经常看到的例子是ASP。NET MVC框架。它具有惊人的可扩展性,但这在某些方面是它的缺点,它没有任何实质内容。想要进行数据访问?你得自己写。想要AJAX吗?同上。

但是,由于它是高度可扩展的,如果您在此基础上进行构建,则可以将其转换为独立的框架。这就是之类的东西所做的,它们给你特定的做事方法,这意味着你必须写更少的代码。

这确实意味着,如果你想要打破这种观点,你要做的工作往往比你在香草版本上做的工作要多。不过,这是一种80/20的情况。如果你正确地选择了你的固执己见的框架,你只会在20%的时间里想要打破观点,而在其他80%的时间里你会非常高效。

为了平衡起见,我将提供一种(相当固执己见的)描述,这种描述更有利于固执己见的方法(与其他一些答案相反)。

固执己见的框架提供了一条“黄金路径”,它被认为是大多数人和大多数场景的最佳实践(在作者的眼中)。

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

不那么固执己见的框架提供了许多不同的选项,并由您自己决定。

有主见的框架通常会减轻开发人员重新发明轮子或一次又一次重新思考同一个问题的负担,从而帮助他们专注于手头的真正问题。

在开源世界中,你可以找到许多固执己见但又相互竞争的框架,所以你仍然有选择的余地。你只需要选择你自己的黄金之路。

很多人都在引用ASP。NET MVC是一个“不受约束的”框架,我只是想就这一点发表一些看法。

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

另一方面,MVC框架倾向于“约定大于配置”,引用Phil Haack的话,他强烈建议遵循预先定义的模式来定位控制器、视图、模型和其他代码。虽然你可以改变这种行为,但随着水流游泳更容易,对大多数人来说,这样做没有问题。

也围绕ASP。NET MVC有很多固执己见的人,我发现这导致了很多有偏见的教程,坚持覆盖,例如单元测试和依赖注入;我完全支持良好的测试和关注点分离,但我确实意识到,在涉及更有用的基础知识之前,这样的主题被强行灌输给了一个人。

在这里,我不得不承认在这些领域中,框架本身是完全开放的,可以采用任何你想要的单元测试解决方案,以及任何你想要使用的依赖注入和模仿框架,所以我猜这提供了另一个灵活性的例子,即使是在单元测试等似乎正在进行的“圣经抨击”中。

有主见的软件是以这样一种方式构建和设计的,它使以某种方式做事变得容易。它更偏爱某些设计模式。在这个过程中,它很难偏离软件开发的风格。另一种说法是它更倾向于“约定而不是配置”。即,配置选项是非常有限的,因为软件承担了许多配置方面。一旦理解了假设,有主见的软件通常会更快地掌握。

另一方面,无偏见的软件很少做假设。因此,没有划分的软件/软件开发框架往往有很多配置选项。开发人员通常必须就软件的各个方面做出很多决定。通常,为了更容易地处理这些巨大的选项,开发了各种工具。例如Visual Studio . net for . net, Eclipse IDE for Java等。不武断的软件通常比武断的软件需要更长的时间来掌握。

博士tl;:

  • 固执己见的:例如Ruby on Rails。有一种特别受欢迎的做事方式,你用这种方式做事会得到很多支持。用其他方法做事是困难的,或者对某些系统来说是不可能的(想到了Cassandra)。
  • Un-opinionated:例如Perl 5。你可以做任何你喜欢的事,任何你喜欢的方式,任何风格。所有样式都是同样开放、有效和受支持的。