अंगूठे का सरल नियम:यदि कोई वर्ग 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
बीच में दोनों के बीच बातचीत होती है।