※ 引述《JYHuang (夏天到了，冷不起來了說)》之銘言： : Class Profile{ : private $db; : private $pic_path; : public $user_info; : public $user_id; : public function __construct($uid){ : $this->db = new db() // pdo; : $this->user_id = $uid; : $this->pic_path = path; : self::user_info(); : } : public user_info(){ : $sql = 'select * from user where uid='.$this->user_id'; : $this->user_info = $this->db->getrow($sql); : } : public get_pic($uid){ : $pic = $tihs->pic_path.$this->user_id.".jpg"; : if (!file_exitsts($pic)){ : if ($this->user_info->sex = 'male') : return 'boy.jpg'; : else : return 'girl.jpg'; : } : } : } : 一都會先 : $user = new Profile($uid); : echo "hello ".$user->user_info->name; : echo "<img src='".$user->get_pic."'>"; : 來取得使用者本身的資訊和圖片 : 後來想要取得其它使用者的圖片時 : 想直接呼叫來取得 : echo "<img src='".Profile::get_pic($uid)."'>"; : 這樣會有pic_path和user_info未被建構而無法取得的問題。 : 嗯.. : 這樣的話是要怎麼去架構整個class會比較好呢？ : 把pic跟profile切開用繼承的方式去寫嘛？ : 還是在get_pic裡做判斷再做建構？ 嗯…看來你想做的是 ORM， 有一個（還是該說兩個）很 lightweight 的 ORM/AR 框架你可以參考一下， http://j4mie.github.com/idiormandparis/ 在你情況裡，需要調整的可能不是「物件構造」去配合呼叫方法， 而是定型一個呼叫方法，然後統一物件構造。 一般實做 ORM 通常會單純的物件呼叫或走工廠模式， $user = new User ($uid); $user = Factory::Model ('User')->find_one ($uid); 如果你希望在原型呼叫下直接取值當然是可以，但物件結構就開始變得 dirty， 因為太多功能目的了，每個取值 method 都必需要實做這項，不然怎麼分辨 Profile::get_pic ($uid) 可以用，而 Profile::get_xxx ($uid) 不能用的原因在哪， 而且實際上物件還是產生並且佔用了資源，真正省到的僅僅是呼叫時少一行 code， Profile::get_pic ($uid) // 內部物件初始化後丟值回來 $prof = new Profile ($uid); // 外部初始化後拿到值 $prof->get_pic ($uid) 與其這樣，如果你目的是更快速/輕盈（省物件）去拿到使用者的某些特定資訊， 例如一堆使用者的 avatar list，還不如直接做 function 用 sql 來拉會比較好， 但缺點是 sql 會開始四散，維護上變得麻煩， 其實現在的物件資源佔用在 PHP 版本升上去過程中已經優化很多， 除非已經是高主機壓力覆載，要考慮整體優化作業， 不然不用太擔心 1 個和 20 個小物件的差別， 想想那些知名的 framework 都是多少個物件交疊在奔馳的… --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.136.54.205