python — filter/ callable/ property
就在今天掌握了去年此刻覺得很難理解的概念，現在可以透過專案需求將這些功能實踐，為自己的成長感動與驕傲，以茲紀錄。
💡 目標: 設計一個元件，在別人需要拉取警告資訊的時候自己檢查內部保持的list有沒有超過10個，那10筆資料要確定是30秒內產生的， 同時要透出一個接口，讓router可以更新這個物件
router 每三秒會送一個警告進來，接到警告的同時產生timestemp
業務要求: 30秒內接收到10個警告就啟動報警開始將事件送上平台
我們要讓這個資料有自動檢查時間差的功能，超過30秒的資料要能夠自己丟掉
當我想到需要在取資料(get)的時候自動update最新，我馬上想到了property這個使用方式
使用property的 getter , setter 的方式進行資料的更新
而且有別於一般的在setter更新的思考想法，我採用在getter更新資料
因為有可能資料在觸動警報後就停止打上來，如此一來由於沒有append等更新行為，警報狀態不會消失，所以我採用在get資料的時候，檢查，並把檢查的結果透過setter的方式塞回內部參數中。
拼圖1: 採用__call__ 這個python的callable
這樣我可以把實例當作方法呼叫，就可以讓整個使用起來變得更簡單
sound_notifier = SoundPollutionNotifier()
- (原本) sound_notifier.sound_pollution
- (callable) sound_notifier() — — → True False
我們也就可以使用
拼圖2: 使用filter 或list表達式進行資料篩選
拼圖3: 研究property的使用
改成自己要的sound pollution notifier
_filter_out_dated 是我們的filter 大大
目標是將30秒以外的資料濾除掉，這裡使用abs(time difference) 與 deltatime 來實作
@property是我們的property區域，可以分別看到time_list的 getter 會將_time_list 進行 filter檢查後送進setter。 而{property_name}.setter會檢查資料需不需要更新的
另外sound_pollution的部分，會拿time_list的資料(這裡注意，這個time_list會在sound_pollution call的同時進行上述的filter檢查與更新，從而避免router那裡資料不再送過來，但是sound_pollution 仍舊一直保持無法關閉的情況)
最後則是我們的callable， callable 使用__call__定義，可以指定我們的class instance被直接呼叫的時候應該要怎麼回應，我在裡面就很簡單的檢查sound_pollution的情況，而sound_pollution又回頭更新time_list
測試用的code
最後裡面提到的callable其實是因應服務擴大之後需要的寫法，可以在專案的app層級去實例化不同的服務(這一次的sound pollution notifier 也可以當一個服務)。如果app底下的服務是會被不同的服務重複調用的，嵌套式的組合實例化就會有在服務很深層被呼叫的情況，專案擴大時，很多重要的pipeline就不可見，也不好分離，使用callable 將callable傳進別的服務就是一種很俐落的抽象。目前我也正在嘗試多實作這種寫法，有更進一步的資訊再跟各位大大分享
附上我的notion連結，medium不能多顏色hightlight 讓我在解釋不同元件的時候感覺有點抽象，我之後會再嘗試把這篇寫得更清楚一些
