今天從同事們那邊學到了書籤這個方便功能，趁還記得的時候來做個紀錄。

那麼馬上就來操作一次：

使用 Ctrl K, Ctrl K 可以在指定的行號上加上一個「書籤」

隨著 2020 進到了 2021，菜雞與物件導向也推進到了五大原則結束，可以暫時告一段落了。

最初和朋友約好了要把公司新訓學到的東西做個整理（廣告一下他的部落格：Sian），只是沒想到因為太常發廢文偷懶，大半年才推進到物件導向的基礎而已，甚至占不到新訓內容的十分之一。希望 2021 能繼續推進，把這部份的坑給填一填，然後把前面的文章也重構一下，只是按照我的個性，可能又會忍不住開新的坑吧，哈哈。

至於物件導向相關的心得和紀錄，也就是這個系列，偶而有想到或是有所體悟的時候再發上來吧，暫時想先把前面隨手寫凌亂文章給整一整先。在這個十幾篇的短系列，記錄了從類別與物件開始，到耦合、內聚及五大原則，每個主題的心得。這邊稍微做個小整理：

類別、物件

• 物件就是用來表達「我們知道的某個東西」，物件導向是用物件彼此互動的方式來建立架構
• 類別去定義我們要的物件有什麼特徵、有什麼功能，再從類別中實例化（也就是根據設計圖產生）物件出來使用

建構式、多載

• 建構式用來在建立物件時就進行一些我們想要的操作，例如狗狗的毛色等等天生的東西，或是這個建立這個物件的必須素材
• 多載指的就是可以有很多個同樣名字的方法，各自去接不同的參數，讓同個目標的函式可以根據傳入的參數不同做不一樣的處理

在上一篇我們紀錄了依賴反轉原則，到此五大原則介紹完畢…是這樣嗎？太天真了！就像四天王總是五個人一樣，五大原則當然也有第六個！

今天的主角就是五大原則中Ｌ位的第一候補：最少知識原則，也被稱作迪米特法則。

最少知識原則 (Least Knowledge Principle)

只和直接的朋友溝通，不和陌生人說話

那麼所謂的朋友是什麼呢？就是指這個物件或方法有直接相關的物件啦。例如當我們使用一個方法時，這個方法應該只認識：

• 該方法所屬的類別
• 該方法所接收的參數
• 該方法中建立的類別
• 該方法所屬的類別所依賴的對象

除此之外對這個方法而言都是陌生人。什麼情況會遇到陌生人呢？有一個蠻常遇到的狀況就符合定義：當我們使用依賴對象的方法，該方法給了我們另一個類別時，我們就正在接觸毫無關係的陌生人。

在聊依賴反轉之前，先讓我們聊聊什麼是依賴，所謂的依賴就是一種「受到某個東西影響、牽制」的狀態。

例如說如果有個像我一樣的肥宅每天一定要來一片雞排才能療癒身心，那我就是依賴雞排；
同樣的，如果有個大叔不抽菸就會全身不舒服，就是對香菸有所依賴。

當有「必須要藉由某個人事物來達到目的」的狀況時，就是依賴。

而在程式設計裡面的概念也差不多，如果Ａ模組直接受到Ｂ模組的影響，我們就稱Ａ依賴了Ｂ，最明顯的狀況就是Ａ模組需要藉由Ｂ模組的實例來完成某個功能的時候。

例如「匯出報表」功能建立了一個「Excel 控制類別」的實例以建立檔案；
或是「會員查詢」功能建立了一個「DB 連線」的實例來進入資料庫取得會員資料

遇見這種「必須要藉由某個模組的實例來完成想要的動作」的狀況時，就是依賴。

依賴與耦合

我們在之前的 耦合篇 提過，如果模組和另一個模組之間有關連，那這兩者之間就耦合。以此來看，依賴就是一種耦合的關係，那麼，依賴是健康還是不健康的耦合呢？

現在讓我們用 多型篇 用過的「老闆徵工程師」的例子來舉例一下：現在有間小小公司，老闆請來了小明當工程師，並請他開工撰寫產品程式碼。

當「撰寫產品程式」對「工程師」直接依賴的時候，狀況可能是這樣的：

public Product Work()
{
    Ming programmer = new Ming();
    var product = programmer.Programming();
    return product;
}

過一陣子，老闆發現小明寫出來的東西似乎不太行，於是把小明趕走，另外請了小華。這時候因為「工程師」這個實作類別不一樣了，我們就必須要改一次程式碼：

public Product Work()
{
    Hua programmer = new Hua();
    var product = programmer.Programming();
    return product;
}

故事是這樣的——

Win10 工作列的合併設定有這些選項：

當選擇「一律、隱藏標籤」時，工作列上同樣的程式就會摺疊起來：

而「永不」和「當工作列滿時」則會將工作列展開：

好的，那麼像我個性這麼麻煩的人，如果覺得顯示名字很佔位置，可是又不想要摺疊之後按兩次才能打開我要的應用程式，偏偏又很愛開一整排 IDE 的話，有沒有什麼簡單的辦法不要讓圖示合併，但也不要顯示名字呢？

如果有個小工具，可以讓這些工作列的設定更彈性就好了，會有嗎？

