[請益] 關於魔術方法 __set __get

看板PHP作者 (玥乂)時間7年前 (2017/03/12 22:05), 7年前編輯推噓7(7推 0噓 41→)
留言48則, 6人參與, 最新討論串1/1
我最近算是剛學php 在class的部份有個小問題， 我們在設定private 或是protected的變量時， 我們可以用public function 自己設定一個內部函數 去修改這類型的變量， 還有另一種方法是直接利用標題所說的 魔術方法 __set __get 去改變或是查看這個變量 我想問的是大家在操作這類變量 是使用那一種方法比較多呢？ 我是覺得魔術方法好像很好用， 但好像也有人說這方法不好？ 說這方法不能對特定變量做一些限制。 若是設定一種新的變量就寫一個 新的public function就沒這個問題。 但我看網路上 有人在 __set裡面寫個switch 不能個別對變量作限制的缺點好像就没了 //之前沒打functuon name 現在加回去 public function __set($name,$value){ switch($name){ case "$name" .......... break; } } 請問我有忽略什麼嗎？ 哪一種方法比較好比較常用呢？ ----- Sent from JPTT on my Xiaomi MI 5. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 119.14.168.131 ※ 文章網址: https://www.ptt.cc/bbs/PHP/M.1489327527.A.4A9.html
推
03/13 00:58, , 1F
你忽略了function name(X
03/13 00:58, 1F
→
03/13 10:43, , 2F
你有學過其他語言經驗嗎
03/13 10:43, 2F
→
03/13 11:35, , 3F
痾 c懂一點皮毛，所以用魔術方法真的會有什麼嚴重的問題
03/13 11:35, 3F
→
03/13 11:35, , 4F
嗎？
03/13 11:35, 4F
※ 編輯: nono5938 (119.14.168.131), 03/13/2017 11:36:59 ※ 編輯: nono5938 (119.14.168.131), 03/13/2017 11:37:38
推
03/13 12:30, , 5F
魔術方法的好處是你連單純的 get/set 都能用程式控制
03/13 12:30, 5F
→
03/13 12:30, , 6F
例如你有複雜的白名單機制，或是你內部存資料的方式跟外部
03/13 12:30, 6F
→
03/13 12:31, , 7F
介面不一樣，或是你需要對於 set 進來的東西加料，然後不
03/13 12:31, 7F
→
03/13 12:31, , 8F
想寫同樣的東西寫個五十次之類的
03/13 12:31, 8F
→
03/13 12:31, , 9F
有這種需求的話，就用吧。反過來就是沒這種需求就少用
03/13 12:31, 9F
→
03/13 12:31, , 10F
當然拿來實驗或把玩是沒問題的
03/13 12:31, 10F
→
03/13 12:32, , 11F
這東西有兩個缺點：code 可以變得很難 trace（看你怎麼寫
03/13 12:32, 11F
→
03/13 12:32, , 12F
然後有效能 overhead。當然大部分情況那個 overhead 還好
03/13 12:32, 12F
→
03/13 12:33, , 13F
但是有個很多人在用的東西被 magic function 搞到肥慢慢
03/13 12:33, 13F
→
03/13 12:33, , 14F
該死的 laravel...
03/13 12:33, 14F
→
03/13 12:34, , 15F
一般物件導向語言教材都會先教getProp()/setProp()
03/13 12:34, 15F
→
03/13 12:35, , 16F
你有幾個prop就寫幾組
03/13 12:35, 16F
→
03/13 12:37, , 17F
一般也建議先習慣這樣 再用get/set這種動態語言的作法
03/13 12:37, 17F
→
03/13 12:39, , 18F
在初學階段最好不要急著想怎麼節省程式碼篇幅
03/13 12:39, 18F
推
03/13 18:58, , 19F
我倒覺得初學試一下也不算壞事，試一下「喔喔喔喔好強」
03/13 18:58, 19F
→
03/13 18:58, , 20F
然後兩個月後「靠北這段 code 到底在跑三小」也是種體驗
03/13 18:58, 20F
→
03/13 18:58, , 21F
而且悟性好的人搞不好就摸出順眼的用法了
03/13 18:58, 21F
→
03/13 18:59, , 22F
只要不像是 laravel 一樣什麼都要過一次 magic 然後速度
03/13 18:59, 22F
→
03/13 19:00, , 23F
也讓人感覺很 magic....（對我就是吃 slim 這一套 =v=）
03/13 19:00, 23F
→
03/13 21:26, , 24F
trace好像確實是個問題，但效能overhead是？不太明白怎
03/13 21:26, 24F
→
03/13 21:26, , 25F
麼會overhead有個什麼例子嗎？
03/13 21:26, 25F
→
03/14 09:46, , 26F
進去method裏面再switch 跟要改哪個prop就叫哪個method
03/14 09:46, 26F
→
03/14 09:47, , 27F
用聞的也知道是前面overhead比較多
03/14 09:47, 27F
→
03/14 09:47, , 28F
當然現在php改良很多 是可以試一試
03/14 09:47, 28F
推
03/14 11:19, , 29F
https://goo.gl/kljGuw 範例。裡面的數字是 PHP7，PHP5 會
03/14 11:19, 29F
→
03/14 11:19, , 30F
再慢個幾倍。基本上是個平常用兩下沒問題，但是被放到
03/14 11:19, 30F
→
03/14 11:19, , 31F
大迴圈裡面會有感覺的程度
03/14 11:19, 31F
推
03/14 11:25, , 32F
PHP裡面New物件跟call function跟magic function都是相對
03/14 11:25, 32F
→
03/14 11:25, , 33F
昂貴的存在，比較過分的就像Laravel的ORM，對上千個物件
03/14 11:25, 33F
→
03/14 11:26, , 34F
做操作就明顯感到慢，我對這個怨氣很重 :/
03/14 11:26, 34F
→
03/14 11:27, , 35F
當然能升級PHP7的話，升級可以解決很～多效能問題。
03/14 11:27, 35F
→
03/14 11:27, , 36F
但是實際工作很容易看到升不上7的code，還是得注意
03/14 11:27, 36F
→
03/14 13:07, , 37F
最近看到的例子以5.3為主 老到5.1都有 X(
03/14 13:07, 37F
→
03/14 14:06, , 38F
好吧 多個switch好像是真的會影響到處理的進程，我大概
03/14 14:06, 38F
→
03/14 14:06, , 39F
瞭解優缺點了謝謝大家
03/14 14:06, 39F
推
03/14 14:07, , 40F
這麼慘，那有機會碰到十倍效能差距...
03/14 14:07, 40F
→
03/14 14:08, , 41F
我是覺得還是可以玩看看，畢竟用的好的時候可以做出超漂亮
03/14 14:08, 41F
→
03/14 14:08, , 42F
的介面...
03/14 14:08, 42F
→
03/16 02:32, , 43F
額外小提醒，在台灣請使用「變數」而不是「變量」這詞。
03/16 02:32, 43F
→
03/16 13:19, , 44F
有點被同化了 我是在youtube看一個大陸的影片學的QQ
03/16 13:19, 44F
→
03/22 20:29, , 45F
Laravel 裡面用的 reflection 應該也拖了不少速度吧？
03/22 20:29, 45F
推
03/24 11:05, , 46F
Laravel 裡面做的能拖慢速度的黑魔法可多了...
03/24 11:05, 46F
→
03/24 11:07, , 47F
量很大才會痛就是了，一天一兩千人的程度不太有感覺
03/24 11:07, 47F
→
03/24 11:07, , 48F
我是背景要處理大量資料的工作用了Elquent ORM...好慢....
03/24 11:07, 48F
‣ 更多 nono5938 的文章
文章代碼(AID): #1OnLMdIf (PHP)