推 JYHuang:嗯..其實我顧慮的也是你最後提到的~ 04/19 09:26
→ JYHuang:還有一點是想把所有avatar相關的method都用同個來源 04/19 09:27
→ JYHuang:這樣維護比較不會漏掉 04/19 09:27
※ 引述《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