整篇连载都不提及架构，因为没有某种架构模式是特定命名的，架构设计是一门哲学，要学会用之自如，象打太极一样，实则虚也，虚则实也，非虚则非实业。要想成事，不要以成事的态度去做事，要学会疯狂，冲动，同时也是艺术创作必备心里素质，编程也是，物极必反。本整篇连载我会挑战自我的，一直以来，我都不太善于用别人的思路及想象读者的感受去澄清事实。这种类型的人我也相识了好多，举个例子，Koumi，这孩子是疯子，有疯子的潜质，下班了，明天继续写吧
。
首先，我先阐述下一些概念性的问题
关于几个关于松耦合强内聚重要原则需要谨记的
1.单一职责原则 (Single Responsibility Principle,SRP)
2.Liskov替换原则 (Liskov Substitution Principle,LSP)
3.打开、关闭原则 (Open-Closed Principle,OCP)
4.依赖倒转原则 (Dependency Invertion Principle,DIP)
5.接口隔离原则 (Interface Separate Principle,ISP)
这些原则都是重要的面向对象原则，我这里就不Ctrl CV概念了，大家自己找下度娘
下面给大家举个例子，是关于SRP的，大家一起探讨一下，如有不正确的地方，请多指教
SRP要记住的只有一点：不要真实的、直接的去设计某个功能（或某个类），抽象其子功能仅做一件（或者一方面）事情的单一元素。
如是，就说我们公司，现在大家都在一个大厅，市场部，测试部，开发部，研发部，等
情景一：当有人说，以下部门到会议室开会，那么所有部门的员工都要分心，把手头的工作停一下，认真听到底是哪个部门。
这就违反了SRP的原则，SRP可以这样做：
情景二：每一个部门在一个屋，通知员到每个屋都喊一下，大家到会议室开会即可。
那么我们来分析下实质问题。
情景一通知员只需要喊一次，但是所有人都会收到影响，这是我们得到一个问题，如果这个屋有越多个团队及部门，那么每个人浪费一分钟去听通知员，那么加起来就越很浪费大家的时间，何况通知员在念部门的时候还要浪费时间，不止是一分钟的问题啦
这时我们会得到一个结论：人越多，耽误的时间越多。那么既是：当一个类方法越多，修改起来越费事。我们要逐个的去找我们要通知的方法，当进行替换的时候，整个类都要重新编译，浪费大量时间
同时，我们再来分析SRP的弊端
情景二通知员逐个的跑每个部门进行通知，首先他必须要动脑知道我通知的部门是什么，需要计划下路线，而情景一照通知稿念就ok了，这一点要更费时。当部门不多的时候，或者有部门不在或者就一两人的情况下，那么通知员去通知，一定浪费事件。
这时，我们又得到一个结论：人越少，或部门少，耽误的时间也多。那么既是：当一个类方法少，或相对后期变动不大，那么呕心沥血的去迎合SRP只会另你更痛苦。我们不要因为折磨自己而养成自虐倾向，这也是流氓程序员的必备素质之一：某些情况不要为了迎合定义原则，被原则虐待，这会直接或间接阻碍你的执行力，甚至智商，相信我，那样你只会学会如何变得更脑残而已！
上面分析也差不多了，该上代码的时候了
// 单一职责，SRP，通知接口
public interface TongZhiYuan
{
void Fun_TongZhi( string Context, string HuiYiShiBH);
}
// 公司基础类，提供一些公司结构
public class GongSi
{
internal static string HuiYiShi;
}
// 开发部门
public class KaiFaBu : GongSi, TongZhiYuan
{
public void Fun_TongZhi( string Context, string HuiYiShiBH)
{
// 实现通知去哪个会议室
throw new NotImplementedException();
}
}
// 业务部门
public class YeWuBu : GongSi, TongZhiYuan
{
public void Fun_TongZhi( string Context, string HuiYiShiBH)
{
// 已经收到去哪个会议室了
HuiYiShi = HuiYiShiBH;
// 继承公司
// 大家得知了，会思考父类，公司的这个会议室在哪，怎么去，等等
}
}
欢迎大家批评，指正，我会虚心接受。嗯，我知道我在推翻传统甚至主流思想，但我会坚持我自己的路让别人说去吧。有些道理我写完就会遭到骂声一片，但我仍然会义无反顾的去做，我相信不久的将来，大批流氓程序员也会编程主流，也有自己的原则。
讨论群：Asp.net（一群）29123371，微学堂 9940051
