अंगूठे का सरल नियम:यदि कोई वर्ग extends दूसरा, तो वह वर्ग है वह मूल वर्ग (केवल थोड़ा बदला या विस्तारित)। आप इस चाइल्ड क्लास को पैरेंट क्लास के बजाय पास कर सकते हैं। उदाहरण:
class Foo { }
class Bar extends Foo { }
function baz(Foo $foo) { }
baz(new Bar);
यह काम करता है, baz() एक Foo की अपेक्षा करता है लेकिन एक Bar भी स्वीकार करता है , क्योंकि Bar है एक Foo ।
अब, है आपके Users एक Database ? नहीं। आपके उपयोगकर्ता डेटाबेस नहीं हैं। आपके उपयोगकर्ता उपयोग एक डेटाबेस। यदि बिल्कुल भी, आपको रचना . का उपयोग करना चाहिए :
class User {
protected $database;
public function __construct(Database $database) {
$this->database = $database;
}
}
एक वर्ग होना चाहिए इसकी जिम्मेदारियां क्या हैं हैं . उपयोगकर्ता प्रबंधन वर्ग की जिम्मेदारी उपयोगकर्ता डेटा का प्रबंधन करना है। इसके एक हिस्से में डेटाबेस से बात करना शामिल हो सकता है, लेकिन इसका मतलब यह नहीं है कि उपयोगकर्ता प्रबंधन वर्ग है एक डेटाबेस। यदि User extends Database , इसका मतलब है कि यह सब कुछ कर सकता है Database कक्षा (और अधिक) कर सकती है। इसका मतलब है कि आप Users . का उपयोग कर सकते हैं कक्षा हर जगह बजाय Database वर्ग, और इसका कोई मतलब नहीं है। जिम्मेदारियों को अलग रखें।
अब, यह अभी भी बहस का विषय है कि यह सही संरचना है या नहीं, लेकिन यह सही दिशा में जाता है। लेकिन हो सकता है कि आप वास्तव में Users रखना चाहें वर्ग, जो एक उपयोगकर्ता . का प्रतिनिधित्व करता है . फिर आपके पास एक UserManager होता है या UserORM या UserStorage या जो भी हो, जो Users . को पुनः प्राप्त करने और संग्रहीत करने से संबंधित है डेटाबेस में ऑब्जेक्ट। यह वर्ग बदले में उपयोग करता है एक Database बस ऐसा करने के लिए। यह जिम्मेदारियों को स्पष्ट और अलग रखता है। Users वर्ग उपयोगकर्ता डेटा का प्रतिनिधित्व करता है, Database वर्ग डेटाबेस के साथ इंटरैक्ट करता है, UserORM/Manager/whatever बीच में दोनों के बीच बातचीत होती है।