Object-oriented programming

Editor's Notes

• #5: First, process oriented considers about the “function”(procedure and action). What do we need to do for finishing the “function”? What’s the flow about the process? According to those flows, we create the programming architecture and functions and modules. 如上應該定義的非常清楚了，因此當程序邊更時通常配合的資料必須跟著修改，如上DFD的範例： 程序導向的基本思維認為，資料是資料，如果沒有處理程序來處理的話，資料還是只是存在的靜態資訊，是獨立存在的。 所以一般程序導向的設計重心主要會在所需要的資料結構，例如：常應用在關聯式資料庫之實體關係模型(ER-Model)，同常就是一種圖形表示法 + 正規化(Normalization) 產出的資料模型。因為程序導向著重於處理程序，以輸入/輸出為主體的方式思考所處裡的資料。
• #6: We consider “object” and “data” for starting creating the programming architecture. OO is an abstraction concept(Chūshō gainen). Cohesion（內聚Gyōshū）：用白話文解釋，把執行某個功能所需用到的程式與資料都塞在某一個模組（function, class, package, etc）之中，使得該模組可被視為一個單獨的個體執行，那麼這個模組的 cohesion 就愈高。內聚，內聚，顧名思義就是把程式，資料這些有的沒的東西都『聚在一起』打包起來。 Coupling（耦合 カップリング）：如果某個模組跟『其他人（另一個模組）』有關係（例如，使用 global variables 或是接受其他模組傳入的參數）那麼這兩個模組就彼此耦合。 而在談論物件導向的思維前先來談談傳統的模組化，模組化有哪些好處呢？模組化(モジュラー)可以 建立重複使用的處理程序 易於維護 減少錯誤發生，發生錯誤也易於Debug，也不至於引發更多錯誤。 容易擴充(拡張Kakuchō) 但模組化還是無法解決對資料的相依性(依存性Isonsei)，可是何謂好的模組呢？這也是物件導向之所以會被發展出來的原因之一，通常一個好的模組應該具備如下兩個條件： 模組內 - 高內聚力(Cohesion) 模組間 - 低耦合度(Coupling) 因此在物件導向的『封裝』與『抽象化』等特性可以使應用程序與資料之間的相依性關係竟可能存在於物件 (類別) 的範圍之內。由於物件之間本身即有清楚的界線，因此非常例於產生低偶合度的模組，且抽象化也利於產生高內聚力的模組，即符合上述兩種特性。
• #8: 協力します 此類別為資料型態在實作的程式中定義 變數名稱，此類別定義的變數稱之為物件 (Object)，封裝在類別中的運算稱之為方法(Method)，而每一運算方法的函數名稱稱之為訊息(Message)，訊息是實作程式用來指揮類別物件運作的溝通橋樑。
• #10: Class是用來定義object的一種東西，class的內容包含了動作（operations）與資料（data）。 類別算是一個藍圖、一個範本、一個可參考的文件，他沒有 實體 (Instance) 的概念，屬靜態的。
• #11: 簡單解釋： 物件是一個看的到、摸的到的實體，屬於動態的，狀態會隨時改變，但架構與行為不會改變。
• #12: 比喻：建築物 類別：設計藍圖 物件：實際蓋好的房子 兩者關係：設計藍圖(類別)決定房子應該怎麼蓋，決定幾台電梯、幾間房間、走道如何設計。實際蓋好的房子(物件)是照著設計藍圖所蓋出來的房子，人只能照設計藍圖的設計使用這間房子。 比喻二：蓋世武功 類別：武林密笈(武道攻略Budō kōryaku) 物件：修練武林密笈而成的武林高手(マスター) 兩者關係：武林密笈(類別)記載許多各種攻擊(Kōgeki)與回應的方式，讓武林高手(物件)知道遭遇到什麼攻擊時要用什麼招式回應。 程式設計：每執行到我們用 new 運算子時，等同於將物件產生，也等同於成功得到武林密笈可以開始練功，或是在「建構子」的時候就已經賦予你基本功力。 基本上，類別只用來決定物件形成時的樣子，當物件形成時，物件就變成一個記憶體中的空間，記載著物件活動時暫存的資料與狀態，並且當有類別存在時有能力透過方法(Method)執行一些動作。
• #14: Ignoring irrelevant features, properties, or functions. Ex. Mari drive a lamborghini Woman drive a car
• #15: One of the rules is class’ data should be gotten or modified through method or attributed.
• #18: You don’t have to write the same code. Concept of “is-a”. You can rewrite the super class’ method. In jave, just can inherit only one class.
• #19: 以生活中的例子來解釋，假如在一個班級中，老師命令學生搬桌子。 不論是命令學生甲或是學生乙，老師同樣都是說：把桌子搬走。 但學生甲跟學生乙搬桌子的方法會不會都相同？學生甲也許是整張桌子抬起來(運びます)，學生乙可能比較懶，桌子是拖著(引っ張ります)走的。 軟體中會不會遇到這樣的情況？在一個看圖軟體中，開啟圖檔是再平常不過的一件事。但圖檔的格式有千百種，每一種格式的開啟方式都不一樣，這個時候程式該怎麼寫呢？或許有人會用以下的方法： if(filepath的副檔名(拡張子kakuchōshi)為jpg) 使用開啟jpg的函式; if(filepath的副檔名為png) 使用開啟png的函式; ................. 如果支援的格式愈多，條件判斷式勢必會增加，在這樣的情況下，程式會變得愈來愈難維護。比較好的方法應該是以下這種方式： openfile(filepath); 把開啟檔案的功能獨立為一個功能，讓程式碼更為簡潔，但函式裡面的方法又該如何實作呢？這個時候就可以使用多型的方法。
• #21: The overried method must have the same datatype and same number of paramters.
• #24: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions.
• #25: Advantage as below. Separating Error-Handling Code and from “Regular” code. Error up call Stack. Grouping and Differentiating Error Types.
• #26: Conclusion: S.O.L.I.D might seem to be a handful at first, but with continuous usage and adherence to its guidelines, it becomes a part of you and your code which can easily be extended, modified, tested, and refactored without any problems.
• #27: 白話：一個class只作一件事。 問題： 1)到底切多細，很難一開始就知道。 2)切太細造成複雜度過高。
• #29: 白話：軟體要很容易擴充功能，且擴充時原有的code都不需修改。 重要性：OCP是OOD諸多主張的核心。 生活實例： Create a room. You can extends to aparment.
• #31: 白話：設計父類別時，只把所有的子類都有的東西放進來。 生活實例： 女兒問你『把拔，什麼是鳥類？』 你很得意的說『很簡單啊，就是會飛的動物(飛べる動物)嘛！』 (把『會飛』加到『鳥類』這個概念中) 接著打開鳥類大百科開始解說： 『就像這個老鷹(イーグル)就是會飛的動物』 『這個烏鴉(クロウ)也是會飛的動物 』 ostrich(ダチョウ) 『還有.........這個... 企鵝(ペンギン) ......？』@ @||| Big bird(ビックバード)
• #33: 白話：設計介面也盡量簡單，別把不相關的東西放進來。 生活實例： 業務員：『太太！你看我們最新的遙控器，可以遙控電視、冷氣、撥放器，連洗衣機也可以遙控，讓你一機在手家事一手包辦...』 太太：『那我衣服洗到一半，被轉電視的小朋友按到停止怎麼辦？可以把洗衣機的部分拿掉嗎？』 業務員：『...』 其實這個我昨天提到的Liskov替換原則有點相近，如果我實做的介面有三個函示，而我只實做了兩個，另一個我根本不能用或者是不要用。 那這時候就違反了這個ISP（介面分割原則），此時我這個類別也等於無法相容於基礎類別，那又違反了Liskov替換原則了。 所以寧願多用幾個介面，也不要將很多個方式全部放到一個介面當中讓來實做的類別誤用，污染了這個介面。
• #34: 看起來好像沒什麼問題吧！但是，如果我的工人裡有機器人呢？ 那怎麼辦？如果讓機器人直接實做I工人介面，那機器人就會被強迫實做「吃飯（）」這個函示，這時候鐵定是行不通的。讓我們將程式碼修改如下：
• #35: 白話：不要具體的指明物件的關係，而要抽象觀念替代之。 相關觀念：IoC(Inversion of Control, 控制反轉)。另DI(Dependency Injection, 依賴注入)則為其實作的方法。 生活實例： 你下班快到家時，接到老婆的電話，才驚覺今天是結婚紀念日。 千萬別在電話中說，『當然，我帶了妳最愛的玫瑰花回家哦！』(具體) 因為很可能稍後發現......附近的花店都關門了... 只要說『當然，親愛的，我帶了禮物回家』(抽象) 這樣一來就能看到路邊賣什麼就買什麼。
• #36: 舉個我們IT人最喜歡的電腦為例：電腦中有很多零組件，有硬碟、顯示卡、CPU…等等零件。 拿硬碟來說，硬碟的廠商有A廠商、B廠商、C廠商…等等。 可是，不管是A或B或C廠商的硬碟，只要介面一樣我們都可以裝在我們的電腦上（例如SATAII）。 我們可以把SATAII這個介面當想成是「抽象」，而各個廠商的硬碟想成是細節（也就是實做）。 所以各加廠商都依賴「抽象（SATAII）」而實做出（SATAII的）硬碟。 這樣到我們的手上才可以使用。如果各家廠商都用自己覺得最快的方式做出他們自己的硬碟，那們我們就會被綁死。因為，互相都不能相容阿~