物件導向 | Kenmingの鮮思維

論述軟體三大基礎觀念－封裝、一般/特殊化 (繼承)、介面/多型

2018-04-16 17:18 | 閱覽人次：5,915 | 尚無迴響

這是看到 PTT Soft_Job 版區一位網友的貼文：[請益] 我這樣解釋OOP對嗎?。原來我已在「FB-軟體設計鮮思維社群」針對此貼文已寫一篇文論述，在此邊我也把回文作個備存，然後再加上一些些心得分享。

剛入門所謂 OO → 連帶等同所謂「物件導向」觀念實作與設計觀念時，幾乎各類 OOP 入門書籍均會談論到此三大術語：封裝 (encapsulation)、繼承 (inheritence)、介面 (interface)/多型 (polymorphism)。看似簡單的術語，卻可能連多數鑽研多年實作的程式開發人員，還不容易真正體會這些觀念的意涵與作用。

即使入這軟體開發行業多年，仍會發現到，軟體大師們的著作，從最早期的 GoF 四人幫「設計模式 (Design Pattern)」，至近幾年「重構 (refactoring)」、「Clean Code」等著作，幾乎都是含繞在上述三大觀念的解釋與實踐。所以也就是說，這三大觀念可以說是要窮究一輩子的研究、思考與實踐力行的，它沒有絕對的標準答案，但也不見得好像很虛妄抓不到。每一段時期的經歷與學習，就可能會對其有著不同的想法與心得體會。

以現在個人入行軟體開發這行業約莫10來年，主要專職於軟體顧問輔導與教學，就以現階段綜合學習、觀察、反思與經驗等，來對這三大術語發表純文字的論述。可能又等 5~10 年後，當又有不同的體認時，再來對比現在的論述，作心得的補充或修正了。 :)

花了三個多小時撰寫這篇 PO 在 PTT soft_job 版，關於 OOP 的三個主要觀念：封裝, 繼承, 介面/多型。

這裡特別提醒下，程序語言用書很喜歡用「繼承」這字眼來解釋 OOP，其實那很容易誤導，常會用父母生子這種觀念看待。適切的用語用 "擴展 (extend)" 較適合。UML 稱之為一般化/特殊化更是合理。

閱讀全文 »

敏捷式系統分析設計與實作—活用 UML/SCRUM 與 C#.NET (2017/07/15, 48 Hrs)

2017-04-12 15:46 | 閱覽人次：3,684 | 2 則迴響

§ 課程介紹

＊＊＊＊＊＊　
1. 本課程包括 UML Model & C#.NET/JAVA 完整程式碼均會以開源 (open-source)方式置於 GitHub 供學員免費下載與持續更新。
2. 課程的實作會同時提供 C#.NET 案例程式碼與 UML Model 檔。
3. 每一期同類型課程會以 C#.NET 與 Java/Srping 交替作為案例實作展示，學員可免費再次旁聽下一期不同程式語言的課程。
＊＊＊＊＊＊

HSDc. 顧問開發團隊綜合多年來的大型系統實務輔導與開發經驗，並結合大量研究的理論知識與平台技術，所推出關於完整的系統分析、設計至實作的課程，期能協助軟體開發人員在現實的工作中，能瞭解完整的開發流程與各個角色的工作執掌與產出。

在基於以架構為中心來建立團隊具共識的整體觀下，能聚焦在適切開發單位的功能點內，快速地從需求分析導出到實作，找出並克服開發過程中，包括溝通、技能與技術等風險因子。而後基於這樣的框架目標內，得以對系統的結構作重整，卻又不至於影響已有的功能前提下，得以對程式碼施以重構的技巧，讓系統更有延展度與彈性。

觀念的傳授、設計的圖形化塑模表達、程式碼的實作三層次，是我們對於系統分析設計與實作課程的基本原則與態度。

修習本次系統分析的學員們，也必然可以拿到完整的教材、完整案例的 Model 檔與實作程式碼的對應，帶回去自行練習，並能對映於工作上，如此才會有顯著且實質的效益。

