Oop &引用；“叉树”；封装对象之间的容器间通信

封装有助于对象的分层“筒仓”或“树”，给定应用程序的主要功能分解为核心主干，每个进一步分解为子功能，并实例化为各自分支的子分支成员对象

例如，假设我正在用QT编程一个GUI。为了将GUI元素与业务逻辑分开，对于每个小部件，我都有一个用于GUI元素的类，一个用于与GUI元素相关联的业务逻辑的类，以及一个控制器，它作为两者的容器，主要用于在两者之间传递信号/插槽。我理解这种模式被称为依赖注入

假设我们的应用程序有两个windows A和B

窗口A包含两个独立的小部件，它们具有独立的业务功能i和ii，因此我们可能有结构

A:：i

和

A:：ii

，其中：：is“包含的是”而不是“扩展的实例”

然后i和ii都包含gui和业务逻辑单元，因此我们有

A:：i:：business

和

A:：i:：gui

现在，假设

A:：i:：business

和

A:：ii:：business

想要在彼此之间传递信息，或者与我的数据库的模型视图（标识为MV）进行双向通信。一般来说，我有哪些选择

到目前为止，我想到的是：

1） 在树上上下传递信号，即Verilog解决方案。这似乎是最严格的面向对象方法，但最乏味

2） 具有更平坦的体系结构以简化解决方案1）的实施。这会影响封装

3） 将

A:：i:：business

和

A:：ii:：business

一直公开，并让另一个对象或第三方共享类访问

A:：i:：business

或直接访问

A:：ii:business

。这会影响封装

4） 有一个相对未封装的对象，如数据库MV或其他形式的“共享存储”，以公共形式存在于程序顶层附近，几乎没有超级容器。这似乎最吸引人，因为相对封装的对象可以保持封装状态，并通过单向读/写与未封装的对象通信。但是，如果我希望其他对象根据共享存储的更改执行操作，则有必要以某种方式通知依赖对象，同时保持它们的私有性。这可能被称为“多线程驱动”或“多处理驱动”的通信模型

以及你们所有人可能有的任何其他建议

我在这里读过这篇文章，但就我的理解水平而言，公认答案中的解决方案，如控制器、监听器和发布订阅，指的是一般设计模式，这些模式似乎没有致力于解决如何路由信号以及如何决定成员类的公共/私有可访问性这一具体问题。在这种情况下，这些解决方案可能与通信对象的去向以及如何访问两个思洛存储器中的不同变量相关，我对此并不熟悉

一般来说，在封装良好的编程中，我似乎遇到了跨容器树通信的一般问题

为了将来的参考，这个问题是否有一个通用术语来帮助将来的搜索？我的体系结构方法是让对象容器结构直接反映应用程序功能的树分解，这是否会导致过于分层的设计，以及不同的对象包含和跨分支通信模式是否会更为优化