Javascript 数据流的方向

数据流的方向究竟意味着什么？ 考虑构图模式： 我有一个类a，在该类a中，在类a实例化时创建另一个类B的实例。 A类持有A类和B类均可访问的公共数据。 类B的实例使用来自类A的数据进行实例化。 类B的实例调用类a中的方法来处理类a实例的数据

数据流中的数据被认为是什么？类或层次结构所持有的数据以及类的权限？ 例如 子类不能在父类的实例上调用父类方法

数据流的方向究竟意味着什么

让我们考虑一种特定类型的软件，这样我们就可以将数据流的数量限制在更大的思想上。

---

在电信传输中有两大数据流划分

A.运输硬件承载东/西数据。。。从一个数据传输设备到另一个数据传输设备。通常，这种数据流太快，软件无法直接处理，并且数据同时向两个方向流动

B.电信传输数据控制称为北/南数据。此流包含5个软件数据流。该流是到/来自本地硬件的，以及从/到操作用户或主机的

---

B（电信传输数据控制）中通常有5个流：

状态更新——软件定期读取硬件状态信息（通常每秒一次），并将捕获的信息传送到本地“快速”存储器（其他命令可以在该存储器中找到该信息以显示或传送到主机）

报警更新——非常类似于状态更新（即定期读取），但只更新报警。警报具有持续时间和超时，并且相当复杂

pm更新——非常类似于状态更新（即定期读取），但软件收集特定活动的摘要计数。。。有多少字节输出，有多少秒出错，等等。这还有循环15分钟的时间段、超时和其他复杂情况

配置控制——用户应用的命令可以更改操作配置。软件响应用户命令，更改特定的硬件配置寄存器。大多数T1/E1硬件可以在任一模式下运行，用户需要在启动时配置每个子系统

配置控制——用户应用命令来启用（或禁用）特定硬件类型的可用性，以“传输”东/西数据。（想想客户付费服务）

从体系结构的角度来看，每一种流动都可能是需求拉动或供给推动，但可能不是两者兼而有之

---

需求拉动示例：状态更新（流向为北，从硬件到本地存储）

在我工作过的大多数系统上，状态更新是在系统时钟之外触发的，在典型的请求拉动中，时钟事件触发从硬件读取所有状态条件。这些收集到的信息通常隐藏在本地“fast”存储器中，其他命令可以在其中找到这些信息，以便显示或传送到主机

---

供应推送示例：配置（流向为南，从用户到硬件）

任何配置（或配置）命令都与系统时钟异步（因为人类不喜欢也不擅长同步）。因此，当用户按下enter键时，会触发一个动作，供应推送的数据（命令参数）流到硬件

对于供应推送，有时需要进行协调，即在进行其他特定操作时，不允许更改配置（或prov），但这通常通过简单的互斥来处理

---

总结-在上述架构级别上，流可能看起来比实际简单

例如，有时，为了在需求拉动期间进行读取，软件必须“挠痒”硬件的某些功能，而这种“挠痒”感觉就像是“错误的方向”。。。但在这种情况下，“挠痒”不是数据流的一部分，只是通过提取/拉出数据来完成数据流的开销

类似地，为了写入配置数据，软件有时必须确定硬件是否允许更改到下一个配置，并且可能通过读取硬件来检查。这些读取看起来是错误的方向，但同样，它不是数据流的一部分，只是一些流开销

这种二元性发生在许多层面

---

---

我不能对桌面软件说太多，但我在许多地方看到了需求拉动和供应推动。在我看来，可能纪律性稍差一些，但这更可能是因为我缺乏使用大型桌面应用程序的经验。

您可能需要给出一个更具体的例子来说明您所谈论的内容。A类具有B类的实例化，并不意味着B类可以访问类A中的所有公共数据。B类的实例没有引用A类实例的方法，除非您引用它。并且您可能需要考虑限制标记。这是一个相当广泛的范围，或者说你试图将这个概念联系起来的语言，toLets说，我们强制公理，现在什么是数据流方向的数据？这不是一个理论站点。这是一个具体的问题网站。如果你能提供一个具体问题的例子，那么它就不再是一个“太广”的问题，而是更多的话题。我对抽象概念感兴趣，而不是对C++的必要公理感兴趣。