# 六角鼠年鐵人賽 Week 32 - Design Pattern - Open Close Principle

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai==

## 魏德聖
:::info
我創造一個機會給自己，然後我賭我自己。
:::

## 前言
最近暫且想放下 Java 方面的學習，轉往比較基本的方面去探討，因此接下來應該會有一系列關於 Design Pattern 和 演算法的學習分享~

藉由文章的方式，希望用自己的心得幫助讀者可以用簡單的方式了解那些不熟悉的部分。

## 主題 Open Close Priciple
中文常見名稱 **開閉原則**

在 1988 年由 **Bertrand Meyer** 在 ***Object Oriented Software Construction*** 一書中提及：
Open Close Principle: Software entities should be open for extension，but closed for modification. (軟體實體應保持擴展彈性，但關閉對其內部方法進行修正)

## 原則說明
當應用面的需求改變時，在不修正程式碼的狀況下，透過替換實體的方式，滿足應用面需求。大量的實體供替換，以此達到快速擴展功能的目的。

## 架構
- 抽象、介面等接口物件
- 繼承實作的類別實體


## 目的
1. 僅須對新擴展的實體進行測試，不須測試舊實體，節省測試環節
2. 減少接口物件的維護作業
3. 提高程式碼的重複可用性
4. 擴展彈性增加需求實現的速度

## 心得分享
這應該是最基本的設計模式了，相信在許多系統中都有應用。

上面架構中使用了 Car 這個當作 Abstract/Interface 接口物件，底下則是繼承其類別的實作類別：BMW、TESLA。

當我們有了這些實體類之後，未來我們在 Car Service 中僅需針對需要的條件給出適當的實體類別即可。

剩下引用的業務邏輯完全不需要更動。即 c.info() 這句。

Open Close Principle 為的就是將重複性同類的實體進行整理，並針對需求的部份給出適當的實體進行內部方法的呼叫。

該原則的優勢就在於，當縱向沒有太多改變的時候，橫向擴展的實體可以開發的非常快速，且維護上很方便。

但當縱向有變化的情況下，就要審慎評估是否要針對接口物件更動內容，畢竟每次更動都會需要針對所有實體進行變動。

這在未來有其他更適合的設計模式可以避免這種狀況發生。

:::danger
最近個人的時間比較緊迫，無法繼續原先的進度，但仍會安排一些必要的進修，例如: Kafka 等 MessageQueue 的學習。

也希望各位會喜歡近期分享的 Design Pattern 和 演算法的學習了~

Kai 在這裡也請大家不吝賜教!
[六角鼠年鐵人賽 Week 33 - Design Pattern - Factory Method](/NEDvd8GHTvaCs7gutW9bPA)
:::

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Design Pattern`,`w3HexSchool`