這兩天閱讀了《程式設計師的思維訓練》和《暗時間》兩書，其中不約而同地提到了抽象這個概念，也就是說我們在學習的過程中將知識抽象，然後在遇到問題的時候將問題抽象，利用抽象出來的這部分去匹配從而實現大腦中「海量資料」的搜尋匹配，很多時候我們沒法想到解決問題的方法、沒法做到學以致用或者由此及彼可能就是由於對知識的抽象不夠，沒有發現知識點的核心——表現出來就是死讀書，也有可能是對問題的抽象不夠，沒有發現問題的本質——表現出來就是一直走彎路。
以上這一部分很好理解，使我產生困擾的是《思維訓練》一書中對新手和專家的定義，書中認為，新手需要情景無關的知識，專家可以從情景相關的知識中學習。也就是說新手需要的是機械化不需要判斷的指令，比如「電腦卡了就重啟」這種，但專家需要的是某種更具體化細節化的知識，他們可以從這些針對性的知識中舉一反三，用於之後其它領域的問題解決過程中。
這裡我就遇到了第乙個問題：「電腦卡了就重啟」不屬於情景嗎？情景該如何定義？
看過《暗時間》之後，我認為他提到的「抽象樹」和「抽象層級」的概念恨正確，也就是說知識屬於「情景有關」還是「情景無關」取決於你怎麼去看待它，知識（以及經驗）誕生之初肯定都是具象的，處於抽象樹的底端，我們去抽象它的過程就是它在抽象樹上移動的過程，它處於乙個怎樣的抽象層級取決於我們有多強的能力。情景自然也是這樣，對新手來說，「電腦卡了就重啟」這條指令不需要抽象，遇到」電腦卡了「這個問題的時候也不需要去抽象，就是用一對一的方式，通過具體的知識（指令）解決具體的問題。因此，此時作為新手只關注了抽象樹的最底層，所以即使他正處於樹的底部（葉子節點），而對它的子樹而言卻屬於處於根部，這就是區域性的情景無關。反之，對專家而言，同樣的問題，他可能會去對知識抽象，比如電腦卡頓的原因是什麼，怎麼判斷電腦卡頓，為什麼重啟就能好，重啟的過程是什麼樣的，其中哪些步驟起到了關鍵作用等等，遇到問題時也會對問題抽象，因此不再侷限於」電腦卡頓「這乙個具體問題上，可能遇到的其他記憶體、匯流排、處理器問題都能通過這個知識的抽象得到提示。這時我們就可以說專家其實工作在抽象樹高層上，他關注點之下的子樹很大，相比於新手的單節點樹，不再是簡單的一對一匹配。
總而言之，我認為所謂的「情景無關」指的是不需要對知識的前提進行抽象與判斷，只是個if語句，而「情景相關」則需要我們對情景進行判斷並選擇，既包括對問題情景抽象也包括對知識情景的抽象。
理解了這一點，我認為《思維訓練》一書後文中所說的「專家能從箴言中學習，而新手不能「這一觀點也不難理解了。
關於抽象類與抽象方法
using system using system.collections.generic using system.linq using system.text using system.data using system.drawing using system.componentmodel u...
關於抽象方法與介面
抽象方法是一種特殊的方法 它只有宣告，而沒有具體的實現。抽象類不一定必須含有抽象方法 但是不符合抽象類設計模式。也可以擁有成員變數和普通的成員方法。設計乙個抽象類，為了繼承而存在。抽象類不能建立物件，卻有構造方法，乙個類繼承抽象類，並不一定要覆寫超類 父類 的抽象方法，派生類 子類 分配堆區的方法指...
關於for迴圈在各種情景下的練習
1.寫出1 1000之間的質數，並儲存在乙個陣列中 int result new int 50 建立乙個陣列，大小可以儲存50個元素 int count 0 用來計數 for int i 2 i 1000 i 2.將陣列中的元素倒敘輸出 例如 double src 這裡要將src 0 和src 3 ...