無論喜不喜歡自己的工作，都應該好好思考自己和工作的關係，畢竟每天花三分之一的時間做這件事，如果和它處得不好，人生也不可能會變好。

這本書並不是那種精神勝利法，又或是超猛接案全攻略之類的書；反而給我的感覺比較像是作者藉著這本書，分享他這一路摸索的心得，和遭遇到的一些困難，看的時候有種像在和作者聊聊天的感覺。

也因為這本書比較接近作者分享他選擇的道路、內容比較廣雜，遇到的部分都稍微說一些，但不是那種針對某個議題深入探討的書籍，所以比較適合想稍微了解自由工作的朋友閱讀。同時也必須了解到，自由工作者也只是眾多職業道路的其中一種，每個人的條件也不盡相同，因此抱持著好奇的心情閱讀，會更有收穫的感覺。

從 博客來 的書籍簡介就可以看到，目錄真的把自由工作遇到的議題都碰了一些：從適不適合接案工作，到報稅、勞保、合約、工作場所都聊了一點。因為真的挺廣的，這邊我就只記錄一些我比較感興趣的話題。

最近遇到在 Amazon Linux AMI 要安裝 .net Core 3.1 環境的時候，會一直跳出
Requires: openssl-libs 而無法安裝的問題，儘管明明已經有 openssl 了，但還是解析失敗找不到依賴，過程一直碰壁，因此在這邊紀錄一下。

過程中嘗試了安裝 openssl-libs（會找不到該套件）、下載 Dotnet 的 tar.gz ，再直接對執行檔下 Dotnet 指令起站台（雖然網站起得來，但執行者會是當下的登入身分，也就是 ‘’@連線進來的IP-伺服器位置，而非由本機執行。後續如果有連線資料庫等檢查權限的地方就很容易出錯）

最後在 Dotnet Core 的 issue 翻到這篇 Cannot install .NET Core 2.0 on Amazon Linux AMI 才成功解決。

首先先將 openssl-libs 的 SPEC 抓下來，然後給 RPM 建置一下。這兩句可以參考一下這篇 RPM 打包︰由一竅不通到動手濫用 (二) 的說明。

wget https://github.com/dotnet/core/files/2186067/openssl-libs-ami.spec.txt
rpmbuild --bb openssl-libs-ami.spec.txt

今天要記錄的是介面隔離原則，顧名思義是和介面高度相關的原則。因此在閱讀本篇之前，可能需要先對 介面 有一點了解呦。

事情就從上一篇 里氏替換原則 的鳥類物流公司開始說起。老闆痛定思痛，決定先用介面先規定好物流士們的應徵條件，例如裝貨、卸貨、飛行、必須有帥氣的喙等等。

這道命令下來後，倉庫們的企鵝都慌了，來檢查的編譯器瘋狂跳出 Error:「您未實作 IBird 的 Fly() 方法！」這下怎麼辦呢，為了要保住飯碗，企鵝們就必須實作出飛行才行，可是企鵝真的就不會飛呀！

這下子企鵝們只剩下兩個選擇：不實作飛行，但是就不能被當成物流士，最後就會被開除；或是……空實作。

public class Penguin : IBird
{
    public void Fly()
    {
      // Do nothing;
    }
}

企鵝們終於騙過了編譯器檢查員，然而當送貨的命令下來之後，企鵝們再一次卡在倉庫門口發呆，最終物流公司仍然踏上了虧損的老路，再度面臨倒閉危機…

不能信任那些 Terminal 或編輯器用白底的人。
—— JokeKappa

這禮拜推薦了個常用的 chrome 套件給同樣喜歡黑色背景的同事，這邊也推薦給大家。

絕對不是因為隻狼更新了不小心砍太爽，結果來不及寫介面隔離只能介紹套件水一下，Heiya～

今天要介紹的就是這款 Dark Reader，這是我用 chrome 時首選的暗黑模式擴充套件，在俺寫文的這時候已經超過了三百萬次的下載次數，現在就讓我來記錄一下這款擴充套件的一些特色唄。

里氏替換原則 (Liskov Substitution Principle)

子類別必須能夠替換父類別

里氏原則還包含了一個概念：子類別替換父類別後，不需要改變，也不會發生任何錯誤或異常。

從定義就可以看出來，這項原則是來替我們處理繼承問題的。因此，在開始本篇之前，可能需要先對 繼承 以及 多型 有基本的認識。如果可以的話，也請先看過 介面。

那麼，就讓我們從很久很久以前開始說起…

我的子類別進入叛逆期了，怎麼辦？

很久很久以前，有一間公司受到 鴿子封包 所啟發，打算發展鳥類運輸技術，強勢打入無人機市場，用生物智慧掀起對人工智慧的革命。既然鳥類都會飛行，理所當然可以藉由飛行來進行空運，甚至還可以偷偷擊墜那些無人機對手，野心勃勃的老闆立馬徵了一批鳥類物流士，打出「凡是鳥類都可應徵」的旗號，各式各樣的猛禽響應而來，一時之間掀起整個物流業的風暴！

但是好景不常，公司營運之後發貨狀況不佳，頻繁發生丟包問題，甚至有些貨根本就出不了倉庫，虧損越來越大，心急如焚的老闆下令徹查，這才發現—