2024-11-08 027_設計一個習題讓我思考 接口與抽象類
2024-11-08 027_設計一個習題讓我思考 接口與抽象類
設計一個習題讓我思考 接口與抽象類
好的,我來設計一個習題,讓你練習如何在接口和抽象類之間進行選擇和使用。這個例子將涵蓋一個「員工管理系統」,包括不同類型的員工(例如,正式員工和約聘員工),並涉及薪資計算的細節。
題目:員工管理系統
假設我們有一個公司,這裡的員工分為兩類:
- 正式員工:具有基礎工資、津貼等薪資結構。
- 約聘員工:根據工作時數來計算薪資,且沒有津貼。
每種員工類型都有一些共通的操作(如計算薪資、顯示基本資訊),但具體薪資計算方式各不相同。
步驟 1:設計接口 IEmployee
- 定義一個
IEmployee
接口,包含一個GetSalary()
方法,用來取得薪水。 - 添加一個
DisplayEmployeeInfo()
方法,用於顯示員工基本資訊。
步驟 2:設計抽象類 EmployeeBase
- 設計一個抽象類
EmployeeBase
,實現IEmployee
接口。 - 這個抽象類包含一個基本員工屬性
Name
和員工 ID。 - 讓
EmployeeBase
定義DisplayEmployeeInfo()
的共通邏輯(例如顯示姓名和 ID),但將GetSalary()
定義為抽象方法,由不同員工類型去實現。
步驟 3:創建具體員工類
- 為正式員工建立一個
PermanentEmployee
類別,繼承自EmployeeBase
,並實現GetSalary()
方法,包含基礎工資加上津貼的計算。 - 為約聘員工建立一個
ContractEmployee
類別,繼承自EmployeeBase
,並實現GetSalary()
方法,根據時薪和工作時數計算薪水。
練習目標
- 思考何時應該使用抽象類(
EmployeeBase
),何時應該使用接口(IEmployee
)。 - 理解如何分配共通功能與特定實現,並讓各類員工的薪資計算方式可以隨時調整而不影響其他部分。
提示程式碼
1 | public interface IEmployee |
練習思考
- 為什麼選擇將
EmployeeBase
設計為抽象類而非接口?在實務上,何時會用到這樣的抽象基類? - 假如以後需要添加新類型的員工(例如實習生),你會如何調整這個架構?
- 如果一個員工類型的薪資計算邏輯改變了(例如,約聘員工的時薪變動),這樣的設計是否能快速適應?