其他具体的Door类型可以extends使用abstract class方式定义的Door或者implements使用interface方式定义的Door.看起来好像使用abstract class和interface没有大的区别。
+ P4 z& v0 a, g% T. j2 w: f / p7 h7 h; l9 c6 ^% R7 G/ ], m
如果现在要求Door还要具有报警的功能。我们该如何设计针对该例子的类结构呢(在本例中,主要是为了展示abstract class和interface反映在设计理念上的区别,其他方面无关的问题都做了简化或者忽略)?下面将罗列出可能的解决方案,并从设计理念层面对这些不同的方案进行分析。
2 P2 i% P" {/ ^/ F7 X& y$ Z+ u
7 n4 L( {+ Z5 t$ a$ q 解决方案一:5 w& Y1 ?8 u- N6 ]* q( \6 }( Z' G
( ]0 u7 o4 ^" } {! a6 V0 S+ H 简单的在Door的定义中增加一个alarm方法,如下:
) w" X# s5 x" ~, g4 X5 F; v' v5 S * _0 a" z* V( H8 E2 ]
abstract class Door {5 B' \& W8 r1 A5 o. W! D2 T" t
( Q9 H: }& N9 W1 R4 J) C
abstract void open();
% }0 x5 X& d- a6 a
$ z z0 r7 T& M* u' Z+ y) i abstract void close();5 n/ q# r- Q& J k
! u3 {2 V! W S* T abstract void alarm();
2 h7 t- [' F5 R; {$ }
1 C5 l0 V9 [: q# w r* g: f }
) t. E1 i% G. i4 ]5 | 7 L7 L: ^* Q, v ~: u) X, L) M
或者% k1 M7 m# _* R; O3 i5 x
; A' q* |& @, z interface Door {0 c: }% k( b& L, \. }7 C
- V+ P7 b% J y0 g/ Q- ] void open();
3 E4 S7 B- s7 Q$ U4 L 3 s2 ^2 B% T1 m3 g" K" J) O) |! w
void close();1 |6 |8 \% X3 e: f/ V
a; m R$ |4 t, c* {7 Z0 g" f void alarm();; G) p2 i p+ W! L2 p4 V9 m2 c% b0 a
& p' S3 ]; O, u
}( n" {6 a6 C0 g( M B. U3 i
; ~0 B' @3 b6 c- R7 L { 那么具有报警功能的AlarmDoor的定义方式如下:
5 a1 i7 @1 K2 R$ x1 {
7 t# P, A% I, a$ e: X4 s) Q0 n6 _ a class AlarmDoor extends Door {( j( k( V4 n, d, h f0 R/ p
0 n/ |' R* p+ B1 e8 z- [( A
void open() { … }
/ B2 e9 U# W/ E; Q" ]0 ?) W. Q- T
2 t( q/ R* Q3 ^6 N# j( B: E void close() { … }7 W. x; m( Y" {2 Q+ x" W p
o3 R$ w* g2 r& \! [$ I7 J
void alarm() { … }
9 S: y- ^) v' K& V: a
. x d% U0 g, H9 ^1 J- |& I }1 d) f( K' k3 \" C4 v- e# ]
, }, k0 E+ j; q- d" W 或者 c& X$ E9 K1 g( w4 k" t& w
$ i) P5 q( {8 M
class AlarmDoor implements Door {& Z- A8 X. K" c2 n% k6 J" Q
; l. s; P8 Y! e! c) e void open() { … }' t8 i/ o4 C* C8 y5 h- X1 V
3 V0 j+ B D% y) X, |7 h+ |# V1 p void close() { … }
( w2 @( f3 j" F2 ?4 Z, |1 K
+ d" H" N" u8 c7 u5 T/ ^8 x void alarm() { … }
s: O9 r$ z- `6 { " q# x: R: N" l: N, `9 @
}+ D4 Q D; Q7 D: T, [" m
- w- ^$ g; o4 n
这种方法违反了面向对象设计中的一个核心原则ISP(Interface Segregation Priciple),在Door的定义中把Door概念本身固有的行为方法和另外一个概念"报警器"的行为方法混在了一起。这样引起的一个问题是那些仅仅依赖于Door这个概念的模块会因为"报警器"这个概念的改变(比如:修改alarm方法的参数)而改变,反之依然。& r8 }8 i. U: e F
& A/ y% e9 X* e6 J8 i4 n 解决方案二:! Q* w; ~' {/ B% g
9 X* v F, d4 Y4 v/ R, Z
既然open、close和alarm属于两个不同的概念,根据ISP原则应该把它们分别定义在代表这两个概念的抽象类中。定义方式有:这两个概念都使用abstract class方式定义;两个概念都使用interface方式定义;一个概念使用abstract class方式定义,另一个概念使用interface方式定义。7 K/ ?# @$ ?: S) C( A8 e% D
0 H2 \) c& q7 D2 j7 I+ i
显然,由于Java语言不支持多重继承,所以两个概念都使用abstract class方式定义是不可行的。后面两种方式都是可行的,但是对于它们的选择却反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理。我们一一来分析、说明。# J/ _9 S7 d3 f' B2 z" x7 M
% l: k& j0 h1 P7 x7 \
如果两个概念都使用interface方式来定义,那么就反映出两个问题:1、我们可能没有理解清楚问题领域,AlarmDoor在概念本质上到底是Door还是报警器?2、如果我们对于问题领域的理解没有问题,比如:我们通过对于问题领域的分析发现AlarmDoor在概念本质上和Door 是一致的,那么我们在实现时就没有能够正确的揭示我们的设计意图,因为在这两个概念的定义上(均使用interface方式定义)反映不出上述含义。2 a0 E# @) X/ o, z0 P4 z2 P
8 Q& h- f* `! J3 c
如果我们对于问题领域的理解是:AlarmDoor在概念本质上是Door,同时它有具有报警的功能。我们该如何来设计、实现来明确的反映出我们的意思呢?前面已经说过,abstract class在Java语言中表示一种继承关系,而继承关系在本质上是"is a"关系。所以对于Door这个概念,我们应该使用abstarct class方式来定义。另外,AlarmDoor又具有报警功能,说明它又能够完成报警概念中定义的行为,所以报警概念可以通过interface方式定义。如下所示:6 l3 d: D1 A' c; Z
/ M7 C. m* B: p: }# {+ |! a
abstract class Door {* h$ t6 X1 U- X- p
3 h% R9 a4 [: d' n+ J abstract void open();8 w0 I% d6 Y2 T4 M! d9 d" F
8 t: L2 K- R- Y, a) q$ P
abstract void close();2 F2 w3 N n( T h+ Y
+ u9 W0 S! j8 h- A5 Y. \
}
: ?; I I7 @5 n) j: G
+ I, Z1 n. p9 W+ A* Z0 F' r6 E interface Alarm {
. P1 r) J5 f4 u* m7 z4 N5 o9 O 3 l1 [" d' W, v X/ E: b6 o
void alarm();+ ?8 q5 D9 n [5 q% L
- ?% Z9 V+ K: F1 O; O
} d9 D) F4 B- J% `& S
2 E& Q4 K& s4 M0 G C2 V class AlarmDoor extends Door implements Alarm {
8 y4 V K! W2 X" w" q . } E# L7 ]7 D3 L# E3 r
void open() { … }6 B- G+ v5 J# l
' z* ^% B5 D! y- r- R' e' D) B void close() { … }
- N- `. p2 h7 `+ H0 @# I- ~# C
. P" e9 x' V) D) { void alarm() { … }
4 B. W; m# F5 e3 S/ i
" z7 S6 x. U$ [! c% `2 U( g) x }
8 O' L( K; Y: @3 e 3 n0 U! l' K9 w3 d
这种实现方式基本上能够明确的反映出我们对于问题领域的理解,正确的揭示我们的设计意图。其实abstract class表示的是"is a"关系,interface表示的是"like a"关系,大家在选择时可以作为一个依据,当然这是建立在对问题领域的理解上的,比如:如果我们认为AlarmDoor在概念本质上是报警器,同时又具有 Door的功能,那么上述的定义方式就要反过来了。
1 K/ y) ~/ K0 j* x : U# u+ }. w7 M( }1 Y7 y( W
结论- c5 A ~) f% a' I' X0 J0 Z
9 `& n3 J% J& H. c* b8 v/ r: T! R9 d l
abstract class和interface是Java语言中的两种定义抽象类的方式,它们之间有很大的相似性。但是对于它们的选择却又往往反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理,因为它们表现了概念间的不同的关系(虽然都能够实现需求的功能)。这其实也是语言的一种的惯用法,希望读者朋友能够细细体会。 |