如何“理想地”捕捉面向对象 API 的精髓？答案

【问题标题】：How to capture the essence of an object-oriented API "ideally"?如何“理想地”捕捉面向对象 API 的精髓？
【发布时间】：2019-12-26 07:11:41
【问题描述】：

我对如何最好组织对象的字段/属性感到困惑。具体来说，图形精灵。以下是创建对象的一些方法：

{
  width: 10,
  height: 10,
  marginTop: 2,
  marginRight: 3,
  marginBottom: 4,
  marginLeft: 5,
  alpha: 0.5,
  red: 200,
  blue: 200,
  green: 200
  // ...
}

或者介于两者之间的一百万种方式。或者例如：

{
  size: {
    width: 10,
    height: 10
  },
  margin: {
    top: 2,
    right: 3,
    bottom: 4,
    left: 5
  },
  color: {
    red: 200,
    blue: 200,
    green: 200,
    alpha: 0.5
  }
}

您可能希望拥有这些嵌套对象而不是平面结构的一个原因是用于类型检查。您将拥有可以在其他地方使用的具有特定类型的明确对象。但是扁平结构的原因是访问属性的潜在性能。但是，您失去了嵌套对象提供的一些概念关系。所以我很困惑。

我很困惑，因为在 HTML 中你基本上是这样的结构：

{
  type: 'div',
  width: 10,
  height: 10,
  style: {
    margin: {
      top: 2,
      right: 3,
      bottom: 4,
      left: 5
    },
    color: 'rgba(200, 200, 200, 0.5)'
  }
}

或者也许宽度和高度被移动到样式对象中。但我们只是在第一个示例中展示了您可以拥有一个简单的属性列表。以及为什么需要嵌套的style 对象。为什么将“边距”（用于调整大小的像素值）分成style，而将宽度/高度委托给元素？我实际上并不想知道为什么 HTML 会这样做，或者是否有其他查看方式。我只是用这个作为一个例子来证明可能有很多不同的方法可以做同样的事情。具有各种配置和组合的嵌套或平面对象。

我可以想象有一个 div 也是这样的：

{
  vector: [10, 10],
  marginVector: [2, 3, 4, 5],
  colorVector: [200, 200, 200, 0.5]
}

不用说，组织代码的方式有无数种，需要在各个方向进行权衡。

但我想知道的是，是否存在某个对象的“理想表示”的概念。最终，一种方式比另一种更好吗？特别是在通用性方面。

一个相关的例子是列表迭代是如何工作的。如果您担心列表的实现细节，例如它是使用指针还是动态语言，或者您有复杂的列表数据结构实现等，那么您必须编写每个列表迭代算法的自定义实现。

iterateThisListType
iterateThatListType
...

这会产生一个问题，即您现在没有“通用列表迭代算法”，就像您在学校学习的那样。每个列表迭代算法可以完全不同，具体取决于体系结构/等。实现细节。

这个问题可以通过使用“迭代器”的概念来解决。将迭代器传递给列表算法可以让您拥有一个非常简单的单一列表迭代算法。

for (item in iterator) {
  ...
}

根本不是类似于列表迭代的东西（只是编造的）：

let something = *another;
while (true) {
  if (something->else > 10) {
    complicated....
  } else {
    complicated...
  }
}

这并没有像迭代器那样捕捉到列表迭代的“本质”。

同样，我想知道我们如何捕捉 DOM 节点的“本质”？在某种程度上，将所有内容分组在style 下，或将color 全部归为一个对象等，这完全有意义。但同时，拥有顶级red 和blue 也是有意义的等，而不是将其嵌套在对象中。那么我们怎样才能类似于list-iteration的例子，捕捉到DOM节点的本质呢？（或任何其他相对复杂的结构）

当您开始更多地考虑图形和效果时，它只会变得更加复杂。在图形中，就像在声音制作中一样，您可以将各种“效果”应用于主要对象，即图形示例中的精灵。一些效果是“投影”、“模糊”、“反射”、“旧胶片”和many others。通常（在图形情况下）效果只是修改对象上现有的较低级别的属性。所以像模糊可能只是修改pixels 属性（其中每个像素都有某种color）。（只是编造这个）。效果（或者您可以称它们为“过滤器”），也可能看起来像常规属性。例如，灰度可以是顶级布尔值：

{
  grayscale: true
}

或者它可能是一种效果：

{
  effects: [
    { type: 'grayscale' }
  ]
}

如果你这样做，那么为什么不把“宽度”和“高度”也变成效果呢！我的意思是，它们也是对象的效果，“给它们一个大小”。

{
  effects: [
    { type: 'grayscale' },
    { type: 'width', value: 10 },
    { type: 'height', value: 10 }
  ]
}

现在我们看到，在这个简单的例子中，效果可以被认为是属性，我们可以回到平面顶级属性示例。但是其他一些效果似乎是在较低级别的“效果/属性”之上的层，有点形成了一些“基本”属性的处理图。所以我不知道！我想知道，是否有“理想”的方法来解决这个问题？有没有办法“捕捉到图形精灵的本质”？为了使使用它的每个算法都可以以一种方式编写（如迭代器）？因此，在一种情况下，我们没有顶级平面属性，另一种是嵌套的，另一种是效果等。哪一种是正确的？我们如何达到理想？

这只是为了演示。

我的问题是关于 DOM 节点的。不是特别是 DOM 节点 API 以及它是如何工作的或为什么会这样，而是关于它背后的哲学。我们如何才能通过这种方式捕捉到 DOM 节点属性的本质？

另一个简单的例子......如果你愿意的话，你似乎可以把东西嵌套得很深。

{
  type: 'animal',
  body: {
    organs: {
      skin: {
        mesh3d: {
          texture: {
            color: '#ff0000'
          }
        }
      }
    }
  }
}

而不仅仅是做：

{
  type: 'animal',
  color: '#ff0000'
}

你可能有一个非常复杂的网格，它在纹理上有颜色。但是你想把它想象成“动物有颜色”。所以我很困惑该怎么做。

【问题讨论】：

标签： algorithm api oop design-patterns data-structures

【解决方案1】：

如果我理解您的观点，我会说相关属性可能会分组到它们自己的对象类型中，因为这对于赋予数据结构很有用。与长的线性属性列表相比，在精神上处理结构化数据更容易。并且可能数据本身具有某种结构。像整数列表这样的线性结构非常简单，而现实世界中的对象比这更复杂，尽管列表实际上很常见。

该技术只会在适当的数据结构中反映这一现实。

您指的是“DOM”节点。虽然您可能应该参考“DOM 树”。

树是一种很好的非线性数据结构，既可以将数据存储在节点中，又可以用元数据注释节点，并且对于搜索、遍历和编辑都很有效。

如果你不喜欢用树的方式思考，也许你喜欢列表的列表，这本质上是一样的。

我认为，要抓住本质，您必须考虑在思考或撰写问题时使用了哪些抽象，然后将其反映在数据表示的领域中。

HTML 将文档结构与应使用 CSS 的表示样式分开。这证明了您所描述的那种分离是合理的。

为什么 DOM 结构类似于 DOM 结构，可能是因为浏览器必须解析它，在这方面，它应该与编译器中的（抽象）语法树紧密相关。

我怀疑你知道这一切，但不知何故没有引起点击，或者你在谈论更深层次的东西，而我没有听懂。

【讨论】：