【Docker系列】 介紹 Docker 安裝 Docker 介紹 Docker 重要元素 Docker Images 操作指令 Build a suitale Image by DockerFile 使用 DockerFile 建置 Tomcat + MySQL 環境 Docker Container 操作指令 Docker 容器效能調整與Image匯入匯出 Docker Compose

前言 在生活中，一定都有遇過目的一樣，但過程總會有些許不同的事情。 以買菜這件事情而言，去傳統市場買？去零售超市買？去量販店買？都是買菜，但是過程卻可能不同。 傳統市場和零售超市可能在家附近，量販店可能就要驅車前往。而在價格部份則可能量販店較便宜。 類同上述目的相同、過程不同的事情百百種。程式設計也相同，若完成需求的程式邏輯簡單，那真的也不需要參考設計模式的方式設計，但工程師們就是專門處理複雜問題，化繁為簡的職業。你面對的問題絕不簡單，你必須要學會可以正確切分程式邏輯的設計模式。 今天要介紹的就是 Strategy Pattern

前言 工程師或多或少都曾經遇過因應服務的擴展，必須要增加輸入參數的情況。 今天接到要做一杯紅茶的需求? 好的沒問題! 建一個方法，只需要輸入茶包、冰塊、甜度三種參數，這樣不僅紅茶，連其他茶飲都可以一併完成。 過幾天接到飲品要有額外添加料的需求? 也沒問題! 在上述方法中增加一個新的參數，這參數會帶入要增加那些添加料的資訊，需求完成。 又過了幾天，飲品要分成大、中、小杯裝...?

前言 你是否曾經遇過辛辛苦苦開發了一個不錯的程式包，卻因為一點點的差異導致無法被重複應用。 這個差異可能是 5%、10%、20% 左右，但卻造成了整包東西無法被再次使用、整合的情境。 今天在專案中引用一個 A 服務，隔天被告知要更換成 B 服務，幾周後又要改成 C 服務，而來自 A B C 的服務本身或多或少都有差異，造成每一次的改變都必須更動到原本的程式邏輯才能完美契合。 但對於程式碼的維護來說卻是糟糕的處理方式，每一次的更正都必須要跑一次測試。 這就像過去有許許多多不同規格的電線插頭一樣，為了不同的插頭而去更換機械部件的插座，非常不符合效益。

【前言】 繼承 (Inherit) 抽象 (Abstract) 介面 (Interface) 三個在 Java 中非常常見的名詞，到底你真的懂他們存在的用意與用途嗎? 什麼是繼承? 簡單來說，它是一個承上啟下的動作，使得繼承的物件可以擁有被繼承物件的方法與特性。

【前言】 你不常聽到這個詞，但你一定常常在使用例如 String 等物件，而 String 正是一種 Immutable Object 為什麼有這種類? 為什麼需要這種類? 使用在系統內有什麼好處? 文中將會逐步介紹，並給出解釋 【介紹】

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 鈴木一郎 :::info 我的準備工作，就是排除任何會成為藉口的因素。 ::: 主題 Factory Method 上篇文章提到了 Open Close Principle 後，來談談常被提起一併討論的 Factory Method

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 名句 Steven Paul Jobs :::info We don’t get a chance to do that many things, and every one should be really excellent. ::: 主題 今天來跟大家分享處理 LogBack 部分

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 賦得古原草送别 白居易 :::info 離離原上草，一歲一枯榮。 野火燒不盡，春風吹又生。 遠芳侵古道，晴翠接荒城。 又送王孫去，萋萋滿別情。 :::

前言 身為工程師的你，是不是偶爾會面對到以下幾種狀況? 需要一個相同的物件來執行事務上的處理，且不能透過 new，因為須要當前物件狀態。 正在跑 Loop 建立大量、相同的物件，差異僅在物件中的屬性值，但建立物件的過程涉及了十幾道工。 曾經的作法就是暴力重建、暴力複製、富含耐心的等待... 結果好死不死發現物件中有些屬性是 Private 無法進行暴力複製；或者僅知道介面，無法找到想複製的實體類別物件...欲哭無淚。

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== Florence Nightingale :::info I attribute my success to this - I never gave or took any excuse. ::: 前言 正如我先前所說，接下來的文章會不定主題的更新 Design Pattern、Algorithm 的學習心得，甚至最近因為工作上專案的關係，又學到了如何做 SpringBoot JPA 的 Multi-DB connection 的皮毛，都很想盡快有個時間可以分享給大家... (加班Loop ORZ)。

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 王雪红 :::info 要成功，就得做最困難的事 ::: 前引 是否覺得有些時候不是那麼需要使用繼承的方式處理類方法的取用? 是否覺得能夠分開類後再組合一起遠比繼承簡單明瞭?

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 張忠謀 :::info 我工作，所以我存在 ::: 前引 在前幾篇文章講述了不少關於 Interface 的設計原則後，這次來講講實體類別之間的處理。

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 義彥 (勇者義彥) :::info 我是肩負拯救世界的勇者 義彥 ::: 前引 上篇介紹了 Single Responsibility Principle，主要在於當功能複雜性超出其原先對於該類別的預期時，則應將可區分的功能再切割出去的動作。

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 半澤直樹 (日劇:半澤直樹) :::info 重要的不是在哪工作，而是如何去工作 ::: 前引 寫程式的時候常會有人說：「要把功能模組化拆開」、「東西不要都放在一個 class」、「同個功能不同對象就不能寫進同一個程式中」。

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== Jeanne d'Arc :::info I am not afraid. I was born to do this. ::: 主題 在上次提到了 Liskov Substitution Principle 後，來分享另外一個對於 Open Close Principle 也是影響重大的原則 -- Dependence Inversion Principle

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 曹操 孟德 :::info 老驥伏櫪，志在千里。 烈士暮年，壯心不已。 ::: 主題 今天要介紹的設計原則是 Liskov Substitution Principle，又簡稱 LSP，中文常見名稱 替換原則 (里氏替換原則)

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 魏德聖 :::info 我創造一個機會給自己，然後我賭我自己。 ::: 前言 最近暫且想放下 Java 方面的學習，轉往比較基本的方面去探討，因此接下來應該會有一系列關於 Design Pattern 和 演算法的學習分享~

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai== 劇中佳句 LIFE OF PI :::info The most important thing is not to despair. ::: 主題 - Optional 類別 Java 工程師在開發程式邏輯時，最惱人也是最容易忽略的便是傳值過程中發生的 NullPointerException

【前言】 最近開始看 Clean Code 了，接下來會做關於書中內容的心得與個人經驗整理的分享文。 【主文】 上一篇講述了命名的部分，這一篇來講關於函式，函式是構成功能的最小單位，一個一個的函式組成可以確立許多不同的業務邏輯，因此函式本身的程式長短與規劃，占了舉足輕重的地位。 【書中的大道至簡】 行數的簡化 首先講求的便是越少的程式碼，讓開發人員相對的越好閱讀和理解，因此能夠減少不必要的物件、重複邏輯、甚至是多功用的設計等，都可以簡潔單個函式的整體。