主流想法
定义一个基类，然后当遇到第一种情况（问题）的时候，派生出第一个子类，解决这个问题。当遇到第二种情况的时候，在派生出第一个子类解决；遇到第三种，那就再派生出第三个子类搞定；第n种情况，那就派生第n个子类。
这样就可以很灵活，每一种子类解决一种问题，还可以随意进行扩展。
只是这么做有一个很大的难点，那就是基类何如来定义？另外在数学上有一个证明方法，不仅要证明当n=1的时候是成立的，最重要的是能够证明n=n+1的时候也是成立的。那么如何确保当遇到第n+1种情况的时候，也可以照样派生出n+1个子类应对呢，而不用修改基类。
这就需要很扎实的面向对象的基本功，还要能够应用好设计模式，什么时候该用哪种模式，什么时候不需要。不仅要很了解客户的业务逻辑，还要了解行业的特点，客户的员工、老板的想法、特点和操作习惯。总之，已知条件掌握的越多，这个基类也就越稳定，否则的话，很可能经不起折腾（就是客户的需求的不断的变化）。
注意：我不是说这种方法不好，而是说这种方法很有难度。不知道大家是不是可以很轻松的掌握？至少我现在的水平，我是不敢尝试的。把项目搞砸了怎么办？我这个年纪是输不起的了。所以我要稳妥一些，用自己熟悉的方式解决客户的需求。然后尝试在一些可以控制的地方应用面向对像，设计基类。
比如自定义控件，以前写自定义控件，没有用基类（当时还不会），写出来的代码虽然可以实现我的想法，但是冗余代码很多，也很乱很难维护和扩展。但是现在对自定义控件，基于.net 2.0在需要的地方使用了基类、设计模式、字典（Dictionary）等方法后，代码变的整洁多了，也可以很容易的维护和扩展。这是我在面向对象的一个进步吧。
另一个尝试就是在UI里面设置基类。把常用的、共用的放进去，其他的页面继承之后，就可以减少很多的冗余代码，看起来也很简洁。
我的想法
好像跑题了，我还没说我的想法呢。我的想法就是依托于强大的关系型数据库。因为我现在主要是做信息管理相关的项目，所以很自然的就想到了数据库，“关系”的强大。
比如我要做“通用权限”。各种项目，各种客户，需求五花八门，如何通用？简直是不可能的。那么我们换一种角度来看。不管是什么项目，是不是都需要一个“功能节点”，无论是树的形式，还是菜单的形式，本质都是一样的。而对于信息管理的项目来说，这个功能节点大多数都可以细化为单表的增删改查的级别。另外一部分就是报表、图表、统计等这一个级别的了。总之我的思路就是尽量的切成小片，以备以后的随意组合。
然后我把这些切成小片的功能节点放到了Manage_Function表里面，这样呢我可以根据这个表来生成树状的功能节点（应该也可以生成菜单形式的），这个是一开始的目的。到了后来考虑到权限的问题，最简单的需求就是，张三只能使用节点1、节点2、节点3，其他的节点都不能用，那么我就可以把这三个节点的ID记录下来，分配给张三（也可以在中间加进来一个角色）。这个就是我的最初的思路。大家也应该会想到吧。
因为我的功能节点是根据Manage_Function里的数据显示出来的，那么如果加上权限的话，那么只需要修改一下提取数据的SQL语句即可。
这样就分成了两步，第一步：把需求整理成功能节点，添加到Manage_Function 表里面。第二步：这就是一个固定的写法了，围绕Manage_Function来写代码了。
这样只要Manage_Function可以保持稳定，那就可以了。我的很多很多的东东都是围绕这个表来实现的。
借用一下“放之四海而皆准”，我不追求在“四海”的范围内都好用，我只追求在“一海”的范围绝对好用（0.25海也行）。这里的绝对好用指的是：易用、快速、简单、简洁、稳定、可扩展。
自我检讨
最后做一下自我检讨，我一直对命名规范不在乎，命名很随意，虽然最近改了一些，但是也不够明显。而在写那个Demo的时候比较匆忙，心情也不太好（没办法我是靠激情写代码的）。甚至有些代码是直接copy以前的程序，也没有做什么修改，这个就太不负责了。而当有人提出来的时候，我又很生气，这是不对的，应该感谢才对。既然挑出来了毛病，那我就要认证改正，所以这几天正在改我的那个Demo。认真检查，修改命名，代码重构。既然是Demo，那么任何细节都不应该放过，不能误人子弟呀。万一谁要是把我的某个错误的写法当成了正确的，那我就是罪人了。
所以请大家放心，我不是不继续我的系列了，而是暂时停下脚步，认真检查。请打大家耐心一下，我不会让大家失望的。
==================
我不喜欢辩论，更不喜欢争论，更更不喜欢吵架。我喜欢安静的聆听，温和的讨论，善意的提问，热情的帮助！
我做好我自己就可以了，把我的这几年的经验分享出来，完成我的一个心愿！
让园子里的口水贴少一些吧。