प्रश्नों की संख्या को कम करने का सबसे अच्छा तरीका क्या है जब क्लास डीएओ के पास समान परिणाम का उपयोग करने वाले तरीके हैं?

यह प्रतिक्रिया वर्तमान क्वेरी संरचना पर निर्भर है, जहां कोई शर्त नहीं है

class CategoriaDAO extends PDOConnectionFactory
{
    /*DB Connection, static member since you only need one connection*/
    private static $dbConnection;

    /*Sql result set, static since there is not conditonal and only a single table used*/
    private static $resultSet;

    private static function getConnection()
    {
            /*Connect to mysql db, set CategoriaDAO::dbConnection; */
    }

    private static function populateResultSet()
    {
            /*Run query and populate resultSet - either as sql result or parse to array - your call*/
    }
    /**
     *
     * @var PDO $conn 
     */
    private $conn;

    public function __construct()
    {
                /*Get sql connection if one hasn't already been established*/
                if(!CategoriaDAO::dbConnection)
                        $this->conn = PDOConnectionFactory::getConnection();
    }
}

इसके पीछे विचार प्रक्रिया यह है कि चूंकि परिणाम हमेशा समान होंगे (अभी के लिए अनदेखा करें, अपडेट करें, सम्मिलित करें, हटाएं) प्रत्येक ऑब्जेक्ट में परिणामों की एक प्रति रखने की कोई आवश्यकता नहीं है।

जैसा कि आपने बताया कि टेबल अपडेट ऑब्जेक्ट के साथ सिंक से सेट किए गए संग्रहीत परिणाम को दस्तक देंगे; यह वह जगह है जहां मैं थोड़ा पीछे ट्रैक करना चाहता हूं और कहता हूं कि यदि किसी दिए गए ऑब्जेक्ट के लिए सेट परिणाम केवल सृजन के समय अद्यतित होना है तो सामान्य ऑब्जेक्ट सदस्यों का उपयोग करें।

स्वतंत्र रूप से और पिछली टिप्पणी के संयोजन के साथ दोनों पर विचार करने लायक यह है कि क्वेरी बदल जाएगी या नहीं और यदि ऐसा होगा तो ऑब्जेक्ट सदस्यों को उत्पन्न करने की आवश्यकता होगी। यदि क्वेरी नहीं बदलती है तो चिंता की कोई बात नहीं है - पिछले बिंदु को छोड़कर। यदि यह बदलता है तो आपके विकल्प कमोबेश निम्नलिखित उदाहरणों में शामिल हैं।

class Foo{
    private $someMember;

    /*
        $params = Associative array of fields and values
    */
    private static buildAndRunQuery($params)
    {
        /*Build sql query based on the given params Array()*/
    }
    public __construct($someMemebrValue)
    {
        $this->someMember = $someMemberValue;
        Foo::buildAndRunQuery(Array("fieldName" => $this->someMember));
    }
}

इस उदाहरण में आप अभी भी क्वेरी उत्पन्न करने के लिए एक स्थिर विधि का उपयोग कर रहे हैं, लेकिन आप प्रक्रिया के लिए गैर-स्थिर सदस्यों को पास कर रहे हैं/इस बिंदु पर (निर्माण के समय वस्तुओं पर अद्यतन होने पर टिप्पणी देखें) आप या तो स्टोर कर सकते हैं स्थिर सदस्य के भीतर परिणाम या उन्हें वापस __construct() फ़ंक्शन पर पास करें और ऑब्जेक्ट इंस्टेंस को स्टोर करें।

फिर ऐसी संभावना है कि आपके द्वारा उपयोग की जाने वाली क्वेरी कुछ फ़ील्ड का अनुरोध करने से थोड़ी अधिक शामिल है जैसे कि स्थिर फ़ंक्शन को पास करने के लिए एक बहुआयामी सरणी बनाना इसके लायक होने से अधिक परेशानी होगी। इस मामले में आप buildAndRunQuery() को buildQuery() - इंस्टेंस मेथड और runQuery() स्टैटिक मेथड जैसे कि विभाजित कर सकते हैं।

class Foo{

    private $someMember;

    /*
        $params = Associative array of fields and values
    */
    private static runQuery($query)
    {
        /*Build sql query based on the given params Array()*/
    }

    private function buildQuery()
    {
        /*Construct your query here and either return calling method or store in instance member*/
         /*Either*/
            return <Constructed query>;
        /*Or*/
           $this->query = <Constructed query>;
    }

    public __construct($someMemebrValue)
    {
        $this->someMember = $someMemberValue;
        /*As per buildQuery() comment either:*/
            Foo::runQuery($this->buildQuery());
        /*Or*/
            Foo::runQuery($this->query);
    }
}

इस मामले में Foo::runQuery() को कॉल करने से पहले जेनरेट की गई क्वेरी को संभालने के लिए कुछ विकल्प हैं।

बेशक इस बात की हमेशा संभावना होती है कि आप क्वेरी को सिंक्रोनस तरीके से या वास्तव में कंस्ट्रक्टर में बनाना और चलाना नहीं चाहते हैं।

अंत में मैं व्यक्तिगत रूप से महसूस करता हूं कि उन तरीकों के लिए जो ऑब्जेक्ट से स्वतंत्र सेवाओं के साथ बातचीत करते हैं जैसे कि Sql या शायद केंद्रित DOMDocument, या इसी तरह, ऑब्जेक्ट इंटरैक्शन, स्टेटिक विधियों का उपयोग करना सबसे अच्छा है जहां वे दोनों प्रासंगिक हैं और अंततः आपकी नाक को काट नहीं सकते हैं। अपने चेहरे के बावजूद (अनावश्यक रूप से जटिल आदि)। बेशक इस सब पर प्रति वर्ग के आधार पर विचार करने की आवश्यकता है।