SOLID

SOLID

Single Responsibility Principle

SRP, the notion that an object should have only a single responsibility.

… every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

(Robert C. )Martin defines a responsibility as a reason to change, and conclude that a class or module should have one, and only one reason to change.

… it(SRP) makes the class more robust.

Open-Closed Principle

OCP, the notion that "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”.

an entity can allow its behaviour to be modified without altering its source code.

… inheritance from abstract base classes. Interface specifications can be reused through inheritance but implementation need not be. The existing interface is closed to modifications and new implementations must, at a minimum, implement that interface.

… the use of abstracted interface, where the implementations can be changed and multiple implementations could be created and polymorphically subsituted for each other.

以我的理解,如果类实现了之前定义的interface,那么当有新的需求需要对类进行变更的时候,不要改变原有的interface,而应该在原来的基础上扩展。再说的白话一些,就是可以定义另一个interface,然后让类实现多个interface,从而实现扩展。

Liskov Substitution Principle

LSP, the notion that “objects in a program should be replaceable with instance of their subtypes without altering the correctness of that program”.

…, in a computer program if S is a subtype of T, then objects of type T may be replaced with objects of type S(i.e., objects of type S may be substitutes for objects of type T), without altering any of the desirable properties of that program(correctness, task performed, etc.).

Let q(x) be a property provable about objects x of type T. Then q(x) should be true for objects y of type S where S is a subtype of T.

Contravariance of method arguments in the subtype.

Covariance of return types in the subtype.

No new exceptions should be thrown by methods of the subtype, except where those exceptions are themseleves subtypes of exceptions thrown by the methods of th esupertype.

Contravariance 和 Covariance 这两个词我一直没搞明白,大致的理解为 covariance 的意思是从小往大从低到高的转换;而contravariance是从大往小从高往低的转换。

  • covariant if it preserves the ordering, ≤, of types, which orders types from more specific to more generic.
  • contravariant if it reserves this ordering, which orders types from more generic to more specific;
  • invariant if neither of these applies.

Interface Segregation Principle

ISP, the notion that “many client specific interfaces are better than one general purpose interface.”

… once an interface has become too ‘fat’ it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them. In a nutshell, no client should be forced to depend on methods it does not use.

这个似乎比较容易理解,就是把不同的功能需求放到不同的interface中去,然后使用不同的类去实现;如果有的类需要实现多个功能,那么就从多个相应的接口继承。具体的实现似乎要关注下面的 DIP。

Dependency Inversion Principle

DIP, the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”

… a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. The principle states:

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend upon details. Details should depend upon abstractions.

我这次终于有点明白了这个所谓的“依赖倒置原则”。在传统的应用程序架构中,低层次的组件被高层次的组件调用,这样一来,高层组件就依赖于低层组件,这样增加了系统的复杂程度,并且限制了高层组件的重用。

依赖倒置原则,解耦了这种依赖关系,高层组件对于行为或者服务的需求被定义为接口 interface,低层组件实现这个接口,这样一来就反转了传统的依赖关系,使得在运行时为高层组件装载低层组件成为可能。

我现在的代码水平应该还处于“传统”阶段,虽然大概明白了“依赖倒置”的定义和优点,要用到实际代码中估计还得学习一段时间。


趁这个机会复习了一下面向对象设计的SOLID原则,后面如果有时间的话,还会再深入了解一下。

posted on 2011-06-12 00:57  zhaorui  阅读(383)  评论(0编辑  收藏  举报

导航