由java的extend的优劣引发的讨论技巧

最近项目需要搭建一套基于springcloud的框架，在项目讨论会上。有同事说到做了一些basebean,basecontroller,baseservice,basedao等一些基础类。要求相关类都extend baseClass，就可以避免大多数重复代码,减少大部分的工作。我一听不对呀，这不是以前吃过的大亏吗？在等到同事介绍完所有的优点的时候，我简单的说了句。“在框架设计时避免使用大量extend”，由此引发的激烈的反驳。

对方的理由主要是3点：

1、java中extend是主要的特征之一，你居然说不能用。

2、extend能减少一半的工作量，你居然说这样的设计不好。

3、你连这些都不知道，怎么会如此的无知。

因为我们是跨3个区域的电话会议，在现场并没有马上反驳对方。会议结束后，我私下联系同事。主要陈述了随着项目开发的推进base臃肿、代码侵入耦合、领悟驱动设计的思想以及对后期维护的影响，还举例了struts1和strats2的设计区别。当然对方应该是没有听进去，还举例了一些填鸭式的解决方案。

主要理由是:

1,等base臃肿的时候重构，

2，base作为基础框架,类似于spring的作用。

3、base的维护是有权限的，避免每个人都有修改的权限带来的系统不稳定性。

讨论在这里我内心久久不能平静，我想这样的事情应该在大多数团队都存在，这也因该是中国软件技术的现状吧？其实在extend的优劣在网上已经有大量的讨论，我也没必要在这里重复。对于好学的人和有一定技术追求的人都能思考这样的问题。我的观点很明确，两种观点都能完成我们的项目设计和开发，从项目健壮性合理性我是支持避免extend的框架。这里我想是一个逻辑问题的思考，我的父亲是一个聪明的木工，我继承了他的聪明，但我并没有继续做木工，而是软件开发（不能强迫我去extend父亲一切）。

下面说extend问题和解决问题的方法。
问题主要是两点:
1、对顶层超类的改动可能会使与其相关的所有子类出现不正确的操作。
2、给子类的修改带来复杂度。
3、extend的单继承的局限性。
解决办法:
1、使用设计模式

类的组合或者装饰模式等 

2、编写代码生成器

由此我想就提问这个话题引发的思考，提问一般有三种情况:
1、质疑
2、反驳
3、求证
对于这三种情况大家应该都比较清楚区别。


特别是在会议上，在别人陈诉时如果没有足够的考证不要打断别人。会议理当应该避免质疑的发言，因为在质疑别人之前务必要做好充分的准备和思考，否则引发的讨论都是在浪费大家的时间。我想在工作中和生活中，聆听别人的意见总会有一种收获。