HSDc. 軟體團隊，強調的是「虛」與「實」兩者調和的『知行合一』．．．。

==================================================================================================
閱讀全文 »

關於 PTT Soft_Job 對於 OOP 的一些回應

2015-03-02 10:59 | 閱覽人次：6,695 | 尚無迴響

沒想到 PTT 的 Soft_Job 看版有人在聊 OOP 的觀念，忍不住作了一些回應。

早期把物件化的分析/設計思維歸為 OOA/OOD (Object-Oriented Analysis/Design)；實現物件化思維的程式語言則稱之為 OOP (OO Programming)。
實現 OO 思維主要有兩個機制：介面 (interface)、多型 (polymorphism)。包括 .NET/Java 等主流語言，早已支持 OOP，甚至連 php/python 等原來屬於 script-based 的程式語言，也朝向 OO 化的實現機制。
從 OOP 的角度來看到物件化的設計思維是不妥的；原因在於絕大數開發人員並不知道 Why OO Thinking！其實採用 OO 設計化思維是必然會增加開發成本的。因為它並非為了解決某一局部的邏輯性問題，而是考量全局，從系統整體來看待「變動 (Change)」的議題，進而提出如何擁抱改變 (embrace changing)的解決方案。
再則從實作上，OO 化的特徵是分散式的 (因為基於類別 (class)的責任分派 (responsibility assign)原則)。所以為了實現 OOP 的分散式架構，程式碼必然大量分散於各類別內，如此會造成實作與偵錯的難度；因而一個必要的配套措施：TDD (Test Driven Development)，測試先行是一定要養成的好習慣。
越是大型變動頻繁、高度維護，或者期待包裝為產品，增加其再利用性價值的系統，採以 OO 的設計/實現 (當然，前提要有這樣實在技能的軟體架構師/Developer)才能感受到其好處：每一次只改變一點點；每一次的變動可以侷限在可控制的變動範圍內。
OO 的特徵是將程序/資料封裝至某一類別內，其實在抽象層次，程序稱之為「行為 (behavior)」、資料稱之為「屬性 (attribute)」，兩者均為物件必然會有的特徵 (features)，是非常自然不致分離的。但因現實仍沒有一種有效的機制能把物件的狀態 (state)儲存起來，所以實作技術上是把物件與資料分離，資料儲存於資料庫系統內、待執行期間 (run-time)才透過如 OR Mapping (如 .NET ER Framework、Java Hibernate 等)，將物件與資料合而為一。
實業界很有趣的一個現象：重視 MIS (Management Infomation System)系統的公司，幾採以資料導向的開發模式；重視 Web 框架如網路行銷公司，大都採以程序導向的開發模式。至於所謂的 OO 化，實現的程度其實還蠻微小的。
順待提下重構 (refactor)的觀念：重構是屬於事後 (Coding 後)的設計，一般與事前 (Coding 前，如典型的 SA/SD)設計可能存在著 3:7 或 4:6 (事前：事後)的比重。而且往往寫完程式才是另一段故事的開始：持續重構 (continous refactoring)。
重構的要件：不會影響到已經上線系統的所有功能。衡量重構的指標：每一個 method 不會超過 10 行、最長不得超過 20 行。
如今重視 Web 相關技術、快速實現商業創意的年代，其實已少人有人談及 OO 更遑論具體實踐了。西元2000年以前，包括 UML 三大師 (Booch、Rumbaugh、Jacobson)、Martin Fowler (重構一書即為他的著作)、Kent Beck (XP/Agile 的始祖)、Bob (Clean Code 作者)均為支持物件思維的軟體大家。國外除了這些大師外，實現 OO 的專家其實也不多，一般是會落在如開發底層框架 (如 .NET Framework)的關鍵架構師。

閱讀全文 »

程式碼與 UML 類別_循序圖的關係探討-完結 (4)

2010-05-14 08:05 | 閱覽人次：16,791 | 1 則迴響

