一个很实际的问题。
我所在的公司是一个集团公司。每一个分公司都有自己的特点。所以我们写的每一个程序基本上都是先写好一个，然后再复制N份在此基础上修改，以满足不同的要求。比如：请假，加班等。这样带来的弊端是：维护很困难。有时候又感觉很灵活。不知道大家是怎么看待这个问题的，有什么好的解决办法,和设计模式可以解决？

------解决方案--------------------
可以从库结构上入手

库内添加一 组织 表 树形结构：

id
parentId
name

每个子公司处于一个组织内 互不干扰
每个组织有自己的规则 比如：请假，加班
------解决方案--------------------
抽象，就是把象的抽出来。。。
然后，拥抱变化~~

哈哈哈
------解决方案--------------------
集团里的所有员工的基本资料都是放在一个数据库的。我的问题的侧重点是如何在一个程序里面处理所有公司的业务差异。比如请假程序，我能不能把N个程序，放到一个程序中来处理。一个公司的规则发生了变化而不影响到其他公司？

------解决方案--------------------

探讨

------解决方案--------------------
你这个貌似是流程都发生变化了。。。。没法抽象吧
------解决方案--------------------
这种我做的比较多,也纠结的狠...开始开法总是想写一个大的类,然后再扩展继承,但有时流程不同,用户习惯不同,要求也完全不一样,总只能重写了.这个只能是你对项目的理解和项目的生存发展上你的把握了.
------解决方案--------------------
前台程序只能是一个，数据库结构也只有一种，
为不同的需求在数据库中建立不同的需求种类，
对不同的需求种类适用不同的规则


------解决方案--------------------
这就好比用户权限一样，不需要为每一个用户或每一组用户在前台程序中写一个权限类，而是在数据库中设置
权限的种类，用户的类别（实际上就是组），组对应的权限，用户属于哪一个组，当新建一用户，并使其加入
到某一组，或新建一组并为其设置权限，这就有各种各样的用户，各种各样的组，以及各各种各样的权限分配，
而不需要更改程序或新建类
------解决方案--------------------
如果你纠结于一个程序要适合许多企业，那么总是纠结于“麻烦”与“灵活”之间，没有结论。首先就是要从观念上分出层次，对于一定层次的东西应该放给别人（你只是验收），你只应做好另外一个层次的核心服务的定义和实现工作。
------解决方案--------------------
抽象式厂,扩展相应的功能模块