程序设计，无限继承是不是一个好的设计模式

程序设计是否应该应用多重继承的思想去实现业务逻辑呢？

还是今天的邮件系统设计，邮件系统功能组件挺多的，包括邮件条，邮件条对象池，邮件条建立的接口，邮件物品对象池，邮件收到对象池.......好多

这样的一套程序写下来绝对

第一天看：还可以挺完美。

第二天看：这部分的程序设计怎么这么别扭呢？

第三天看：这部分逻辑应用可能有点问题

第四天看：哇，一坨shit

第五天看：重构中.....

我就是一个程序架构设计的过程了，我已经经历了第4天，按理来说所有的程序设计都应该实现的是一个高内聚，低耦合的设计原则，这是一个什么样的原则呢？

一个功能尽力不要和其他类等等做成分布的功能，从而牵一发而动全身这就是高内聚，低耦合是类关系依赖性质降低，同样也是为了避免牵一发而动全身，简单的东西可能还行如果程序大起来那简直就是一个坑呀！会对未来造成无限的冲击最终所有的应用都碎成渣渣。

很显然这并不是我们设计人员想要的结果

那么下面就思考一下无限的嵌套继承这种模式去实现到高内聚低耦合是否是可行的~

首先这个确实是实现了高内聚低耦合，但是嵌套多了起来所带来的问题是什么呢？

让我们幻想一下一个大一些的功能分成了10个类继承下来，每个类都是特别的，套起来连环10个20个30个，哇这会是一个多大的程序呢？

如果再想一想如果是这10个类的内容放在1个类里面实现，一个类200行实现功能，实现下来一个文件2000行代码，20个类，4000行，30个类6000行代码！！

看来这都不是我们想要的结果吧~

如果二选一呢？我们肯定会选择分出多个类的那个设计，首先这个容易维护一些，但是貌似也并不是非常完美的。

或许我们应该遵循一个平衡一些的想法，两者都有单独的功能分一个类但是并不是都挂到一起，也就是中道的思想，既不向多个类这样细致到每一处的拆分功能，又不像这样不管三七二十一把所有功能都堆到一个类里面让程序不可维护。

所以最终

我们应该两者都不偏向，保持正中~

这时候再看无限的嵌套继承是一个好的优秀的设计模式

而这个优秀还是决定于编程人员设计时候的思想和把握。