百战程序员数据结构 课件_结构之战

百战程序员数据结构 课件

图1显示了结构良好的程序包的spoiklin类图 。

图1：Lucene的良好包装结构。

它具有良好的结构，因为它使依赖关系跟踪相对容易。 如果我们随机选择一个类（例如ReusableStringReader） ，则可以轻松发现该类的依赖关系，从而估算对该类进行更改的潜在成本，请参见图2。

图2：跟踪对ReusableStringReader的依赖关系。

但是，依赖有两种形式。 句法依存关系不依赖于所连接节点名称的含义。 但是，语义依赖确实可以。 图2的依赖关系是否也是良好的语义依赖关系？

要回答这个问题，我们必须检查依赖类的名称，并询问它们是否“有道理”，因为在它们各自的认识论领域中可能希望这些名称之间存在联系。

因此，我们有一个依赖于ReusableStringReader的分析器 。 这很有道理； 如果您要构建用于分析某些东西的功能，则很可能希望读取字符串，并且“可重用”的字符串读取器听起来像是特定类型的字符串读取器，因此这种语义上的依赖不足为奇。 同样， AnalyzerWrapper可能完全取决于Analyzer 。 重复练习将揭示一个合理的语义结构。

结构是一组节点及其相互连接的集合，那么哪个更重要：语法结构还是语义结构？

让我们更改图2以故意降低其语义结构。

纯粹的语法更改涉及更改节点之间的依赖关系。 纯粹的语义更改涉及更改节点的名称（添加或删除节点既是语法更改又是语义更改）。 因此，让我们通过将ReusableStringReader的名称更改为Banana来进行最小的语义修改。

图3：语义滑移。

“香蕉”是ReusableStringReader类的一个可怕名称。 当看到分析功能取决于水果（或草药，或香蕉到底是什么）时，试图理解此程序包的程序员会哭泣。 猴子依靠香蕉而不是分析功能。 这是不良的语义结构。

但是，如果我们更改Banana中的代码，是否还能预测潜在的涟漪效应？ 是的，我们可以，因为涟漪效应遍及语法而不是语义依赖性。 即使我们删除所有语义信息（请参见图4），我们也可以跟踪可能受影响的类。

图4：无语义图。

或者，我们可以检查语法结构不正确的程序包，并改进其语义以评估总体收益。 图5显示了这种不良的包装。

图5：来自Lucene的可怕软件包。

除非我们不尝试语义上的改进。

因为即使Wittgenstein和Chomsky自己将图5配对编程为软件工程史上最知名的软件包，所以估算变更成本仍然是一场噩梦。

摘要

好的软件结构的主要目的是帮助评估影响成本，并间接地降低实际影响成本。 语义学是一个至关重要的理解辅助工具，但是比起出色的句法结构所支持的语义水果篮，在不良的句法结构上披上语义稳健性的更新成本更高。

句法bit子打的语义。

硬。

翻译自: https://www.javacodegeeks.com/2015/09/battle-of-the-structures.html

百战程序员数据结构 课件