长城这么矮究竟能拦住啥？

Posted 2023-04-19

2021年9月13日，北京，雨后的司马台长城云海翻腾，美不胜收。

长城城墙确实不高，但是别忘了长城所在的大山足够高啊，原本这些山脉就已经具备一定的高度，巍峨耸立，足够拦截军队和战马的入侵，再加之以几米高的城墙阻隔，让原本敌军的进攻行动变得越发艰难了些。

而长城的建立所要防御的目标，主要还是来自于长城另一边的北方游牧民族部落，越过长城便是游牧民族的草原帝国，那里水草丰茂，风吹草低见牛羊，是牛羊骏马的理想栖居之地，匈奴草黄马正肥，优质且数量众多的马匹，也成就了游牧民族所向披靡的骑兵部队。无论是匈奴，突厥，鲜卑，还是契丹，蒙古，女真皆是马背上长大的民族，全民皆骑兵，这无疑也为后来他们的骑兵作战奠定了坚实基础。

骑兵战术如何破？硬碰硬，正面刚，中原骑兵自不是其对手，但是一道绵延万里的城墙却轻易的化解这个问题，足以让骑兵部队折戟城墙脚下。从古至今，你有听说过，哪个游牧民族骑兵非要硬着头皮爬城墙而进的吗？这主要归功于长城的防御功能。如果敌军骑兵未被城墙劝退，选择绕道而行，那也让他绕，待他们的千军万马，千里奔袭，翻山越岭，找到城墙的某一个薄弱口子，进行集中进攻时。中原将士们也早已经顺着长城而上，此时的城墙上，军队早已集结完毕，重兵严防死守，就等你外族骑兵开战。

但是长城的作用可不仅仅只是防御，长城还有它的第二大作用——预警。欲知万骑还千骑，只看三烟与两烟……每当守卫士兵发现有敌军来犯时，便会立刻点燃长城的烽火台，台台紧密相连，烽火被接连点起，直至将消息传到皇帝所在都城，好让大家尽快做好战前应敌准备，有应敌之策。

参考技术A

历史上长城对保护百姓抵御游牧民族的侵扰起到过重要的作用。

汉民族在和游牧民族的长期战斗中总吃大亏。因为界线漫长，很多平原地带，你根本不知飘忽的他们要从哪边过来抢掠。

就算你知道了你也很难挡住高头大马的剽悍冲击。

长城虽然不高，但它拦住了所有可能的通道。把敌人的骑兵冲击变成艰难的攻城战斗。增强了防守能力，有效阻挡住敌人，坚持到援兵的到来。

长城再矮，你从下面爬的上去吗？而且长城还建在坡度较大的绵延山顶！另外，抵抗外敌也不完全是依靠长城建筑本身，最终还是要靠士兵们的战斗，长城只是增加敌人的进攻难度，如果建造更高，将会带来的更大的安全风险和更高的成本

参考技术B 长城的修建绝不是劳民伤财那么简单。长城虽然不高，却像一根细细的长绳，将胡人缓慢地、活活地勒死。从秦长城的地理状况来看，正好处于400毫米等降雨线。长城以南，是适合种植的农业区；而在长城以北，却是苦寒、荒芜的游牧之地。以农为主的农业文明喜欢的是陆军，以牧为主的牧业文明喜欢的是骑兵，长城的平均高度是在7.8米，轻松的可以阻拦骑兵过境。 参考技术C

别看它矮，在当时的科技环境不是很发达的情况下，对阻滞敌方的军队行动，效果是很明显的。

参考技术D

长城。真不矮。因为长城面对北方的一面是依据。崇山峻岭建造的。北方的抵扣。若想进入南方。想攻打长城。那是在过去的年代根本是不可想象的。面对着崇山峻岭不说。陡峭的山崖。矮的也有几米高的也有几十米。再加上长城大多都是。三四米高。累加起来。那真是一个天堑。所以说长城矮。那就是孤陋寡闻了。当年。的战争。都是拿着长矛和短剑。一般的梯子是没有办法达到长城这么高的。所以长城的建立。是一个伟大的智慧。是一个汉族联盟的最佳工事。当年抵御匈奴。是非常有效的。

