對抽象方法仇恨的自白 - 250bpm
我之前寫過關於抽象成本的文章 。一旦你在IT行業工作了幾十年，一旦你在遺留程式碼上閱讀了數百萬行，你就會對任何一種抽象產生正常的懷疑。並不是說我們可以不做抽象。我們需要它能夠編寫程式碼。但是，每次在程式碼中遇到可以避免的抽象時，您都會感到更加悲傷。有些程式碼庫比羅密歐與朱麗葉和李爾王結合起來更悲傷。
還記得上次讀一個不熟悉的程式碼庫嗎？還記得你是怎麼認為作者是一群無能的白痴？
人們可能會爭辯說這是因為遺留的東西必然是錯綜複雜的，但是嘿，那時候你只是瀏覽程式碼庫而你並沒有深入瞭解它，你生氣的原因是因為你被大量不熟悉的抽象所淹沒。（為了證明這一點，考慮一下你對程式碼庫的看法是幾個月之後，在熟悉之後。看起來好多了，不是嗎？）
牢記這種感覺。在編寫新程式碼時可以考慮它。一個不瞭解這個程式碼庫的人在閱讀時會有什麼感受？
選項不合適。要麼你想要聰明，要麼使用抽象，他們會認為你是個白痴。或者你擺脫了所有不必要的抽象。你會讓他們的生活變得更加沮喪，但他們會認為你是某種傻瓜。（他們可能會重構程式碼，使其看起來更聰明。）
我想給出一個非常基本的例子。
想象一下，要求是你的程式按順序執行A，B，C，D和E.
你可以用最愚蠢的方式做到這一點：
<b>void</b> main() {
<font><i>// Do A.</i></font><font>
...
</font><font><i>// Do B.</i></font><font>
...
</font><font><i>// Do C.</i></font><font>
...
</font><font><i>// Do D.</i></font><font>
...
</font><font><i>// Do E.</i></font><font>
...
}
</font>
或者你可能注意到B，C和D是相關的，並構成一個邏輯工作單元：
<b>void</b> foo() {
<font><i>// Do B.</i></font><font>
...
</font><font><i>// Do C.</i></font><font>
...
</font><font><i>// Do D.</i></font><font>
...
}
<b>void</b> main() {
</font><font><i>// Do A.</i></font><font>
...
foo();
</font><font><i>// Do E.</i></font><font>
...
}
</font>
但是C作為一個獨立的功能可能會更好。您可以想象一下某人想要從其他地方呼叫它的情況：
<b>void</b> bar() {
<font><i>// Do C.</i></font><font>
...
}
<b>void</b> foo() {
</font><font><i>// Do B.</i></font><font>
...
bar();
</font><font><i>// Do D.</i></font><font>
...
}
<b>void</b> main() {
</font><font><i>// Do A.</i></font><font>
...
foo();
</font><font><i>// Do E.</i></font><font>
...
}
</font>
現在從休閒讀者的角度來考慮它，一個只是瀏覽程式碼的人。
當他們檢視程式碼的第一個版本時，他們可能認為作者是一個簡單的東西，但他們可以輕鬆地閱讀它。它看起來像一個故事。你可以把它看成是一部小說。那裡沒什麼好混淆的。部件的順序正確：
A B C D E
但是，當瀏覽重構的程式碼時，不再是這種情況。你看到的是：
C B D A E
掌握正在發生的事情要困難得多，但至少他們會欣賞作者的聰明才智。
或者也許他們不會。