向对象设计原则是OOPS（Object-Oriented Programming System,面向对象的轨范设计系统）编程的焦点，但大大都Java轨范员追逐像Singleton、Decorator、Observer这样的设计模式，而不正视面向对象的剖析和设计。甚至还有经验丰硕的Java轨范员没有风闻过OOPS和SOLID设计原则，他们根柢不知道设计原则的益处，也不知道若何遵照这些原则来进行编程。5 Y) `' X* Q; I0 C
8 }4 w- u) r* a1 d: ] 众所周知，Java编程最根基的原则就是要追求高内聚和低耦合的解决方案和代码模块设计。查看Apache和Sun的开放源代码能辅佐你发现其他Java设计原则在这些代码中的现实运用。Java Development Kit则遵循以下模式：BorderFactory类中的工场模式、Runtime类中的单件模式。+ a4 C1 b- q2 k8 Q2 X' y
# B+ _" [( c6 _# K* \: m 原则1:DRY（Don't repeat yourself）# M0 f4 `+ q% t0 ]5 K
5 p. ~. i7 K2 u) I2 Z. }' m/ \
即不要写一再的代码，而是用"abstraction"类来抽象公有的工具。如不美观你需要多次用到一个硬编码值，那么可以设为公共常量；如不美观你要在两个以上的处所使用一个代码块，那么可以将它设为一个自力的体例。SOLID设计原则的利益是易于维护，但要注重，不要滥用，duplicate 不是针对代码，而是针对功能。这意味着，即使用公共代码来验证OrderID和SSN,二者也不会是不异的。使用公共代码来实现两个分歧的功能，其实就是近似地把这两个功能永远绑缚到了一路，如不美观OrderID改变了其名目，SSN验证代码也会间断。是以要慎用这种组合，不要随意绑缚近似但不相关的功能。; I, ~) B" V2 a1 p
' W9 Y4 t6 g n3 O! t4 K
原则2:封装转变* Y4 Z1 b1 }9 f* b
: F" r" O) O! T
在软件规模中独一不变的就是"Change",是以封装你认为或猜测未来将发生转变的代码。OOPS设计模式的利益在于易于测试和维护封装的代码。如不美观你使用Java编码，可以默认私成仙变量捉式，并慢慢增添访谒权限，好比从private到protected和not public.有几种Java设计模式也使用封装，好比Factory设计模式是封装"对象建树",其矫捷性使得之后引进新代码不会对现有的代码造成影响。- f% A- k' [ l# r
1 f- h9 ] l5 m& ? 原则3:开闭原则# N0 s7 U4 G6 C3 N
; P0 K3 h- d4 m z9 `, e! ?- W
即对扩睁开放，对改削封锁。这是另一种很是棒的设计原则，可以防止其他人更改已经测试好的代码。理论上，可以在不改削原有的模块的基本上，扩展功能。这也是开闭原则的宗旨。
* \; H( [- d5 i2 w. F d* i4 E+ u& Q% u) @& v
原则4:单一职责原则
$ e- S3 N6 `, [4 L7 E7 D3 O" h/ B) } 9 }, J9 {8 e, Z% v; W# U
类被改削的几率很大，是以应该专注于单一的功能。如不美观你把多个功能放在统一个类中，功能之间就形成了联系关系，改变其一一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能呈现的问题。, W6 X1 \6 l. R4 z: p
; n |8 j3 Z9 s6 h' Z# \ 原则5:依靠注入或倒置原则
/ q0 V R. z" v; V& y3 V3 M
7 @4 q" a5 S6 s. C: r6 [% F 这个设计原则的亮点在于任何被DI框架注入的类很轻易用mock对象进行测试和维护，因为对象建树代码集中在框架中，客户端代码也不杂乱。有良多体例可以实现依靠倒置，好比像AspectJ等的AOP（Aspect Oriented programming）框架使用的字节码手艺，或Spring框架使用的代办代庖等。! Q: H9 D* X, v: y
. O5 n6 r4 H) V" ~4 ]
原则6:优先操作组合而非担任' l7 r3 |% K2 D) O+ _% c% ]; B
' Q$ y' D) [. _' w. W 如不美观可能的话，优先操作组合而不是担任。一些人可能会质疑，但我发现，组合比担任矫捷得多。组合许可在运行时代经由过程设置类的属性来改变类的行为，也可以经由过程使用接口来组合一个类，它供给了更高的矫捷性，并可以随时实现。《Effective Java》也举荐此原则。0 m9 i, x4 D9 n* f
* u! j7 q6 k6 J# b5 p# V* M 原则7:里氏代换原则（LSP）
9 h0 l( c, U- I( p% l( C+ d0 Y- x 6 V6 k8 A0 X1 T0 m) P3 R9 x
按照该原则，子类必需能够替代失踪它们的基类，也就是说使用基类的体例或函数能够顺遂地引用子类对象。LSP原则与单一职责原则和接口分手原则慎密亲密相关，如不美观一个类比子类具备更多功能，很有可能某些功能会失踪效，这就违反了LSP原则。为了遵循该设计原则，派生类或子类必需增强功能。
6 u! I0 V" C: r( y
/ }# L u h0 A% m/ N, `6 M0 B- S6 n 原则8:接口分手原则' a4 b- x- p5 C3 C% e
( s% z- U. d4 z* b0 e 采用多个与特定客户类有关的接口比采用一个通用的涵盖多个营业体例的接口要好。设计接口很棘手，因为一旦释放接口，你就无法在不间断执行的情形下改变它。在Java中，该原则的另一个优势在于，在任何类使用接口之前，接口晦气于实现所有的体例，所以单一的功能意味着更少的实现体例。
- p7 t7 [9 u6 f D% _% A & B& r8 u4 X K) L
原则9:针对接口编程，而不是针对实现编程
+ {7 F5 i+ r: T: I5 B ' g0 Y3 k9 P+ M7 w. ~. D* j+ ?9 j
该原则可以使代码加倍矫捷，以便可以在任何接口实现中使用。是以，在Java中最好使用变量接口类型、体例返回类型、体例参数类星匀。《Effective Java》 和《head first design pattern》书中也有提到。
4 A" }% A; H5 S( j, X3 Y
$ n) b9 y1 B, D C7 Q& {2 h/ o4 v 原则10:委宛原则% w4 h( w% D7 }; C& k( r* N+ }
9 h2 v6 ?* k. r- t1 v 该原则最典型的例子是Java中的equals（） 和 hashCode（） 体例。为了平等地斗劲两个对象，我们用类自己而不是客户端类来做斗劲。这个设计原则的益处是没有一再的代码，而且很轻易对其进行改削。 |
发表于 2012-8-4 12:44:44
