设计模式

最近在读设计模式之禅

单一职责原则 SPF原则

Single Responsibility Principle

There should never be more than one reason for a class to change

在类设计的时候尽量分清职责,做到业务对象和业务逻辑分离

单一职责原则最难划分的就是职责,一个职责一个接口,但职责并没有量化的标准,一个类到底要负责哪些职责?职责如何细化?细化后是否都要有一个接口或类?这些都因项目而异

在类的方法上,也要遵循SPF
一次专注于一件事情已经不是个容易的事情了,不要把问题搞得太复杂

里氏替换原则 LSP原则

Liskov Substitution Principle

Functions that user pointer or reference to base class must be able to use object of derived class without knowing it
只要父类出现的地方,子类都可以出现,而且替换为子类也不会产生任何错误或者异常

• 子类必须完全实现父类的方法
• 子类覆盖或者实现父类方法时输入参数可以被放大
  ..

依赖倒置原则 DIP原则

Dependence Inversion Principle

…

未完,待续

======2016年12月19日更新
介绍一个最近学到概念，叫设计模式与过度设计。

过度设计大体是指软件迭代过程中需求是不断的变化的，这意味着对代码设计的越早，在后期失败的概率越大，在当时看起来合理的设计，在后期却会因此花费过多的代价。

对于了解设计模式的人来说，设计模式是一种沟通语言，它需要大量的编程经验，才可以让我们实现：重构到设计模式。对于我这样的新手而言，只需大致了解一点就可以了。离开实践经验，妄谈设计模式，没太多的益处。所以这个坑先挖着。