库好于框架 - brandonsmith

20-05-09 banq

代码通常可以采用两种粗俗的形式:库或框架。

库是一组构建块,它们可以共享一个共同的主题或可以很好地协同工作,但是在很大程度上是独立的。

框架是包含编写代码的上下文。可以是采取控制反转,特定于领域的语言的形式,也可以只是一种很自以为是且内部耦合的库。

两者之间没有界限。判断是否为框架或库的一种方法是问自己:“我可以将其与其他类似框架结合使用吗?或者它是否建立了与其他方式可以互斥的方式?”

框架的主要特征是它们对程序员施加了限制。他们没有提供程序员可以做的一系列新事情,而是在程序员可以做的事情上建立了界限。为了换取灵活性,他们通常消除样板,为在其之上构建新库建立试金石,并允许程序员的技能成为更具可移植性的项目。实际上,有时限制本身是可取的!毕竟,类型系统不过是对代码施加限制的一种方式。局限性并不是本质上的坏处。

然而。当您编写一个期望其他人用来构建真实项目的框架(即,它不仅仅是一个玩具)时,您承担的责任要比库更大。

通常,框架必须提前预测其用户可能需要在其内部进行的各种操作。它必须承担起相应的责任。它需要提供一个正常完成各种操作的方式,否则,为什么要使用它?

这也转化为开发人员的经验。您的框架是否引入了超出基本语言的基于约定的行为?您最好彻底记录下来,否则用户将无可救药地迷路。您是否引入特定领域的语言?您现在负责构建链的一部分,并负责编辑器集成。

现在,如果有一个主要组织来支持该框架,那么计算就可能成功了。Google可以支持Angular,Pivotal可以支持Spring,Epic可以支持Unreal Engine。在这些情况下,可以采用框架方法,因为存在着资源和意愿,可以真正覆盖所有需要覆盖的基础。

因此,我的观点:框架并不总是坏的,但是与库相比,对于创建者和用户而言,框架带来的风险要大得多。如果您的框架可以是一个库而又不会损失很多,那就作为库。如果您不在大型科技公司工作,那么您可能没有时间或精力来提供框架所需的全部精力。库不是万能的,但它们应该是首选。

 

                   

1
猜你喜欢