跳到主要內容

物件導向複習筆記

參考網址: https://dotblogs.com.tw/ace_dream/2016/01/10/oop1

物件導向的三大特性:
封裝:(Encapsulation):指的是將一組相關的屬性、方法和其他成員,視為單一單位或物件。
繼承(Inheritance):則是描述依據現有類別來建立新類別的能力。
多型(Polymorphism):指的是您可以有多個交替使用的類別,即使每個類別是以不同的方式來實作相同的屬性或方法。

封裝:(Encapsulation):
物件都會擁有物件內部的私有部分(屬性、方法...)而這些部分必須是外界無法直接存取,這樣才能保有物件的完整性。
如果"破壞封裝"的話,會有可能無法恢復原來的功能,因此物件必須將私有的部分封裝在物件的內部,而使用者只能藉由物件所提供的方法、屬性來操控物件,以保持物件的完整性,這就是封裝的特性。

繼承(Inheritance):
一個物件A得到另一個物件B特性的過程稱為“A繼承B”,物件B則屬於“父類別”或稱基礎類別(Base class),物件A則屬於子類別或稱為衍生類別(Derived class)。

子類別可以繼承父類別的能力,直接使用父類別非私有的屬性和方法。
子類別只能繼承一個父類別。
父類別的方法若宣告為虛擬(virtual),則表示該方法可以被子類別覆寫(非必需)。
父類別的方法若宣告為抽象(abstract),則表示該子類別一定要覆寫該方法(子類別為抽象類別除外)。
類別若包含抽象成員,則該類別必需宣告為抽象類別。
父類別又叫做基底類別(Base Class)。
子類別又叫做衍生類別(Derived Class)。
若方法或屬性宣告為密封(sealed),則不可以被子類別覆寫

多型(Polymorphism):又稱同名異式,是透過動態繫結的方式讓我們在程式執行時期可以動態決定物件參考所要執行的方法,多型允許我們在程式中使用名稱相同的方法或屬性,但不須考慮當時使用的物件型別是什麼。若要設計多型,子類別就必須先覆寫父類別同名稱的方法或屬性,接著再使用父類別的物件參考來選擇所要執行子類別物件實體的方法。由於多型的使用上會在類別中建立名稱相同的成員(屬性或方法),多載(Overloading)和覆寫(Overriding)也可以建立名稱相同的成員,因此有必要釐清這兩者的概念。

多載(Overloading):可接受不同個數的參數或不同資料型別的參數,用來提供不同版本的屬性或方法。也就是多個方法擁有"相同名稱"但"不同參數",傳入不同參數時會執行對應的方法。

覆寫(overriding):子類別的成員可用來取代父類別中不適用的成員,子類別覆寫父類別的成員時,子類別與父類別的成員必須接受相同個數的參數與相同的資料型別。也就是子類別重新定義父類別的"同名同參數"方法。

如果子類別想要重新定義父類別的方法或屬性(覆寫),首先必須將父類別的方法宣告為virtual,表示父類別允許被子類別的同名的方法覆蓋;而子類別要覆蓋父類別同名稱的方法,必須將子類別的方法宣告為override(覆寫),表示要重新定義父類別的方法。

留言

這個網誌中的熱門文章

[學習iOS之路] Lifecycle 比較

在開發Android很多年之後終於開始學習寫iOS了 契機就是工作需要,果然工作需求就是推開最大靜摩擦力的原動力啊! 在這邊寫下學習Swift的一些筆記,希望在自己忘記或是需要給別人教學的時候可以起到一點點作用。 因為對Android比較熟悉,所以透過比較來熟悉iOS架構 首先是iOS與android的比較 可以參考這張圖 Android vs iOS lifecycle 與這張 iOS 詳細state 流程 Android lifecycle OnCreate -> OnStart -> OnResume ->(running) -> OnPause -> OnStop -> OnDestroy                        ^                  ^                                  |               |                         |                  |-------------------v               |                         |-----<-----   OnRestart   ------<---------v iOS lifecycle LoadView -> ViewDidLoad -> ViewWillAppear -> ViewDidAppear -> (running) -> ViewWillDisappear -> ViewDidDisappear -> ViewWillUnload -> ViewDidUnload -> dealloc 於ViewDidDisappear之後view就看不見了,如果view要再次被看到且view還存在 那就會是ViewWillAppear,否則就是LoadView從頭開始 下一篇是語言的比較 Java vs Swift

Docker vs VM 的學習

工作上用到 Docker 也一段時間了,剛接觸到 Docker 時常常會聽到別人這樣解釋," Docker 的 Container 技術,類似於 VM 。差別是 Container 比較小,沒有包含 OS,而 VM 會包含 OS"。 這段話我覺得不算是全錯,所以我一開始也是這樣去解釋給別人聽,直到我聽到我同事在面試求職者時問了這句話,"如果 Container 比較快,比較輕量,優點這麼多,為什麼 VM 沒有被淘汰?" 我才忽然意識到,我並沒有真正瞭解這兩種技術的差別。 事實上,這件事情要從解決問題的角度上出發去理解。任何技術的產生應該都是為了解決某些痛點,從這點來思考的話網路上就有很多文章可以查到了,我把我查到的最清楚的文章連結放下本文最下方,有興趣的可以去看看。 VM 是為了解決硬體的資源共享的問題所產生出來的技術,而這個需求仍然存在,並不會因為有了 Docker 的 Container 技術就取代了。這個可以回答為什麼 VM 沒有被淘汰。因為要解決的問題不一樣,事實上很多 Container 還是跑在 VM 裏頭,可謂是相輔相成。 那 Docker 是為了解決什麼問題才發明的呢? 我的消化與理解是 "解決建置環境的複雜度" 而發明的,每個 Dockerfile 會指定使用的映象檔(image),然後寫下需要安裝的 Tool 指令。按照這個 Dockerfile 上面列下的指令去安裝與建置,就可以重現執行這個 APP Runtime 所需要的環境。這解決了以前工程師常說的那句話 "在我的電腦上跑得好好的,為什麼在正式環境就行不通" 的問題。   參考連結

C# CSRF attribute 的錯誤追蹤與處理

最近開發網站碰到一個問題,有時候可以登入成功,有時候不行。但明明帳密都是 Google 記憶的,不可能打錯帳號密碼。後來猜想到是 CSRF 認證的問題,由於網站是透過 k8s 建立的,且 replicas: 2。很大可能性是因為拿 token 是跟 A Pod 拿,但登入是跟 B pod 登入,造成 token 無法驗證成功。 想證明這個問題,我們必須去紀錄 Log,由於我們是透過 C# 的 ValidateAntiForgeryToken Attribute 實作 CSRF 的防禦,因此一開始想法是寫一個 ExceptionFilter 去攔截例外。但發現無法攔截 CSRF 的問題。後來找了一段時間發現,CSRF 並不是丟出例外,而是結果回覆 HttpStatusCode 400。查到可實作 IAlwaysRunResultFilter 攔截結果,並判斷是否是 IAntiforgeryValidationFailedResult 的一種。 程式碼如下:  public void OnResultExecuting(ResultExecutingContext context) { if (context.Result is IAntiforgeryValidationFailedResult result) { // Log here } } 但是這樣還不夠。還必須要強制關閉客戶端錯誤的轉換才行,這樣才可以精準的把結果視為 IAntiforgeryValidationFailedResult 至於怎麼關閉則是在註冊 MVC 服務的時候設定 Config SuppressMapClientErrors = true 即可。      services.AddMvc().ConfigureApiBehaviorOptions(options => { options.SuppressMapClientErrors = true; }); 詳細可以參考 MSDN