长城。

究竟啥是绑定？

【中文标题】究竟啥是绑定？

【英文标题】：What exactly is a binding?究竟什么是绑定？

【发布时间】：2013-05-27 18:12:26

【问题描述】：

我最近越来越多地看到术语“绑定”和“实时绑定”，尤其是在 Ember.js、Can.js、Knockout.js 和 Backbone.js 等 JavaScript 框架中，更传统的是，在Cocoa 和 Objective-C，想知道绑定到底是什么？ （究竟什么是“实时绑定”？）。

似乎从广义上讲，我们可以“将 A 绑定到 B”，然后我们可以说，“A 绑定到 B”，也就是说 B 的变化会反映在 A 中——自动，无需用户担心必须设置观察者，但观察者会更早自动设置并在 B 更改时自动通知。

当我们这样做时，我们正在创建一个“绑定”。

从更严格的意义上讲，Cocoa 和 Objective-C 似乎是这样定义的：绑定是对象 A 的 property foo，而这个属性观察并更改为对象B的属性bar的值。它是如何发生的，我们不在乎，它应该是隐藏的（就像一个黑盒子），通常它是由观察者模式实现的。所以“绑定”这个词实际上意味着一个“属性”，而不是一个动作——并且这个属性观察并被更改为与另一个属性相同的值。

而且这种绑定不仅限于绑定到数据的 UI 元素。它可以是包含较小部分 UI 元素的外部较大 UI 元素，并且外部 UI 元素具有绑定到内部 UI 元素属性的属性。或者它可以是绑定到另一个非 UI 数据属性的一个非 UI 数据属性。

这就是绑定吗？那么实时绑定呢？

【问题讨论】：

只是我的两分钱，IMO 你完全正确地理解了绑定是什么，并且实时绑定几乎相同，但名称不同。

我想你已经回答了你自己的问题，很好。 :)

【参考方案1】：

我不确定历史，但我的猜测是这个意义上的“绑定”一词源于“数据绑定”一词。 “数据绑定”确实是一个动作：它使用来自实际数据（AKA 模型）的值填充 UI 控件，例如，当表单中的字段被数据库中的数据填充并自动更新时，使用您提到的观察者模式.我认为绑定的主要区别是单向与双向：在双向数据绑定中，用户输入也会同步回模型，而不是仅将数据从模型同步到视图。

“绑定”是动词，“数据绑定”的动词形式是“绑定数据”或“执行数据绑定”。第二个例子表明“数据绑定”也是一个名词，可以定义为“将数据/模型属性绑定到 UI/视图属性的行为”。关于“绑定”本身的名词版本，我认为您是正确的，它通常指的是两个属性之间的单独绑定。为了直观地展示这一点，假设这些点代表两个相互绑定的属性：

• ----- •

这里的“绑定”是它们之间的界线。

更具体地说，单向绑定可以用一个箭头表示：

• ----> •

还有一个带有两个箭头的双向绑定：

• •

“实时绑定”是一个术语，仅用于表示正在使用观察者模式。我的猜测是，区分“实时绑定”的愿望可能来自 Web 开发人员，他们以前曾使用过在第一次加载页面时，每个 HTTP 请求只发生一次数据绑定的框架。现在，大量 Javascript 的 Web 应用程序正在成为规范（部分归功于 ajax），没有理由不使用 MVC 原始定义所建议的观察者模式，因此“实时绑定”对于 RIA 而言可能是一个不必要的术语或原生桌面或移动应用程序。

