JAVU技巧：java中extends的危害(2)

会计考友

　有一天，有人也许运行这个代码而且注重到Stack没有运行的如想象的那么快，而且能够在重负荷下使用。你能够重写Stack，以至于它不用ArrayList而且继续提高Stack的效率。这是新的倾向的和有意义的版本：
4 \( o. L3 h) p* Z* E　　[/代码]
! W) |8 Z: |. }/ u　　class Stack
　　{
: w' V: q, [' B" X/ x. X' W" R　　private int stack_pointer = -1;
$ F5 U1 t7 p' y. ~, f　　private Object[] stack = new Object[1000]; public void push( Object article )
/ b, J( b: J+ y/ |5 `/ V8 q- {　　{
　　assert stack_pointer < stack.length;
　　stack[ ++stack_pointer ] = article;
　　}public Object pop()
　　{
　　assert stack_pointer >= 0;
; S- J* I( L5 G1 E4 S& q) M8 n& M　　return stack[ stack_pointer-- ];
2 _% M! G, O  Q, Y9 }9 J4 S1 U9 g' p　　} public void push_many( Object[] articles )
　　{
　　assert ( stack_pointer + articles.length ) < stack.length; System.arraycopy( articles， 0， stack， stack_pointer + 1， articles.length );
　　Stack_pointer += articles.length;
　　}
6 d1 @1 F/ U7 P$ q6 a2 U6 a　　}
　　[/代码]注重到push_many不再多次挪用push()—它做块传输。新的Stack运行正常；事实上，比前一个版本更好。不幸的是，派生类Monitorable_stack不再运行，因为如不美观push_many()被挪用，它不正确的跟踪仓库的使用（push()的派生类版本不再经由过程担任的push_many()体例挪用，所以push_many()不再更新high_water_mark）。Stack是一个懦弱的类。与封锁它一样，事实上不成能经由过程小心来覆灭这些类型的错误。注重如不美观你用接口担任，你就没有这个问题，因为你没有担任对你有害的函数。如不美观Stack是接口，由Simple_stack和Monitorable_stack实现，那么代码就是加倍健壮的。我供给了一个基于接口的体例在Listing 0.1。这个解决体例和担任实现的体例一样的矫捷：你能够用Stack抽象术语来写代码而不必担忧你事实上在操作那种具体的仓库。因为两个实现必需供给公共接口的所有工具，它很难使工作变糟。我仍然有和写基类的代码一样的只写一次，因为我用封装而不是担任。在底层，我不得不经由过程封装类中的琐碎的访谒器体例来访谒缺省的实现。（例如，Monitorable_Stack.push(…)(在41行)不得不挪用在Simple_stack等价的体例）.轨范员埋怨写所有这些行，可是写这出格行代码同消弭主要的潜在bug长短常小的成本。[/代码]
) [# L/ @! o/ s* ~　　Listing 0.1. 用接口消弭懦弱基类 1