這里，我不是書生氣。在我自己的工作中，我發(fā)現(xiàn)一個(gè)直接的相互關(guān)系在我OO方法的嚴(yán)格之間，快速代碼開發(fā)和容易的代碼實(shí)現(xiàn)。無論什么時(shí)候我違反中心的OO原則，如實(shí)現(xiàn)隱藏，我結(jié)果重寫那個(gè)代碼（一般因?yàn)榇a是不可調(diào)試的）。我沒有時(shí)間重寫代碼，所以我遵循那些規(guī)則。我關(guān)心的完全實(shí)用—我對(duì)干凈的原因沒有興趣。
脆弱的基類問題
現(xiàn)在，讓我們應(yīng)用耦合的概念到繼承。在一個(gè)用extends的繼承實(shí)現(xiàn)系統(tǒng)中，派生類是非常緊密的和基類耦合，當(dāng)且這種緊密的連接是不期望的。設(shè)計(jì)者已經(jīng)應(yīng)用了綽號(hào)“脆弱的基類問題”去描述這個(gè)行為?；A(chǔ)類被認(rèn)為是脆弱的是，因?yàn)槟阍诳雌饋戆踩那闆r下修改基類，但是當(dāng)從派生類繼承時(shí)，新的行為也許引起派生類出現(xiàn)功能紊亂。你不能通過簡(jiǎn)單的在隔離下檢查基類的方法來分辨基類的變化是安全的；而是你也必須看（和測(cè)試）所有派生類。而且，你必須檢查所有的代碼，它們也用在基類和派生類對(duì)象中，因?yàn)檫@個(gè)代碼也許被新的行為所打破。一個(gè)對(duì)于基礎(chǔ)類的簡(jiǎn)單變化可能導(dǎo)致整個(gè)程序不可操作。
讓我們一起檢查脆弱的基類和基類耦合的問題。下面的類extends了Java的ArrayList類去使它像一個(gè)stack來運(yùn)轉(zhuǎn)：
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}
甚至一個(gè)象這樣簡(jiǎn)單的類也有問題。思考當(dāng)一個(gè)用戶平衡繼承和用ArrayList的clear()方法去彈出堆棧時(shí)：
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();
這個(gè)代碼成功編譯，但是因?yàn)榛惒恢狸P(guān)于stack指針堆棧的情況,這個(gè)stack對(duì)象當(dāng)前在一個(gè)未定義的狀態(tài)。下一個(gè)對(duì)于push（）調(diào)用把新的項(xiàng)放入索引2的位置。（stack_pointer的當(dāng)前值），所以stack有效地有三個(gè)元素-下邊兩個(gè)是垃圾。（Java的stack類正是有這個(gè)問題，不要用它）.
對(duì)這個(gè)令人討厭的繼承的方法問題的解決辦法是為Stack覆蓋所有的ArrayList方法，那能夠修改數(shù)組的狀態(tài)，所以覆蓋正確的操作Stack指針或者拋出一個(gè)例外。(removeRange()方法對(duì)于拋出一個(gè)例外一個(gè)好的候選方法)。
這個(gè)方法有兩個(gè)缺點(diǎn)。第一，如果你覆蓋了所有的東西，這個(gè)基類應(yīng)該真正的是一個(gè)interface，而不是一個(gè)class。如果你不用任何繼承方法，在實(shí)現(xiàn)繼承中就沒有這一點(diǎn)。第二，更重要的是，你不能夠讓一個(gè)stack支持所有的ArrayList方法。例如，令人煩惱的removeRange()沒有什么作用。唯一實(shí)現(xiàn)無用方法的合理的途徑是使它拋出一個(gè)例外，因?yàn)樗鼞?yīng)該永遠(yuǎn)不被調(diào)用。這個(gè)方法有效的把編譯錯(cuò)誤成為運(yùn)行錯(cuò)誤。不好的方法是，如果方法只是不被定義，編譯器會(huì)輸出一個(gè)方法未找到的錯(cuò)誤。如果方法存在，但是拋出一個(gè)例外，你只有在程序真正的運(yùn)行時(shí)，你才能夠發(fā)現(xiàn)調(diào)用錯(cuò)誤。
對(duì)于這個(gè)基類問題的一個(gè)更好的解決辦法是封裝數(shù)據(jù)結(jié)構(gòu)代替用繼承。這是新的和改進(jìn)的Stack的版本：
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{
the_data.add( stack_poniter++, article );
}
public Object pop()
{
return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{
for（ int i = 0; i < o.length; ++i ）
push( articles[i] );
}
}
到現(xiàn)在為止，一直都不錯(cuò)，但是考慮脆弱的基類問題，我們說你想要在stack創(chuàng)建一個(gè)變量， 用它在一段周期內(nèi)跟蹤最大的堆棧尺寸。一個(gè)可能的實(shí)現(xiàn)也許象下面這樣:
class Monitorable_stack extends Stack
{
private int high_water_mark = 0;
private int current_size;
public void push( Object article )
{
if( ++current_size > high_water_mark )
high_water_mark = current_size;
super.push( article );
}
publish Object pop()
{
--current_size;
return super.pop();
}
public int maximum_size_so_far()
{
return high_water_mark;
}
}
這個(gè)新類運(yùn)行的很好，至少是一段時(shí)間。不幸的是，這個(gè)代碼發(fā)掘了一個(gè)事實(shí)，push_many()通過調(diào)用push()來運(yùn)行。首先，這個(gè)細(xì)節(jié)看起來不是一個(gè)壞的選擇。它簡(jiǎn)化了代碼，并且你能夠得到push()的派生類版本，甚至當(dāng)Monitorable_stack通過Stack的參考來訪問的時(shí)候，以至于high_water_mark能夠正確的更新。
