封装有助于对象的分层“孤岛”或“树”，将给定应用程序的主要功能分解为核心主干，每个主干又分解为子功能，这些子功能可实例化为各自分支的子分支成员对象。
>作为示例，假设我正在QT中编写GUI。为了将GUI元素与业务逻辑分开，对于每个小部件，我都有一个GUI元素类，一个与GUI元素相关联的业务逻辑类以及我称之为控制器的控制器，该控制器既作为这两个元素的容器，又主要存在在两者之间传递信号/插槽。我知道这种模式称为依赖注入。
假设我们的应用程序有两个窗口A和B。
窗口A包含2个具有独立的业务功能i和ii的独立窗口小部件，因此我们可能具有结构A::i和A::ii，其中::是“包含”的实例，而不是“扩展” “。
然后，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或某种其他形式的“共享存储”），以公共形式存在于程序的顶层附近，几乎没有/没有超级容器。这似乎最吸引人，因为相对封装的对象可以保持封装状态，并通过单向读取/写入未封装的内容进行通信。但是，如果我想让其他对象根据共享存储的更改执行操作，则有必要在保持依赖状态的同时通知依赖对象。这可以称为“多线程启发”或“多处理启发”通信模型。
还有其他所有人的建议。
我在此处阅读过this的帖子，但据我所知，公认的答案中的解决方案（例如控制器，侦听器和pub-sub）是指似乎没有提交的一般设计模式解决有关如何路由信号以及就成员类的公共/私有可访问性做出决策的具体问题的解决方案。这些解决方案可能有关联的约定，这些约定涉及通信对象的去向以及它们如何访问我不熟悉的任一筒仓中的不同变量。
通常来说，在封装良好的程序中，我似乎遇到了跨容器树进行通信的一般问题。
为了将来参考，是否存在针对此问题的通用术语以辅助将来的搜索？我使用对象容器结构的体系结构方法是否直接反映了应用程序功能的树形分解，从而使其自身过于过于分层了设计，并且采用不同的对象包含和跨分支通信模式会更好吗？