Re: [問題] Class中有關input的疑問
※ 引述《jasonhsu14 (14號星期五的傑森)》之銘言:
: H1=Human1()
: print(H1.BMI())得到當初創建類別時的預設或輸入的數字
: print(H1.BMI(170,80))時,得到不一樣的結果
: 有想過直接在 def BMI(self, h=160, w=50)這樣去寫
: 但這樣又等於重複做了跟__init__一樣的事情
: 所以想詢問有無辦法讓BMI變成一個
: 不輸入的話就會根據最一開始創建類別的預設(或輸入)數值
: 但也可以讓BMI自己另外輸入想要的數字
忽然覺得想說的多了點,還是回文好了。雖然推文給了一個回答,但我覺得最好
還是從概念上來處理這個問題。
H1.BMI()
這寫法很直覺,就是得到H1這個實體本身的BMI,沒有問題。但是:
H1.BMI(170, 80)
請問你覺得這是什麼概念呢?叫H1這個人幫你算算170/80的人BMI是多少?
你可以發現,這兩個用法的概念是衝突的。前者把H1當作一個有BMI的實體,後
者卻只是一個計算BMI的計算器。
那麼我的建議是,應該把實體跟計算器的角色分開來。這個計算器誰來負責呢?
我認為是Human1 class本身,把計算方法定義成Human1的一個靜態方法。當我們要計
算任意一組資料的BMI時,我們呼叫:
Human1.cal_BMI(170, 80)
這個cal_BMI()可以定義為:
@classmethod
def cal_BMI(cls, h, w):
# 計算並return BMI
當我們要得知一個實體H1本身的BMI時,我們呼叫:
H1.BMI()
而這個BMI()則定義為:
def BMI(self):
return Human1.cal_BMI(self.h, self.w)
這樣,我們就既不需要在兩處處理default值(__init__跟BMI),也兼顧了code
的重用性,同時讓實體跟class本體的角色更明確。同時,也不需要寫煩人的邏輯來
判斷輸入值是什麼情況、要用內部值或外部值等等。
BMI要修改計算方式,我們只需要改動cal_BMI(),除非引入了其他參數或要改變
實體與類的計算連接方式(比如說,公開測量時的cal_BMI都是很公正的,但是要讓
每個人自報BMI時都故意低報一點,就像NBA球員偷偷高報身高XD)才會動到BMI()。
--
「可是妳......不是天使嗎?」
「天使?」她緩緩的轉過頭來,用悲傷的表情。「天使,只不過是神創造出來的
不死玩偶。」
「而神,也只不過是詛咒下的偽善使者。」
--星.幻.夢的傳說
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.248.150.42 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Python/M.1587015592.A.42B.html
※ 編輯: ddavid (111.248.150.42 臺灣), 04/16/2020 13:43:12
推
04/16 13:46,
4年前
, 1F
04/16 13:46, 1F
→
04/16 13:53,
4年前
, 2F
04/16 13:53, 2F
推
04/16 15:32,
4年前
, 3F
04/16 15:32, 3F
推
04/16 15:43,
4年前
, 4F
04/16 15:43, 4F
推
04/17 20:03,
4年前
, 5F
04/17 20:03, 5F
推
04/19 16:40,
4年前
, 6F
04/19 16:40, 6F
我認為選擇 Human1.cal_BMI 比較好。概念上也就是說,這邊是每個人都依循這
個人類定義的標準計算方式給出BMI,他們不是「每個人用自己的方式計算」,所以
call的是類別靜態版本較符合這概念。
單從程式語言寫作而言也是建議如此做,即便Python確實可以讓你透過實體去呼
叫靜態方法。
※ 編輯: ddavid (114.36.173.238 臺灣), 04/19/2020 19:52:12
→
04/19 23:32,
4年前
, 7F
04/19 23:32, 7F
→
04/19 23:32,
4年前
, 8F
04/19 23:32, 8F
→
04/19 23:32,
4年前
, 9F
04/19 23:32, 9F
→
04/19 23:33,
4年前
, 10F
04/19 23:33, 10F
→
04/19 23:33,
4年前
, 11F
04/19 23:33, 11F
→
04/19 23:33,
4年前
, 12F
04/19 23:33, 12F
→
04/19 23:33,
4年前
, 13F
04/19 23:33, 13F
→
04/19 23:34,
4年前
, 14F
04/19 23:34, 14F
其實我確實是有想過一些不同使用情境或未來擴展會導致應該使用不同設計的情
況。
不過我認為就這個例子可以單純化,所以就只給了基本的簡單設計。
基本上我認為與其過度設計不如等用到了再refactoring,工作上有深刻體驗。
所以事實上在原Po一開始那篇直接硬用if解決的方式,也未必有什麼不好。
至於你提到@staticmethod來取代@classmethod,你是對的。我不是為了擴展性
,只是直覺用了@classmethod,但其實這邊沒有必要使用cls,所以@staticmethod確
實比較好XD
※ 編輯: ddavid (1.160.87.162 臺灣), 04/20/2020 12:46:07
推
04/20 15:21,
4年前
, 15F
04/20 15:21, 15F
推
04/20 22:35,
4年前
, 16F
04/20 22:35, 16F
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 2 之 2 篇):