顺便说一句，Trygve Reenskaug 对 MVC 的最初设想（他发明了它）从根本上是关于在系统中反映最终用户的心智模型，因此“模型”是用户几乎可以直接操纵的东西（或至少感觉这种方式给用户）。所以观察者模式（或者至少是保持模型和视图同步而不重新加载页面的某种机制）对于它来说是必不可少的，并且在服务器端拥有大部分代码的 Web 开发框架并不是最初设想的真正 MVC，而是而是在代码组织方面遵循相同一般思想的变体。主要用于客户端应用程序的现代 Javascript 框架使真正的 MVC 可用于 Web 开发。

回到您在问题中提出的观点，当您说绑定不一定只在模型属性和视图属性之间时，我认为您也是正确的；它可以在两个模型属性之间（通常在不同的模型上），或者在两个视图属性之间。但我不同意你关于“绑定”只是编程方面的名词的断言——显然在英语中它是动词“绑定”的名词形式，换句话说，“绑定的行为”，我认为这是一个有效的在编程中的使用也是如此。所以本质上我要说的是它有双重含义，但我认为你提出的定义是最常见的。这是我对正式定义的尝试：

绑定。

两个属性之间的连接（通常在两个不同的对象中），它使属性彼此保持同步，即具有相同的值。同步可以是单向的，也可以是双向的。 启动此类连接的行为。

【讨论】：

如果您有兴趣了解更多关于 Trygve Reenskaug 关于最终用户心智模型的想法，我当然建议您查看有关 MVC 的早期文章，但也可以查看他的新范式（其中与 MVC 互补）、DCI，进一步帮助在代码中反映用户的心智模型。 This article 是一个很好的起点。

能否请您回答您自己的问题，或者接受马特的上述回答（我认为这很好）...以便从此处的“未回答的问题”部分中删除此问题？谢谢！ :)

【参考方案2】：

Binding 很简单的意思就是链接，假设你有一个进度条和一个变量 X，每次点击一个按钮，X 的值都会递增。使用 Binding 您可以获取 X 的值（每次递增）并将其显示在进度条上。在 C# 中的以下代码行中，“pb”是进度条，TapCount 是保存总点击次数的变量。它显示“pb”的值已经绑定到变量TapCount

public void tapping
    
 pb.Value = TapCount; 

【参考方案3】：

这与原版 javascript 中 .bind 方法的原始使用没有什么不同：您将对象的范围绑定到方法。

考虑this.iterable.map( this.flush ) 和this.iterable.map( this.flush.bind(this))。首先，我们简单地在 this 上的可迭代属性的每次交互上运行一个方法 - 但是为了让 this.flush 方法访问 this 属性，您必须将其绑定到 this。

同样，在 Ember 等框架中，模型是一个声明。为了从远程源填充该模型，您需要一个实例。为了从车把修改模型，您需要一个实例。如果您的 UI 更改立即影响模型实例 - 它们已绑定。

伪编码： UI.view.bind(modelInstance) RemoteSource.bind(modelInstance)

根据我的经验，“实时绑定”是在 UI 发生变化时立即将数据绑定到远程源。

伪编码： UI.view.bind(modelInstance) RemoteSource.bind(modelInstance) modelInstance.onChange(RemoteSource.update.bind(modelInstance))

【参考方案4】：

术语“绑定”主要用于客户端开发。以您创建一个显示温度的 html 网页为例。

<div id="temp_value"> 77 °F </div>

现在您想在温度变化时更新此值，同时不断向温度提供程序 API 发出 AJAX 请求。在该响应中，您会收到一个温度值，该值应相应地更新您的 UI。

这种需要用 Javascript 变量或类似变量来更新 HTML 就产生了绑定的概念。

当你创建的东西让你的 DOM 与任何可以是 DOM 的 JS 变量的变化保持同步时 - 变量对可以说是相互绑定的。

还有一个术语叫做双向绑定，DOM 中的任何更改都会更新绑定的 JS 变量，反之亦然。