包含標籤 NewbieGuide 的文章

菜雞與物件導向 (4): 繼承

接著要介紹的是繼承 aka 物件導向三大特性之王 aka 濫用榜 Ko.1 ,繼承的強大幾乎和它的惡名一樣可怕,給一個從聊聊程式的這篇 [心得整理] c# 物件導向程式 - 2.封裝、繼承、多型的三大特性 摘過來的例子就可以略知一二了:

什麼也不做,僅僅只是繼承而已,就取得了繼承對象(C# 中稱為基底類別)近乎全部的內容,真是太可怕了。在 C# 中,繼承可以取得基底類別除了 Private 以外所有的內容,例如 Protected 更是表明就是只給繼承使用的。

由此可見,在減少重複程式碼的路上,繼承無疑達到了全新的高度。

那麼繼承代表的是什麼意思呢?大多的網站都能直接說明:繼承是一種「is-a」的關係。當你能說出A是一個B的時候,就代表你認為A可以繼承自B

最直覺的繼承例子就是物種的分類。舉例來說,狗跟貓都是哺乳類,因此他們都可以繼承到一些哺乳類共通的特徵(例如哺乳、用肺呼吸)。藉由繼承,我們可以把這些哺乳類共有的特徵全部放在哺乳類這個物件,再由狗和貓分別去繼承哺乳類,藉此讓他們都能得到哺乳類的特徵,再進一步發展出自己的特徵和行為,甚至重新定義基底類別的方法為自己所用。因此,像大話設計模式就將繼承說明如:繼承者是對於被繼承者的一種特殊化。

如此一來,當我們需要修改哺乳類的定義的時候,只需要修改一個地方,而繼承了哺乳類的這些物件(C# 中稱為衍生類別)全都能夠一起修改到,大大地減少了跑來跑去修改的次數,也讓程式碼的重複大幅度地減少

然而也因為如此,繼承最大的惡名出現了:繼承享受了取用基底類別內容的好處,卻也必須背負牽一髮動全身的風險

……

閱讀全文


菜雞與物件導向 (3): 封裝

封裝包含了兩個重要的觀念:

  • 控制物件和外部進行互動的出入口
  • 隱藏物件內部的細節資訊

強者我同事整理的文章裡的例子就舉得不錯:當你按下鍵盤的A鍵,螢幕隨即出現了A,你不必知道中間發生了什麼事,你只需要知道怎麼操作和最後得到什麼就可以了。

其中鍵盤提供的按鍵,就是我們對電腦進行互動的出入口;而電腦實際上做了什麼事情,也被隱藏了起來,讓我們只需要關注結果就好。

此外我也看到過販賣機的例子,當你去販賣機買飲料,你也不需要知道裡面的構造,只要知道你選了飲料投了錢,飲料就會跑出來就行

從上面的兩個例子,相信大家已經掌握到封裝的概念了:將物件視作一個整體,把內部的實作內容隱藏起來,讓使用者只需要知道怎麼使用這個物件即可。(相似的思路,我們後續的介面會再提到)

如果封裝做得夠好,除了可以將程式碼整理得井井有條以外,也能讓物件內部的修改不會直接影響到使用物件的地方,達成了降耦合的目標

並且也能讓物件的使用者直覺地知道如何使用物件提供的方法,如此使用者就可以專注在更高層次的抽象,而不用被物件內部的細節所干擾。

最後,從上面的敘述中我們可以察覺到要實現封裝,最重要的就是:對外的開放程度(存取範圍)的控制。或是套一句前輩的說法:給程式碼隱私的空間

補充:如果想問「什麼是耦合?」的朋友,建議可以看看這篇:實務上的高內聚與低耦合

或是參照本系列後續的 內聚與耦合

存取範圍與存取子

先讓我們從存取範圍開始說起吧,因為我個人慣用的是 C#,因此就介紹一下 C# 是怎麼控制存取範圍的。

在 C# 之中,類別裡控制可見度是使用修飾子來定義存取範圍,也就是當我們替類別宣告欄位時常看到的 PublicPrivate

  • Public: 這是公開的,所有人都看得到
  • Private: 這是私有的,只有自己看得到

除了最常用的這兩個以外,還有其他的修飾子可以先知道一下:

  • Protected: 這是受到保護的,只有自己和繼承的孩子們看得到
  • internal: 這是內部的,只有身為同一個組件的朋友們看得到
  • Protected internal:組合上面兩個,也就是可以給同個組件的朋友們,或是其他組件繼承的孩子們看見

接下來的部分會以最常見的 PublicPrivate 來繼續說明,對存取範圍的這些修飾子有興趣的朋友,可以參照 存取範圍層級 的說明。

現在我們已經知道了有哪些修飾子可以用來控制存取範圍,但為什麼我們會需要宣告存取範圍的大小呢?其根本是為了將控制權掌握在物件本身

就像大話設計模式比喻的:物件就像間房子,我們不希望被看光光,可以看見的 Public 就像門和窗,而不該看見的 Private 則是用牆壁隱藏起來,而對於這間房子而言,門窗是可以控制的。

……

閱讀全文


菜雞與物件導向 (2): 建構式、多載

我就直接說了,有用前面的程式碼區塊的人,絕對執行不了。因為我們建立哥布林和戰士這兩張卡片的時候,根本就沒有給他們數值呀!

雖然可以先呼叫出來再賦值…

var goblin = new Card();
goblin.Name = "哥布林";
goblin.Attack = 3;
goblin.Health = 2;
/* ...其他賦值 */

這實在相當占空間,也有點奇怪。畢竟如果是阿福(狗),一出生的時候應該就確定了一些特徵才對,例如品種、血型、眼睛顏色這種。並不會出生後過一陣子,才突然決定這些東西,既然如此,我們在產生物件的時候,當然也會希望在建立的同時就先決定好一部份內容

這時候我們就可以藉由建構式的方式,在建立物件時就進行一些我們想要的操作。

建構式

事實上,當我們呼叫 new Card() 的時候(不覺得這個 () 很有呼叫方法的感覺嗎?)我們就是正在調用 Card 的建構式。而當我們沒有特別去定義建構式的時候,就會直接使用內建的建構式去幫我們產生物件。

現在我們替 Card 新增一個建構式:

public class Card
{
    public Card (string name, int attack, int health)
    {
        this.Name = name;
        this.Attack = attack;
        this.Health = health;
    }
    /* ... 其他屬性和方法 */
}

在 C# 的時候,建構式必須和類別同名,且不需要定義回傳類型。當我們有了建構式,剛剛的例子就可以改寫成:

var goblin = new Card(name: "哥布林", attack: 3, health: 2);
var warrior = new Card(name: "戰士" , attack: 4, health: 3);
warrior.Hit(goblin);

建構式也就是建立這個物件時執行的函式,通常會用來進行初始化,也就是做一些建立物件必要的準備。例如傳遞必要屬性或是建構需要的其他物件、或是給予私有屬性初始值等等,例如說我們的卡牌一建立,就會需要知道它的名字和戰鬥力,這樣才有卡牌的感覺,而不該像一些 壞決鬥者 邊打牌邊偷偷印卡。

……

閱讀全文


菜雞與物件導向 (1): 類別、物件

直覺上你當然知道什麼是物件;物件就在你的身邊。

汽車、iPhone、收音機、吐司機、廚房用具等等,你說得出來的都是。

  ——《深入淺出學會編寫程式》

什麼是物件?一切都是物件。

物件導向試圖讓抽象的程式碼,更貼近於我們的實際生活,其認為一切是由各式各樣的人事物互動所組成的,因此有了物件這個共通、最基本的概念。

假設現實世界存在一頭狗,叫做阿福。而我們想要在虛擬世界裡表達「有一隻叫做阿福的狗」這件事

這時候就要在系統裡有一個能代表「阿福(狗)」的東西存在,也就是「阿福」這個物件。

關於「把現實世界的物件,抽象化成程式世界裡的物件」的邏輯,可以參考 一個語言如果不改變你的思考方式,就不值得學?談程式語言的本質 這篇,尤其是選擇保留哪些資訊的部份我認為描述得很好。

現在我們知道,物件就是用來在虛擬世界中代表「某個特定的東西」,例如說叫做阿福的狗就是一個物件,阿福今天晚上要吃的飼料罐也是一個物件。

理解物件的概念是相當直覺且迅速的,畢竟你我身邊有著數不清的東西,它們都是一件一件的物件,但這樣的理解還不夠明確。

就像前文所引的 談程式語言的本質 文中所提到的,在抽象化的同時我們必然要選擇保留哪些資訊。

例如說阿福這隻狗,是一個物件;飼料罐也是一個物件

而這些物件之間還會彼此互動,例如說阿福是一隻狗,而我們觀察到狗都有吃東西這個動作,例如「阿福吃了飼料」

同時物件也會有一些專屬於它的特徵,例如說阿福是黑色的,我們就知道狗有毛色的差別。

那麼我們要怎麼表達「阿福」作為一隻「狗」擁有的那些動作和特徵呢?狗的毛色?狗可以吃飼料?

我們需要選擇怎麼去描述「狗」--也就是阿福這隻狗,被我們抽象化後的樣子,我們需要將它用程式碼的方式定義出來。

這時候我們就會需要類別,來定義出我們觀察到同一類的物件該有哪些特徵和動作,也就是我們替物件「分門別類」後、篩選出特定資訊的抽象化結果

延續前面的例子,假設今天我們從阿福身上觀察到進食跟毛色兩個狗的重要資訊,我們就可以建立類別 Dog:

public class Dog
{
    public string color;
    public void Eat(IFood food) { /* 進食與消化之類的 */ };
}

藉由我們定義的類別,就可以從類別中實例化(=建立)出物件。

也就是說,現在我們終於可以用「狗」這個類別,來表達出我們需要的「阿福」了:

Dog afu = new Dog(); // 阿福是一隻狗
Console.Write(afu.Color); // 阿福是黑色的
afu.Eat(food); // 阿福會吃食物
……

閱讀全文


菜雞與物件導向 (0): 前言

在訂便當告一段落之後,其實就已經和同事約好要來整理公司新訓的筆記。但儘管已經到職快一年了,有些工具已經在專案碰過好幾次。但遇到需要跟朋友討論,或是聽前輩說明觀念的時候,還是不自主地會想「我真的懂嗎?」故一直是挺畏懼的。

但幸虧同事的鼓勵和以身作則,最終還是開啟了這個新系列,決定直接開坑把當初前輩新訓指導過的部分整理下來,也算是讓自己能趁著這機會好好複習一番,把自己的想法跟心得記錄下來。

另外,如果你是真心希望弄懂物件導向的朋友,這邊推薦《大話設計模式》的附錄,內容對物件導向的介紹清晰易懂且循序漸進,非常適合作為了解物件導向的起頭。

本篇的段落將會分成以下幾個部份,由於只是筆記一下,因此會附上一些知識點的參考資料,看見的時候可以先行閱讀;末尾也會附上有關的參考資料及文章,對於這類概念性的東西,一向是推薦多方閱讀以增強理解,就像保哥寫的:「如果你問 100 個人這個問題,可能會得到 200 個答案,所以你一定要有自己獨到、有自信、精闢的見解或描述方式。」如果有寫得不錯的文章想推薦給我,或是有地方需要補充和指證,還請不吝指教。共勉之。

……

閱讀全文


AutoMapper —— 類別轉換超省力

類別間的轉換幾乎是每個專案每個工程師都會碰到的動作,舉凡是分層架構每層之間的轉換,如 Dto 轉換成 ViewModel;或是接收到資料要塞進自定義的類別時也需要進行轉換。但在遠古時代,當我們要把一個類別的資料倒進另一個類別時,總免不了一番折騰

例如一個卡片對戰遊戲的資料庫,光是要先把卡片資料讀取出來就需要:

有些時候也會看見用 Foreach 然後逐一傳值的場景,或是各種差不多的變種情況。同樣的是,光是將一個簡單的卡片資訊轉換成 ViewModel,就花了一大段在做對映的處理。這個過程本身枯燥乏味又占空間,更可怕的是,如果有個陳年資料表,動不動就上百個欄位,那這個轉換過程的恐怖程度可想而知

幸好!天無絕人之路,這種時候就是本日的主角 —— AutoMapper 出場的時候了。

當 AutoMapper 一出手,轉換的過程瞬間就變成:

是不是精簡很多呢?接著就讓我們來看看怎麼開始使用吧!

……

閱讀全文


Visual studio 環境設定 —— 字型、套件、快捷鍵

目標:整理一下自己用的字型、插件和快捷鍵

今天在工作時寫到一半突然藍屏,重開機之後俺的地表最強編譯器 Visual Studio 整個就開始鬧脾氣,打開專案整排都是 Error,連 System.Object 都找不到,差點往生。還好用了修復功能之後一切恢復正常,但是載入的插件和一些個人設定就這樣重置了……

為了之後可能還會遇到相同的事情,這邊就先將平常的 Visual Studio 環境用到的設定做一份紀錄,之後遇到新插件或是什麼功能也可以回來更新這篇文,如此一來下次又被洗白的時候就可以回來參考了。

這邊主要會記錄三個部分,並隨時可能更新。主要是字型、使用的插件以及常用的快捷鍵。

不過我的 Visual Studio 也被洗白了所以這篇會跟著找回失落插件的歷程慢慢補上QQ

字型

字型部分必定、絕對要使用等寬字型,這是必要的前提也是絕對的共識,畢竟你不會希望有什麼神秘空白,或是推個版就排版大炸裂之類的。

推薦先參閱 換個好字型讓程式開發有效率

(2021/1/27) 補充:字型也可以看 devfonts 。裡面直接放了超多 Coding 常用字型,也可以貼上 Code 直接進行比較,相當貼心。想逛一下挑個順眼字型的朋友直接試試唄。

Consolas

內建就有的字體,個人認為在不想另外下載字體的時候是相當優質的選擇。

看起來粗粗圓圓的很放鬆。

FiraCode

FiraCode,整體看起來就是乾淨優雅,尤其是連字能使得整個 Code 更有滑順的感覺,十分推薦。

然而,FiraCode 雖然陪伴我一段不短的時間,但還是有一個致命的缺陷:不支援中文!

於是後來我基本上都使用下面介紹的這款

更紗黑體

更紗黑體 除了同樣支援連字以外,更支援多國語系。例如繁中就是有標註 TC 的字形,看見中英文都套用上去就是一陣舒服。是現在我的主力。

至於不想用等寬字體的朋友,都看到這裡了,沒關係。下面這套推薦給你們

Ink Free

就是這麼直接!這麼舒服!如果你的同事要過來 Code Review,不要猶豫字體直接換下去!

……

閱讀全文