设计中“接口膨胀”有关问题

设计中“接口膨胀”问题
不知道大家在设计中是否有碰到下面这种情况：
我有4个功能和概念上独立的模块，分别是：M1,M2，M31,M32
它们的关系是：M1-->M2（M1聚合M2），M2-->M31,M32（M2聚合M31,M32）
  即：M1-->M2-->M3,M4
  一个用户可能实例化一个M1，M2实例M2，M2实例M3,M4
  多个用户的话会有多条这样的实例过程
我现在的问题是：M3中需要输入一个参数A，那我现在会想到的是M3的参数需要由
  M2来输入，那这样M2便需要一个输入参数A，M2的输入又需要由
  M1来提供。如果同样我在M4中也需要一个参数B的话，那最终也
  会到M1这里来提供接口输入。随着我的模块或聚合层数的增加
  那M1这里会需要提供指数级的接口。不知道有没有更好的方法来
  解决这样的 问题呢？？？

------解决方案--------------------
可以把底层的接口暴露出来，比如在M1中添加这样一个方法：

class M1
{
public:
M2* GetM2();
};

好处是底层模块接口变动时不必一连串的修改上层模块接口（纯体力活），也不必把底层接口挨个的封装一遍（也是纯体力活）
缺点是调用起来挺麻烦的，类似下面的样子：
M2* m2 = m1->GetM2();
M3* m3 = m2->GetM3();
m3->SetParam(param);
------解决方案--------------------
这么设计不对，这不应该是接口膨胀问题。
接口应该是是一个软件元素外部可见的，同时也描述了这个软件元素的责任。
很难想象M1需要暴露出M4个一个设置参数的接口。

你提到了聚合，在M1在使用对象代理(object delegate) 来复用功能的模式下，
M1提供的接口不会受到内部对象的影响，仅仅由M1本身的职责决定。