作者講的「快速學習法」，其本質上應該就是我先前做過重點摘要的「費曼學習法」，想要教授一樣技能或技術給他人時，自己就要徹底理解問題或技術的本質，然後收集相關的資料，用自己的話重新詮釋問題及解決方式。在這個過程中，就能把知識轉化為自身的理解，從而跟自己的知識樹相連接，存在腦海深處變成本能。

職場產業

學習

陸續看了很多自媒體/部落格行銷的書跟文章，都說明了信任度及品牌建立的重要性，因此我決定幫公司新開一個部落格，專門寫一些技術性或學術性的文章，以前自己埋頭做也沒太多機會整理發表出來，這或許是個契機吧! 在這個部落格寫文章對公司的生意（業務）有什麼幫助？坦白說，我也不知道。

什麼是領域模型？領域模型是完成從需求分析到物件導向設計的一座橋樑。需求分析和物件導向並無直接關係，需求分析階段不區分是物件導向還是程序導向，要從「領域建模」才真正開始物件導向的工作。後續我們會使用一個「影像處理軟體」的使用案例來說明如何建立領域模型。

封裝、繼承、多型是物件導向的三大核心特徵，判斷一種程式語言是否為物件導向的程式語言，就看其是否支援這三大核心特徵。

軟體類別是對現實類別的模擬，但不是簡單的等同。除了實作現實類別相對應的功能，還會創造出許多現實中不存在的類別。

這個創造過程正是各種設計方法、設計模式、設計原則大顯身手的地方。

常見的 C 語言是屬於程序導向中結構化程式設計的概念，採取『自上而下、逐步細化、模組化』的方法，從而降低軟體發展的複雜度，因此 C 語言成為 20 世紀 70 年代軟體發展的潮流。因為結構化程式設計的方式無法滿足軟體『可擴充性』和『可維護性』的需求，因此物件導向的概念才開始普及。

設計模型主要包含兩個部分：靜態模型、動態模型。動態模型設計一般都是在類別模型設計完成後開始，此階段需要使用類別模型的類別。動態模型設計不需要應用「設計原則」和「設計模式」，只需對照「使用案例模型」，並根據使用案例的特點，選一個適合的動態模型表述即可；動態建模不需要面面俱到。


從電腦程式語言的歷史來看，進入門檻越低且容易取得相關資源的程式語言會被廣泛使用。現代的軟體開發更重視軟體元件(函式庫)的整合使用與架構，更勝於程式語言本身的特性。現代程式語言的開發已經轉向重視易用性、安全性及函式庫支援的豐富程度，而非單純講求執行階段的效能。 

現代的計算機概論範圍也越來越廣了，從傳統的「硬體」、「軟體」到「通訊」及「資料」等；其中，通訊現在應該算獨立於計算機之外自成一派。而資料科學則在近十年「機習學習」或「深度學習」變成顯學後，受到高度重視。不想變成時代的眼淚，還請多努力，別輕易躺平。


以行動支持創作者！付費即可解鎖

終於完成物件導向的設計，包括用於指導撰寫程式的「類別模型」和「動態模型」。以物件導向的方式進行設計，只是進攻的前奏，撰寫程式才是最終的目標。雖然物件導向的理論、方法、技巧經過多年的發展後，業界已經形成基本統一的認知，但並未出現一種統一的「物件導向程式語言」。

在實務上，為了求快，工程師們常知其然不知所以然，反正呼叫 API 能動或能給出想要的結果就好。但這樣的想法到底是讓軟體設計變的更輕鬆，還是入門容易熟練難呢？ 當你邊上理論課程，然後自己又有能力設計出基於理論的實用軟體工具，並分享給其他人使用時，豈不是更滿足也更有成就感!

我們常使用別人設計好的 API 來使用，這符合現代軟體設計的概念，利用軟體元件拼湊組合出新的功能，不做重覆的事。但這樣真的行嗎？中間跳過了甚麼？這個軟體元件為何要這樣設計，它隱含的分析及設計流程全部跳過，如果一昧地只會用別人設計好的東西，那當遇到的非典型情況時，自己又該怎麼處理呢？

閱讀可以用最低的成本來獲得別人經驗，培養閱讀能力，一生受益。但要記住，別只讓自己的大腦永遠處於「輸入狀態」，要適當地「輸出」自己的想法。透過閱讀輸入，再利用寫作輸出，就像「費曼學習法」說的一樣，教授到別人能夠了解，自己才算是領悟了這門學問。