支援自動產出循序圖的工具

EA (Enterprise Architect) 8.x－內建動態產出循序圖的機制。
Together, RSA, Flowchart4j(c#) －支持靜態產出循序圖的方式。
HSDc. Sequence Genenator (名稱暫訂)
- 實作於 EA 7.x-8.x Plugin。
- 支持靜態產出循序圖的方式。
- 可支持正向/反向將程式碼/循序圖互轉的功能。

HSDc Seq. Generator plugin 操作示範

安裝 Seq. Generator plugin

（點擊圖片鏈接看原圖）圖、安裝 Seq. Generator plugin

閱讀全文 »

程式碼與 UML 類別_循序圖的關係探討 (3)

2010-05-10 16:31 | 閱覽人次：9,356 | 尚無迴響

程式碼與循序圖的正反向工程

先瞭解一個重點：靜態程式碼結構並無法直接對應循序圖 (對應的是類別圖)。

兩種方法可以產出循序圖：

動態產出：設定 run-time 環境，實際執行應用程式，再由 UML 工具至系統內追蹤解析。
靜態產出：直接掃瞄程式碼，解析物件之間的參考 (reference)。

動態產出循序圖的優缺點：

優點：
- 不需要程式原始碼，只要具有能直接執行的應用程式 (如 .NET DLL 執行檔)即可。
- 可以確實捕捉單一程序內，物件之間的呼叫情形。
缺點：
- 需要事先設定好可以執行該應用程式的 run-time 環境。設定相當複雜繁瑣 (一般需為命令列模式)，且不同的程式語言 (如 C#NET, Java, PHP …等)均須各自設定不同的 run-time 執行環境。
- 只能呈現單一執行路徑內的物件互動。意即，無法呈現如 If…Then…Else 或 Exception 等多種條件或替代路徑。

靜態產出循序圖的優缺點：

優點：
- 不需要設定繁瑣的 run-time 執行環境，操作相當簡潔。
- 可以指定所掃瞄的程式碼深度 (層次)。
- 可以同時呈現多重的條件或替代路徑的物件呼叫互動情形。
缺點：
- 需要有原始程式碼，以提供靜態掃瞄的來源依據。
- 轉換工具的實作邏輯並無明確的轉換 (transform)規則；相對來說，需要考量到程式語言個別的機制與語法，故轉換工具的實作難度相對提高。

※ 延伸參考
o　程式碼與 UML 類別_循序圖的關係探討 (1)。
o　程式碼與 UML 類別_循序圖的關係探討 (2)。

程式碼與 UML 類別_循序圖的關係探討 (2)

2010-05-06 22:45 | 閱覽人次：22,341 | 尚無迴響

程式碼與 UML 設計圖之間的關聯性

從抽象的角度思考類別(Class)/物件(Object) 的關係

物件是活的！
但是，類別可不是死的 (更不是活的)；因為，它僅是對系統的設計契約而已。

問題思考！？
程式原始碼 (Source Code) 對應的是 UML 哪一張設計圖？

推導－1
程式碼 = 靜態結構 = 設計契約 = 類別設計

所以 程式碼 對應的是：UML 類別圖 (Class Diagram)。

Ex. 程式碼與類別圖的對應

範例－靜態的程式碼設計契約
範例－程式碼與類別圖的對應關係

使用 UML 類別圖 (Class Diagram)的好處

快速定義類別的結構 (包括類別名稱、屬性與行為)。
過濾程式碼實做的細節，容易聚焦於類別的責任分派 (responsibility assign)設計議題。
可以透過工具，將類別圖轉出至對應的程式碼 (反之亦然)骨架 (skeleton)。

類別圖無法作到 …

無法呈現系統執行期間 (run-time)，程序單位之間的呼叫情形。
無法追蹤為完成某一特定功能案例，物件之間的動態相依呼叫關係。
無法掃瞄物件之間的動態連結，是否有違背類別圖的結構設計。

閱讀全文 »