做项目遇到的有关问题
做项目遇到的问题
我现在做的是一个产品。
问题是这样，许多公司都用这个产品，共通部分占绝大数，但是每个公司又有自己的一些机能要求。
我的想法如下
1 每个公司做一个接口，如果产品卖的好，接口就越多，相应的类也会增加，但是对于后期的维护和改修的话，比较容易。
2 一个接口，每个公司是一个实现类。
以上，仅供参考。
大家有什莫好的意见和想法，共享一下了！
------最佳解决方案--------------------
如果2可实现,2是相对OK的方式
class j_comm_impl;//通用实现
class j_company_impl:
public i_company_interface,
public j_com_impl
这样j_company_impl只需实现特定的,别的可以用comm的,当改动巨大时,可以直接重写j_company_impl,放弃从j_comm_impl的继承.
------其他解决方案--------------------
建议把功能梳理一下，通用功能放在基础类中实现。
非通用部分在子类中扩展接口，接口最好能分类，这样后期维护比较方便些。
------其他解决方案--------------------
像楼上说的，采用公共接口的方式，留出可以扩展的部分来。设计一个统一的接口，然后其它的具体实现，都从这个接口类来继承就可以了。
------其他解决方案--------------------
我觉得你的这个想法和headerfirst 设计模式中第一章的讲述很类似
所以我觉得你应该用策略模式
过多的继承 可能会导致类之间的关系太紧密，要改善这种关系
------其他解决方案--------------------
2 一个接口，每个公司是一个实现类 OK
——————————————————————> 策略模式应用
------其他解决方案--------------------
继承 --- 会给你带来无尽的麻烦
多用组合，少用继承
------其他解决方案--------------------
公用的部分集成到框架里吧，然后对外开放一些接口，不同的用户有自己不同的实现，那么他自己去实现这些接口，然后用反射当做插件加载到框架当中，这样每个用户不同的部分都是插件，
------其他解决方案--------------------
简单一点说就是把可变的和不变的分别封装
------其他解决方案--------------------
我是这样想
LZ你的是中央管理平台
其它子公司，每一个是一个子系统 子系统自己可以扩展
我怎么觉得 象工厂模式
------其他解决方案--------------------
1、可以把功能细分，比如A功能定义一套接口，B功能定义一套接口。
2、针对每个细分功能，利用子类实现各个公司具体需求即可。
如果还有特殊扩展，可以考虑修饰者模式。如果在对象生命周期内，这些性能都不会改变，那么就没必要使用Strategy/state，直接用子类继承就行了。
------其他解决方案--------------------
看来设计模式有大用处了。
楼主应该高兴啊。。
我等还苦于没有练手的项目。。
------其他解决方案--------------------
对不同的功能实现不同的接口。
各个机器都从一个抽象机器继承。
不同的实现中考虑用装饰模式和模版模式。
------其他解决方案--------------------
通常都采用这种，一个接口，每个公司是一个实现类。
------其他解决方案--------------------
提供扩展接口
------其他解决方案--------------------
第一种方案吧。第二种对于产品的后期维护带来了麻烦，每个公司都实现一下，以后就不容易进行修改，更谈不上扩展了。
------其他解决方案--------------------
学习了
------其他解决方案--------------------
我现在做的是一个产品。
问题是这样，许多公司都用这个产品，共通部分占绝大数，但是每个公司又有自己的一些机能要求。
我的想法如下
1 每个公司做一个接口，如果产品卖的好，接口就越多，相应的类也会增加，但是对于后期的维护和改修的话，比较容易。
2 一个接口，每个公司是一个实现类。
以上，仅供参考。
大家有什莫好的意见和想法，共享一下了！
------最佳解决方案--------------------
如果2可实现,2是相对OK的方式
class j_comm_impl;//通用实现
class j_company_impl:
public i_company_interface,
public j_com_impl
这样j_company_impl只需实现特定的,别的可以用comm的,当改动巨大时,可以直接重写j_company_impl,放弃从j_comm_impl的继承.
------其他解决方案--------------------
建议把功能梳理一下，通用功能放在基础类中实现。
非通用部分在子类中扩展接口，接口最好能分类，这样后期维护比较方便些。
------其他解决方案--------------------
像楼上说的，采用公共接口的方式，留出可以扩展的部分来。设计一个统一的接口，然后其它的具体实现，都从这个接口类来继承就可以了。
------其他解决方案--------------------
我觉得你的这个想法和headerfirst 设计模式中第一章的讲述很类似
所以我觉得你应该用策略模式
过多的继承 可能会导致类之间的关系太紧密，要改善这种关系
------其他解决方案--------------------
2 一个接口，每个公司是一个实现类 OK
——————————————————————> 策略模式应用
------其他解决方案--------------------
继承 --- 会给你带来无尽的麻烦
多用组合，少用继承
------其他解决方案--------------------
公用的部分集成到框架里吧，然后对外开放一些接口，不同的用户有自己不同的实现，那么他自己去实现这些接口，然后用反射当做插件加载到框架当中，这样每个用户不同的部分都是插件，
------其他解决方案--------------------
简单一点说就是把可变的和不变的分别封装
------其他解决方案--------------------
我是这样想
LZ你的是中央管理平台
其它子公司，每一个是一个子系统 子系统自己可以扩展
我怎么觉得 象工厂模式
------其他解决方案--------------------
1、可以把功能细分，比如A功能定义一套接口，B功能定义一套接口。
2、针对每个细分功能，利用子类实现各个公司具体需求即可。
如果还有特殊扩展，可以考虑修饰者模式。如果在对象生命周期内，这些性能都不会改变，那么就没必要使用Strategy/state，直接用子类继承就行了。
------其他解决方案--------------------
看来设计模式有大用处了。
楼主应该高兴啊。。
我等还苦于没有练手的项目。。
------其他解决方案--------------------
对不同的功能实现不同的接口。
各个机器都从一个抽象机器继承。
不同的实现中考虑用装饰模式和模版模式。
------其他解决方案--------------------
通常都采用这种，一个接口，每个公司是一个实现类。
------其他解决方案--------------------
提供扩展接口
------其他解决方案--------------------
第一种方案吧。第二种对于产品的后期维护带来了麻烦，每个公司都实现一下，以后就不容易进行修改，更谈不上扩展了。
------其他解决方案--------------------
学习了
------其他解决方案--------------------