突然想写一些关于设计模式的文章（一）

之前看过一些视频和文章，想根据自己的理解来记录一下设计模式。
设计模式是一种思想，不局限于某一种语言，用c#可以写，用c++也可以写，当然java也可以，当你写代码的时候，觉得写的代码冗余，虽然看起来没问题，运行起来没问题，功能上也没问题，但是就觉得代码上不够严谨。
先举个例子，这块先不涉及设计模式，比如下列代码：
void Check(type type_)
{
if (type.one == type_)
{
func1(true);
}
else
{
func1(false);
}
}
参数是个枚举，判断是type是不是type.one，这个代码乍一看没毛病，但是能不能减少代码行数呢？可能有人会这么想：
void Check(type type_)
{
if (type.one == type_)
func1(true);
else
func1(false);
}
if else 可以缩略他的大括号，但是能不能更精简呢？
func1(type_ == type.one);
其实这段代码无非就是func1要传一个bool类型。这里我想说明的是，虽然上述代码没问题，但是在写代码的时候能精简的5行的能写1行的就是进步了，这个进步就是问题的思想上的转换。这个地方还没理解我的意思的请接下来看：
之前我问我们公司的大佬，设计模式这块应该怎么根据需求去设计，说白了就是策划这边给个需求，怎么根据设计模式来写代码，然后策划同事不断的增加需求，代码还有很好的扩展性，耦合性低，而且程序同事看的或者使用的时候一看就会，知道调用哪个接口，除了注释，你不可能每一句都会注释你的代码。大佬说他不会设计模式，我当时懵了，想怎么不会呢？他说写多了就会了，而且也没有特意的按照某一个设计模式去构建自己的代码，我当时还不是很理解，但是无意间看到一个设计模式的视频想到了为什么我们公司的大佬不会设计模式。但是依然写的一手好代码。答案是：他不是不会代码。而是告诉我，这个设计模式不能拘泥于他的模式。那就是重构得到设计模式-设计模式的应用不宜先入为主。
答案就是这个，就是重构。大佬写的代码可能涉及到几种模式，包括单例，观察者，工厂，融为一体了。就像李连杰张无忌的电影学太极一样。
越学忘的越多，这其实就是一种境界，慢慢的融入到自己的招式里了，就是这样。
有几种原则，只要符合这几种原则，其实慢慢就会把模式融入到自己平常写的代码中，
1、单一职责。单一职责都能理解就是单一，比如一个sum函数，就是加法的函数，你非要写个又减法，。你让这个函数怎么办。这个是函数功能单一。
2、开放封闭原则。比如你设计一个类，他的扩展是开放的，他的更改是封闭的。
3、替换原则。子类必须能够替换他们的基类。
4、依赖倒置原则。高层模块不依赖底层模块，高底层都依赖于抽象，抽象不应依赖实现细节，实现细节应该依赖于抽象。这个地方有点拗口。甚至还有点让人感到发懵。。前面高底层应该可以看懂。抽象不依赖实现细节，你的抽象类，是包括抽象方法等，是做什么的？实现方法肯定不是写在抽象类里把。所以抽象不依赖实现细节。实现是在继承这个抽象的子类里实现，细节应该依赖于抽象。