七大设计原则

一、单一职责原则(Single-Responsibility Principle):
单一职责的含义是:类的职责单一,引起类变化的原因单一。解释一下,这也是灵活的前提,如果我们把类拆分成最小的职能单位,那组合与复用就简单的多了,如果一个类做的事情太多,在组合的时候,必然会产生不必要的方法出现,这实际上是一种污染。所谓职责,我们可以理解他为功能,就是设计的这个类功能应该只有一个,而不是两个或更多。也可以理解为引用变化的原因,当你发现有两个不同的变化会要求我们修改这个类,那么你就要考虑撤分这个类了。SRP优点:消除耦合,减小因需求变化引起代码僵化。
二、开闭原则(Open-Close Principal):
开闭原则的含义是:对扩展开放,对修改关闭。就是,我们写完的代码,不能因为需求变化就修改。我们可以通过新增代码的方式来解决变化的需求。当然,这是一种理想的状态,在现实中,我们要尽量的缩小这种修改。 再解释一下这条原则的意义所在,我们采用逆向思维方式来想。如果每次需求变动都去修改原有的代码,那原有的代码就存在被修改错误的风险,当然这其中存在有意和无意的修改,都会导致原有正常运行的功能失效的风险,这样很有可能会展开可怕的蝴蝶效应,使维护工作剧增。
三、里氏替换原则(Liskov-Substituion Principle):
里氏替换原则的含义是:子类可以在任何地方替换它的父类。也就是说在程序中将基类替换为子类,程序的行为不会发生任何变化。 Liskov替换原则是关于继承机制的设计原则,违反了Liskov替换原则就必然导致违反开放封闭原则。 Liskov替换原则能够保证系统具有良好的拓展性,同时实现基于多态的抽象机制,能够减少代码冗余,避免运行期的类型判别。
四、依赖倒置原则(Dependecy-Inversion Principle):
面相对象的初期的程序,被调用者依赖于调用者。也就是调用者决定被调用者有什么方法,有什么样的实现方式,这种结构在需求变更的时候,会付出很大的代价,甚至推翻重写。 依赖倒置原则就是要求调用者和被调用者都依赖抽象,这样两者没有直接的关联和接触,在变动的时候,一方的变动不会影响另一方的变动,面向抽象编程,解耦调用和被调用者。 具体而言就是高层模块不依赖于底层模块,二者都同依赖于抽象;抽象不依赖于具体,具体依赖于抽象。 我们知道,依赖一定会存在于类与类、模块与模块之间。当两个模块之间存在紧密的耦合关系时,最好的方法就是分离接口和实现:在依赖之间定义一个抽象的接口使得高层模块调用接口,而底层模块实现接口的定义,以此来有效控制耦合关系,达到依赖于抽象的设计目标。 依赖于抽象是一个通用的原则,而某些时候依赖于细节则是在所难免的,必须权衡在抽象和具体之间的取舍,方法不是一成不变的。依赖于抽象,就是对接口编程,不要对实现编程。
五、接口隔离原则(Interface-Segregation Principle):
它的含义是尽量使用职能单一的接口,而不使用职能复杂、全面的接口。 很好理解,接口是为了让子类实现的,如果子类想达到职能单一,那么接口也必须满足职能单一。 相反,如果接口融合了多个不相关的方法,那它的子类就被迫要实现所有方法,尽管有些方法是根本用不到的。这就是接口污染。
六、迪米特法则(Law of Demeter,LoD):
又叫作最少知道原则,迪米特原则要求尽量的封装,尽量的独立,尽量的使用低级别的访问修饰符。就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。这是封装特性的典型体现。 一个类如果暴露太多私用的方法和字段,会让调用者很茫然。并且会给类造成不必要的判断代码。所以,我们使用尽量低的访问修饰符,让外界不知道我们的内部。这也是面向对象的基本思路。这是迪米特原则的一个特性,无法了解类更多的私有信息。 迪米特原则要求类之间的直接联系尽量的少,两个类的访问,通过第三个中介类来实现。
七、组合/聚合复用原则(Composite/Aggregate ReusePrinciple,CARP):
组合/聚合复用原则的含义是,如果只是达到代码复用的目的,尽量使用组合与聚合,而不是继承。因为继承的耦合性更大,组合聚合只是引用其他的类的方法,而不会受引用的类的继承而改变血统。说白了就是我只用你的方法,但我们并不是同类。

  • qq_43638135
    妲己再美究为妃: 博主没有想过自己接一些私活干吗?我现在还没毕业,但是我也确实听说外挂市场自动化游戏脚本市场挺火热的,并且报酬也很丰厚,但是具体的我也不是很清楚,求解答。 (1个月前 #47楼) 查看回复(2) 举报 回复
    22