किस प्रकार कक्षाएं एक php OOP डिजाइन

Question

मैं एक आर्केड साइट चलाने के लिए और पिछले कुछ वर्षों में यह कई सुविधाओं, कहा कि यह बिंदु है जहां प्रक्रियात्मक प्रोग्रामिंग अभी जिस तरह जटिल और लग रहा है नई सुविधाओं को जोड़ने या सरल बनाने के लिए मिला है था है में उपयोग करने के लिए डिजाइन संशोधन बहुत मुश्किल हो सकता है।

इसलिए मैं कोशिश करते हैं और एक ही सुविधाओं के साथ, लेकिन एक OOP प्रारूप में जमीन से साइट पुनःकूटित करना तय कर लिया है।

मुद्दा रहा है कक्षाएं उठा रहा है, मैं OOP को समझते हैं और यह कैसे काम करना चाहिए, लेकिन हमेशा मुसीबत शुरू हो रही है लगता है। मुझे यकीन है कि मुझे यूजर क्लास जैसे क्लास के लिए फ़ंक्शन में उपयोगकर्ता फ़ंक्शन के साथ फ़ंक्शन बनाने की कोशिश करनी चाहिए या यदि उपयोगकर्ता क्लास को उपयोगकर्ता विवरण जोड़ने/अपडेट/अपडेट करना होगा और लॉग इन भाग सिस्टम में बेहतर होगा कक्षा?

फिलहाल मैंने निम्न श्रेणी और कार्यों के साथ शुरुआत की है, लेकिन क्या वे इस श्रेणी में फिट हैं?

<? 
class User { 

    var $userId, 
     $username, 
     $userRole, 
     $userEmail; 

    function isLoggedIn(){ 

    } 

    function login($postusername, $postpassword) 
    { 

    } 

    function increaseLoginCount(){ 

    } 

    function logout(){ 

    } 
} 
?> 

मैं तो .. एक page.php में निम्नलिखित की तरह कुछ हो सकता था (नहीं दिखाया गया वर्ग कनेक्ट)

<? 
$db = new Connect; 
$db->connect(); 

$user = new User; 

if(!$user->isLoggedIn()) 
{ 
    echo "Please Log In."; 

    if($_POST['user']) 
    { 
     $user->login($_POST['username'], $_POST['password']); 
    } 
} 
else 
{ 
    if($_POST['logout']) 
    { 
     $user->logout(); 
     exit; 
    } 

    echo $user->username." Logged In.<br />"; 
} 
?> 

लेकिन तब साइट खेल श्रेणियों दिखाने के लिए पृष्ठों के लिए होता है और मैं डॉन ' टी पता नहीं है कि displayGames() फ़ंक्शन फिट होगा क्योंकि यह एक गेम नहीं है, इसलिए 'गेम' कक्षा में नहीं जाएंगे?

मैं जैसे उपयोगकर्ता वर्ग नज़र में खोजने के लिए 'असली दुनिया' उदाहरण लेकिन php कोड मुझे दिखा कैसे एक हाथी रंग बदल या नृत्य वास्तव में मदद नहीं करता है बनाने के लिए कोशिश की है ...

Answer 1

के कुछ ऐसे मौलिक विश्लेषण के साथ शुरू करते हैं, मेरे द्वारा डाला:

मैं एक आर्केड साइट और से अधिक पिछले कुछ वर्षों

के बारे में कितना सोचो चलाने आप से निपटने में सक्षम हैं और आप किसके साथ काम कर रहे हैं।यह भी समझें कि पिछले कुछ वर्षों में आपने विशिष्ट ज्ञानआर्केड साइट चलाया है। आपने अपने क्षेत्र में पेशा हासिल किया है। अपनी खुद की स्थिति और परिसंपत्तियों को कभी कम मत समझें, यह वह आधार है जिसका आप संचालन कर रहे हैं और आप इसमें परिवर्तन पेश करेंगे। इसमें आपकी साइट का उपयोगकर्ताबेस शामिल है।

यह कई सुविधाओं जोड़ा था, यह बिंदु है जहां प्रक्रियात्मक प्रोग्रामिंग अभी जिस तरह जटिल और नई सुविधाओं को जोड़ने या साधारण डिजाइन संशोधनों बहुत मुश्किल हो सकता है बनाने लग रहा है करने के लिए मिला है।

यदि सिस्टम बढ़ते हैं, तो वे अधिक से अधिक जटिल हो जाते हैं। यह केवल प्रक्रियात्मक प्रोग्रामिंग के लिए विशिष्ट नहीं है, यह तथ्य की बात है। चूंकि आप अब कई सालों से साइट चला रहे हैं, आप जानते हैं कि चीजें कैसे बदलीं, खासकर इस क्षेत्र में कि उपयोगकर्ता आपकी साइट के साथ कैसे इंटरफेस करता है।

इसलिए मैं करने का निर्णय लिया कोशिश और वही सुविधाएँ साथ, लेकिन एक OOP प्रारूप में जमीन से साइट पुनःकूटित।

ऐसा कहा जाता है कि पुनः उपयोग करने योग्य सॉफ़्टवेयर बनाने के लिए ओओपी तकनीकों का उपयोग करना संभव हो सकता है, इसका कोई सबूत नहीं है (और नहीं हो सकता)।

लेकिन वाणिज्यिक सॉफ्टवेयर विकास में केवल कुछ ही उदाहरण हैं जहां पूरे आवेदन को स्क्रैच से पुनः लिखना एक सफलता थी। बहुत कम। वाणिज्यिक सॉफ्टवेयर विकास के नियम आपके विशिष्ट मामले में लागू नहीं हो सकते हैं, इसलिए बस कह रहे हैं।

साइट को रिकोड करने से पहले दो बार सोचें। केवल इसे प्राप्त करने के लिए बहुत सारे काम करना कुछ हद तक फलहीन है और निराशाजनक हो सकता है। इसके बजाए शायद अधिक विशेष रूप से देखें कि आपके वर्तमान डिज़ाइन में से कौन सी सबसे बड़ी समस्या है जिसे आप बदलना पसंद करेंगे।

यह पीएचपी साथ प्रक्रियात्मक मिश्रण और वस्तु उन्मुख शैली, आप (कोड विरासत कोड के एक सामान्य परिभाषा है w/स्वचालित परीक्षण ओ) विरासत कोड है जब जो विशेष रूप से उपयोगी हो सकता है संभव है।

मुद्दा रहा है वर्गों उठा रहा है,

मुझे लगता है कि अलग तरीके से व्यक्त करने की कोशिश: क्या के लिए के लिए कक्षाओं बारे में?

मैं OOP समझ में और यह कैसे काम करना चाहिए, लेकिन हमेशा की है मुसीबत शुरू हो रही लगते हैं।

शुरुआत हमेशा सबसे कठिन कदम है। आप निर्णय लेने के लिए तैयार स्थिति में हैं, लेकिन आप भविष्य में नहीं देख सकते हैं। सबसे जोखिम भरा हिस्सा को खत्म करके जोखिम को कम करें। आपने शायद अपने फैसले को आधार देने के लिए कुछ प्रतिक्रिया प्राप्त करने के लिए यहां एक प्रश्न पूछना शुरू कर दिया है, लेकिन इससे शायद बोझ कम नहीं होगा और इससे भ्रम पैदा हो सकता है।हालांकि, शिक्षित होना अक्सर एक अच्छी बात है।

मैं कर रहा हूँ अनिश्चित कि क्या मैं जैसे उपयोगकर्ता समारोह में या यदि उपयोगकर्ता वर्ग बस/अद्यतन/शो उपयोगकर्ता विवरण जोड़ने के लिए होना चाहिए लॉग के साथ एक उपयोगकर्ता वर्ग के रूप में कक्षाओं के लिए काम करता है बनाने के लिए कोशिश कर रहा होना चाहिए और एक वर्ग वर्ग में लॉग में हिस्सा बेहतर होगा?

यह आपके आवेदन की प्रकृति और उपयोगकर्ता की प्रकृति पर निर्भर करता है। शायद आपकी अधिकांश स्क्रिप्ट को केवल यह जानना होगा कि कोई उपयोगकर्ता कंक्रीट या अज्ञात है (अज्ञात उपयोगकर्ता लॉग इन नहीं हुआ है), यह आईडी, नाम या उपनाम है।

आवेदन उस उपयोगकर्ता को किसी उपभोग करने वाले घटक को प्रदान करना चाहिए, इसलिए प्रत्येक कमांड/स्क्रिप्ट को उपयोगकर्ताओं की जानकारी प्राप्त करने और उपयोगकर्ताओं को संभालने (जैसे लॉग इन करने) को संभालने की आवश्यकता नहीं है, बी) यह सत्यापित करना कि घटक के लिए मान्य है या नहीं उपयोगकर्ता (अभिगम नियंत्रण)। इसे कहीं और रखा जाना चाहिए, उदा। application controller^­PofEAA में।

आपकी प्रत्येक स्क्रिप्ट/कमांड जिनमें एप्लिकेशन नियंत्रक ऑब्जेक्ट है, उपयोगकर्ता के लिए पूछ सकता है और केवल उपयोगकर्ता से बातचीत कर सकता है।

हालांकि यह तकनीकी रूप से बोल रहा है। अपने आप को अनिश्चित होने के तथ्य से निपटें, उस जानकारी के साथ काम करें। अपनी ठोस समस्या को बेहतर बनाने की कोशिश करें, इसे हल करने के एक विशिष्ट तरीके के लिए पेशेवरों और विपक्षों को सूचीबद्ध करें, कोड शुरू करने से पहले कंक्रीट कोड से दूर हो जाएं। फिर पेशेवरों और विपक्ष की तुलना करें। चीजों को और अधिक सरल और कम जटिल बनाने की कोशिश करें।

संभवतः सरल शब्दों में लिखना कोड लिखने के बजाय क्या हो रहा है।

पल मैं निम्नलिखित वर्ग और कार्यों साथ शुरू किया, लेकिन ऐसा किया गया कम से

वे में इस श्रेणी फिट **? **

आपका कोड, काफी नंगे है, इसलिए यह मुश्किल है इसके बारे में बहुत कुछ कहना - विशेष रूप से मुझे नहीं पता कि आपकी आर्केड साइट क्या है (और आप किस श्रेणी के बारे में लिखते हैं)। यह शायद एक उदाहरण के लिए अभी भी अच्छा है। आपकी कक्षाओं में क्या देखा जा सकता है कि आप एक दूसरे के साथ सबकुछ मजबूत रूप से एकीकृत करते हैं।

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

$application->getDB(); 

चूंकि उपयोगकर्ता प्रत्येक एप्लिकेशन में ऐसा केंद्रीय विषय है, तो इसका एक बहुत ही सरल इंटरफ़ेस होना चाहिए। प्रमाणीकरण के बारे में सभी महिमा विवरण, के उपयोगकर्ताओं के गुण आदि पुन: प्राप्त करने, अन्य वर्ग/घटक में सौंप दिया जाना चाहिए ताकि आप कार्यान्वयन जहाँ उपयोगकर्ताओं को जमा हो जाती है बदल सकते हैं और वे कैसे प्रमाणित:

/** 
    * @package command.modules.games 
    */ 
function ListGamesCommand(Request $request, Response $response) 
{ 
    $application = $request->getApplication(); 
    $user = $application->getSession()->getUser(); 
    $games = $application->getModels()->build('games'); 
    $games = $games->findByUser($user); 
    $response->setProp('games', $games); 
} 

के रूप में इस उदाहरण से पता चलता है , जब आपको आवश्यकता हो तो आप कार्यक्षमता जोड़ सकते हैं। जैसे जब तक आपके एप्लिकेशन को वास्तव में उपयोगकर्ताओं में लॉग इन करने की आवश्यकता नहीं है, तब तक क्यों परवाह है कि यह अब कैसे लिखा गया है?जो कुछ भी यह अब या भविष्य में आवश्यकता होगी (वस्तुओं The Clean Code Talks — Inheritance, Polymorphism, & Testing में की दो बवासीर देखें) -

एक कारखाने कि आवेदन वस्तु के लिए उपयोगकर्ता का निर्माण कर रहा है बनाएँ। यदि आपको प्रमाणीकरण की आवश्यकता है, तो इसे सत्र ऑब्जेक्ट या उपयोगकर्ता ऑब्जेक्ट इंटरफ़ेस में जोड़ें।

प्रमाणीकरण स्वयं को किसी भी तरह की कक्षा में लागू किया जाएगा, Authenticator। इसलिए आप बाद में अपने इंटरफेस की समीक्षा भी कर सकते हैं, सत्र से उपयोगकर्ता या प्रमाणीकरण से प्रमाणीकरण के आमंत्रण को स्थानांतरित करके। केवल आपके आदेशों का एक अंश इन विशिष्ट कार्यों से निपटने की आवश्यकता होगी और चूंकि सभी नए कोड स्वचालित परीक्षणों के तहत हैं, क्योंकि आप ओओपी से फिर से लिखना और लाभ लेना चाहते हैं, आपने यह सुनिश्चित किया है कि सभी जगहें ढकी हुई हैं और ठीक से फिर से परिचालित हैं।

अनुरोध चरों तक पहुंचने के लिए भी सही है। यदि आप ओओपी के लाभों का उपयोग करना चाहते हैं - जो संकेत के साथ अत्यधिक जुड़ा हुआ है (और संकेत की प्रत्येक परत एक मूल्य के साथ आता है) - आपको सबसे पहले अपने बेस क्लास विशिष्ट डेटा पर काम करना चाहिए, न कि किसी भी डेटा (जैसे ग्लोबल्स और सुपरग्लोबल्स, मैंने आपके उदाहरण कोड में $_POST देखा है)।

तो एक अनुरोध पर संचालित करने के लिए अपने नए कोड को सक्षम और एक प्रतिक्रिया देने के (इनपुट - प्रसंस्करण - आउटपुट):

$request = new Request($_SERVER, $_GET, $_POST, $_COOKIE, $_FILES, $_ENV); 
$response = new Response; 

^{उदाहरण BankAccount - Sample application used for PHPUnit training}

अब इस नीचे सब कुछ से लिया Request और Response ऑब्जेक्ट पर प्रक्रिया कर सकते हैं - प्रक्रिया इनपुट करें और इसे आउटपुट में चालू करें। डोमेन कमांड (आपकी स्क्रिप्ट/आदेश जो आइटम करते हैं) को HTTP अनुरोध से इनपुट निकालने के बारे में अब देखभाल करने की आवश्यकता नहीं है जैसे $_POST या $_GET वे इसे Request से सीधे ले जा सकते हैं - या यदि आप एक वर्ग लिखते हैं इसके स्वयं के आदेश - यह और भी अनुरूप हो सकता है। और कुछ आदेश स्वयं के अनुरोधों और प्रतिक्रियाओं पर काम कर सकते हैं।

अगला बड़ा विषय उपयोगकर्ता-इंटरफ़ेस है। आप लिखते हैं आप चाहते हैं:

मैं कोशिश करते हैं और एक ही सुविधाओं के साथ, लेकिन एक OOP प्रारूप में जमीन से साइट पुनःकूटित करना तय कर लिया है।

मैंने पहले से ही लिखा है कि ऐसा करना फलहीन हो सकता है। ओओपी कोड का लाभ उठाने का मतलब यह होगा कि अगली बार जब आप अपना कोड बदलते हैं, तो भी आप घटकों का पुनः उपयोग कर सकते हैं। जैसे-जैसे सॉफ़्टवेयर लगातार बदलता है, इस बार अब अगली बार है। तो आप पहले से ही मौजूदा कोड का पुनः उपयोग करना चाहते हैं। मुझे लगता है कि आपके मौजूदा कोड का एक हिस्सा आउटपुट तर्क है। तो मौजूदा आउटपुट तर्क को उपरोक्त अनुकरणीय Request और Response के साथ इंटरफेस करने की आवश्यकता है।

मुझे यकीन है कि आप वेबसाइटों से प्यार करते हैं। आप उन्हें सिर्फ काम करने और महान दिखने के लिए प्यार करते हैं। आपने वर्षों में अपनी साइट बनाई है और यहां तक ​​कि सब कुछ ऐसा नहीं है जैसा आप चाहते हैं, आप इसे छोड़ना नहीं चाहते हैं। तो यह आपके पुन: लिखने के लिए महत्वपूर्ण है कि आप सबकुछ नष्ट नहीं करते हैं लेकिन आप अब से भविष्य में अपने कामकाजी फॉर्म को संरक्षित कर सकते हैं (साथ ही Preserve a Working Application; last point of the list देखें)।

वेबपैस में दृश्य इतना महत्वपूर्ण हिस्सा है। यदि आप दृश्य को खो देते हैं, तो आपकी साइट इसकी पहचान खो देगी।यदि आप इसमें बहुत अधिक परिवर्तन करते हैं, तो आपकी साइट उन उपयोगकर्ताओं को खो देगी जो आज इसका उपयोग करने में सहज हैं।

आप इसे तोड़ने, तो

1. आप भी नोटिस करेंगे?
2. क्या आप इसे ठीक कर सकते हैं?

दूसरी ओर आप अपने आवेदन कोड (सुविधाएं, कार्यक्षमता) चाहते हैं नहीं होने के लिए कि कसकर यह किसी भी अब करने के लिए बाध्य अपने कोड पुनर्लेखन में एक लाभ है।

 .---------.       .-------------. 
    | website | ---> [interface in ] ---> | application | 
    | user | <--- [interface out] <--- |    | 
    `---------´       `-------------´ 

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

User ऑब्जेक्ट को यहां एक उदाहरण के रूप में लेना। यह कैसे प्रमाणित करता है और कहां संग्रहीत किया जाता है, ऐसा कुछ नहीं होना चाहिए जो आपके नए एप्लिकेशन कमांड कोड के बारे में चिंतित हैं। अगर आदेश की आवश्यकता है तो यह सिर्फ वहां है। वैश्विक रूप से नहीं, लेकिन विशेष रूप से यदि आदेश इसके लिए पूछता है।

जहां पंजीकरण और खोए गए पासवर्ड प्रक्रियाएं आपके मौजूदा एप्लिकेशन का हिस्सा हैं और मौजूद हैं।

अब आपको पुराने और नए कोड को एक साथ लाने की आवश्यकता है।

तो आप शायद HTTP अनुरोधों और HTTP प्रतिक्रिया के लिए एक इंटरफेस से शुरू करेंगे। दृश्य इंटरफ़ेस आउट के साथ आता है। आप उस इंटरफेस के माध्यम से दृश्य के लिए सभी आवश्यक डेटा असाइन/पास करते हैं, आपका आवेदन अब दृश्य को नहीं जानता है। आप अपने नए एप्लिकेशन कोड के भीतर किसी भी सीएसएस, जावास्क्रिप्ट या एचटीएमएल कोड से निपट नहीं सकते हैं। आउटपुट के लिए यह सिर्फ चीनी है। आपके एप्लिकेशन को सादा पाठ में कंसोल/टेलनेट के माध्यम से या रिमोट एक्सएमएलआरपीसी सेवा के रूप में इंटरफेस करना चाहिए, AJAX एंडपॉइंट - जो भी हो।

तो आप शायद अपने व्यू कोड को सामान्यीकृत कर सकते हैं और इसमें चर इंजेक्ट कर सकते हैं। एक दृश्य परत लिखने के लिए एक PHP फ़ाइल सहित सरल हो सकता है। यह उन चर पर चल रहा है जो इसके दायरे में उपलब्ध हैं। यह "सहायक" कार्यों (टेम्पलेट मैक्रोज़) का उपयोग कर सकता है जो इसके दायरे में उपलब्ध हैं। यह का उपयोग मॉडल ऑब्जेक्ट्स का उपयोग कर सकता है। दृश्य के लिए अपनी भाषा लिखना भी संभव है (templating भाषा, एक डोमेन विशिष्ट भाषा (डीएसएल))।

लेकिन यह केवल तभी संभव है जब आप एक इंटरफ़ेस बनाते हैं जो एप्लिकेशन कोड को ऐसा करने की अनुमति देता है।

तो अब आप अपने आवेदन से एचटीएमएल/एचटीएमएल/सीएसएस/जेएस को अपने एडाप्टर में ले जाने के लिए क्या करना चाहते हैं। वह एडाप्टर जेनेरिक कमांड तैयार करने में सक्षम है जिसे इंटरफ़ेस में इंटरफ़ेस के माध्यम से पारित किया जा सकता है।

एप्लिकेशन केवल आदेश निष्पादित करने और इंटरफ़ेस के माध्यम से इसकी प्रतिक्रिया देने का ख्याल रखेगा। तो आपके पास अब दो डोमेन हैं: आपका एप्लिकेशन और वेबसाइट।

आप इन दो नए डोमेन बनाने शुरू कर सकते हैं और फिर अपने विरासत कोड और एक नए कोड के लिए एक इंटरफ़ेस प्रदान कर सकते हैं।

आपके पास एक दूसरे के बगल में "दो" अनुप्रयोग भी हैं। अंत में वे आपके डेटाबेस के साथ एक साथ बंधे हुए हैं (अपने कोड में अदृश्य) जो आपकी साइट का डेटा क्रम में ध्यान रखता है। और यही डेटाबेस के लिए है। अपने कोड से डेटा अलग करें, ताकि आप समय के साथ अपना कोड बदल सकें।

यदि आप फिर से कोड करना चाहते हैं, तो मौजूदा कोड और नए कोड के बीच सीमा बनाएं।

गुड लक! और मुझे उम्मीद है कि यह आपको आपके विशिष्ट मामले के लिए कुछ विकल्प दिखाएगा। यह भी ध्यान रखें कि आप अपने नियंत्रकों को डेटाबेस में बस एक और मुखौटा में नहीं बदलते हैं। शायद आपको लाइटवेट HTTP एब्स्ट्रक्शन और व्यू लेयर का उपयोग करके सबसे अच्छा लाभ मिल गया है (केवल अपनी कंक्रीट सबसे बड़ी समस्या नहीं है) क्योंकि यह हो सकता है कि आपका एप्लिकेशन केवल वेबसाइटों के लिए है।

चूंकि HTTP/PHP में के रूप में:

[Interface In] Plain Text HTTP request 
[Application] Free to go 
[Interface Out] Plain Text HTTP response 

आप आम तौर पर इनपुट को पार्स और उत्पादन के निर्माण के लिए केवल कुछ कार्यक्षमता की जरूरत है।

इसके अतिरिक्त वसा मॉडल का उपयोग न करने का लाभ यह है कि आप अपने डेटा को तेज़ी से और अनुक्रमिक रूप से एक्सेस करते हैं, उदा। यदि आपको आउटपुट को एक बार पास करने की आवश्यकता नहीं है (buffered, एक-ब्लॉक), तो आप आउटपुट को सर्वर पर स्ट्रीम करने के लिए लाभ प्राप्त कर सकते हैं।

आपको यह तय करना चाहिए कि आपके आवेदन के लिए रिफैक्टर के लिए कौन से हिस्से महत्वपूर्ण हैं, ओओपी नहीं या नहीं। प्रक्रियात्मक की तरह, ओओपी को भी अच्छी तरह से किया जाना चाहिए। यदि आप आज प्रक्रियात्मक कोड लिखकर समस्याओं में भाग लेते हैं, तो ओओपी कोड आपकी समस्या का उत्तर नहीं दे सकता है। बेहतर प्रक्रियात्मक कोड लिखने की आवश्यकता यह हो सकती है। बस कह रहा है, किसी एप्लिकेशन को दोबारा उपयोग करना आसान नहीं है और आपको पहले वास्तविक समस्या की पहचान करनी चाहिए।

1. यदि आप इसे तोड़ते हैं, तो क्या आप भी ध्यान देंगे?
2. यदि आप इसे तोड़ते हैं, तो क्या आप इसे ठीक कर सकते हैं?

महत्वपूर्ण हिस्सा यह है कि आप ध्यान दे सकते हैं और आपके पास ठीक करने के लिए सब कुछ है।

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

ऐसा करने से आप आसानी से एक नई सुविधा के बारे में निर्णय ले सकते हैं या नहीं। जब तक आपको नई सुविधाओं को पेश करने की आवश्यकता नहीं है, तब तक आप सुविधाओं को लिखने में कुछ भी बदलने की जरूरत नहीं है। और वहां तक, आप नई सुविधाओं के लिए योजना नहीं बना सकते हैं।

तो अपने आवेदन को दोबारा लिखने से पहले दो बार बेहतर सोचें। जैसा लिखा है, यह परियोजना को मार सकता है।

---

रूप में अच्छी तरह देखें:How to implement MVC style on my PHP/SQL/HTML/CSS code?^{­SO Q&A}

Answer 2

सभी सदस्य वे वहां हैं। गुई कोड को अन्य कोड से अलग करना महत्वपूर्ण है, मैं कुछ प्रकार के गुई क्लास में displayGames() डाल दूंगा।

Answer 3

OOP सब के बारे में जिम्मेदारी के क्षेत्रों की पहचान और कोड की आत्म निहित इकाइयों एक, और केवल एक, उन क्षेत्रों की संभाल करने के उद्देश्य से निर्माण है। अंगूठे का एक सामान्य नियम यह है कि आपके सिस्टम में प्रत्येक वस्तु को वास्तविक दुनिया में समकक्ष वस्तु या अवधारणा को अवतारित करना चाहिए, लेकिन यह हमेशा सत्य नहीं है क्योंकि आपको अपने सिस्टम को काम करने के लिए आवश्यक अमूर्त चीज़ों के बारे में भी चिंता करने की आवश्यकता है (मेरा मतलब यहां सार है इस अर्थ में कि वे व्यापार तर्क के किसी आइटम का प्रतिनिधित्व नहीं करते हैं, लेकिन सिस्टम को काम करने के लिए अभी भी जरूरी है। मेरा मतलब अमूर्त वर्ग नहीं है, जो कुछ और पूरी तरह से है)।

उदाहरण के लिए, आपके गेमिंग साइट में, तो आप शायद इतने पर खेल, उपयोगकर्ता, मध्यस्थ, लेखा, समीक्षा, टिप्पणियां और से निपटने के लिए जा रहे हैं। इनमें से प्रत्येक एक वर्ग अपने अधिकार में होना चाहिए, और उस वर्ग के हर उदाहरण को किसी विशेष उपयोगकर्ता, गेम, टिप्पणी आदि का प्रतिनिधित्व करना चाहिए।

लेकिन कक्षाओं में ज़िम्मेदारी के क्षेत्र हैं, और ऊपर बताए गए अनुसार, एक वर्ग को जिम्मेदारी के क्षेत्र से निपटना चाहिए और कुछ भी नहीं। किसी पृष्ठ को प्रस्तुत करना ऊपर वर्णित किसी ऑब्जेक्ट क्लास की ज़िम्मेदारी नहीं है। यह वह जगह है जहां आपके सिस्टम की इकाइयों का प्रतिनिधित्व नहीं करने वाले वर्ग आते हैं। आपको शायद किसी पृष्ठ के लिए कक्षा, सत्र के लिए कक्षा, डेटाबेस कनेक्शन के लिए एक कक्षा की आवश्यकता होगी (हालांकि PHP ने आप पहले ही पीडीओ के साथ कवर किया है और कुछ अन्य डीबी मॉड्यूल जैसे कि mysqli)।

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

class Page 
{ 
    private $user = NULL; 
    private $games = array(); 

    public function setUser (User $user) 
    { 
     $this -> user = $user; 
    } 

    public function getUser() 
    { 
     return ($this -> user); 
    } 

    public function addGame (Game $game) 
    { 
     $this -> games [] = $game; 
    } 

    public function getGames() 
    { 
     return ($this -> games); 
    } 

    public function generate() 
    { 
     $user = $this -> getUser(); 
     $games = $this -> getGames(); 

     $pageFile = '/path/to/a/php/script/representing/the/page/markup.php'; 
     require ($pageFile); 
    } 

    public function __construct (User $user, array $games) 
    { 
     $this -> setUser ($user); 
     foreach ($games as $game) 
     { 
      $this -> addGame ($game); 
     } 
    } 
} 

वास्तविक markup.php स्क्रिप्ट शायद कुछ इस तरह दिखेगा:

<html> 
    <head> 
     <title>Games page for <?php echo ($this -> user -> getName()); ?> 
    </head> 
    <body> 
    <p>Hello, <?php echo ($this -> user -> getName()), here are your games.</p> 
    <?php if (count ($this -> games)) { ?> 
    <ul> 
     <?php foreach ($this -> games as $game) { ?> 
     <li><?php echo ($game -> getName()); ?>: your best score is <?php echo ($game -> getHighScore ($this -> user)); ?></li> 
     <?php } ?> 
    </ul> 
    <?php } ?> 
    </body> 
</html> 

आपने गौर किया हो सकता है, अगर आप इस दृष्टिकोण का उपयोग तो आपके आवेदन के मॉड्यूल तीन श्रेणियों में से एक में गिरने लगेगा। उपयोगकर्ता और गेम जैसे आपके व्यवसाय तर्क वस्तुएं, मार्कअप.एफ़.पी.पी. फ़ाइल जैसे आपका डिस्प्ले तर्क, और तीसरा समूह जो गोंद तर्क और पृष्ठ वर्ग जैसे समन्वय के रूप में कार्य करता है।

जबकि इस विशेष मामले में यह आपकी साइट के लिए विशिष्ट है, यदि आप इस दृष्टिकोण को सामान्यीकृत करना चाहते हैं तो यह एक डिजाइन पैटर्न में गिर जाएगा जो एमवीसी के रूप में जाना जाता है, जो मॉडल, व्यू, कंट्रोलर के लिए खड़ा है (वास्तव में यह एक पैटर्न के करीब है प्रेजेंटेशन, एब्स्ट्रक्शन, कंट्रोलर के लिए पीएसी कहा जाता है, लेकिन इसे लगभग किसी कारण से PHP समुदाय में हमेशा एमवीसी कहा जाता है, इसलिए हम अभी एमवीसी कहेंगे)। एक पैटर्न उन समस्याओं की एक वर्ग का सामान्यीकरण है जो प्रोग्रामर नियमित रूप से पर्याप्त आधार पर चलते हैं कि पूर्व-निर्मित समाधानों का टूलकिट आसान है।

आपके गेमिंग एप्लिकेशन के मामले में, उपयोगकर्ता और गेम मॉडल हैं, पृष्ठ एक नियंत्रक है, और markup.php एक दृश्य है। यदि आप इस कोड में एक अलग markup.php स्क्रिप्ट को प्रतिस्थापित करते हैं तो आप इसका उपयोग उसी तरह के डेटा को पूरी तरह से अलग तरीके से प्रस्तुत करने के लिए कर सकते हैं, उदाहरण के लिए एक्सएमएल फ़ाइल के रूप में कहें। आप अलग-अलग चीजों को करने के लिए एक ही नियंत्रक के साथ एक ही मॉडल का उपयोग कर सकते हैं। यहां ध्यान रखने योग्य महत्वपूर्ण बात यह है कि मॉडलों को खुद से चिंता नहीं करनी चाहिए कि उनका उपयोग कैसे किया जा रहा है, इस तरह उन्हें नियंत्रकों को प्राप्त करने की आवश्यकता के आधार पर विभिन्न तरीकों से उपयोग किया जा सकता है।

चूंकि एमवीसी एक पैटर्न है, एमवीसी बनाने के लिए पहले से ही टूलकिट मौजूद हैं (हालांकि वे वास्तव में एमवीसी नहीं हैं;)) PHP में अनुप्रयोग। इन्हें ढांचे कहा जाता है। वहां से चुनने के लिए बहुत सारे विकल्प हैं, जैसे सिम्फनी, कोडइग्निटर, ज़ेंड फ्रेमवर्क और इसी तरह। इन दिनों सबसे लोकप्रिय रूपरेखा ज़ेंड है, हालांकि मैं व्यक्तिगत रूप से इसके प्रशंसक नहीं हूं। (मैं कहूंगा कि ज़ेंड फ्रेमवर्क 2 के बीटा संस्करण हालांकि ढांचे के वर्तमान संस्करण की तुलना में बहुत बेहतर दिखते हैं)।

मुझे आशा है कि यह आपके लिए सहायक होगा। मुझे पता है कि ओओपी पहले चुनौतीपूर्ण हो सकता है। यह आपको प्रोग्रामर के रूप में सोचने का अपना तरीका बदलने की आवश्यकता है, लेकिन चिंता न करें, यह पर्याप्त अभ्यास के साथ आएगा।

Answer 4

गॉर्डनएम की पोस्ट आपको शुरू करने के लिए एक अच्छा है। मैं निश्चित रूप से आपको शुरू करने के लिए एक स्थापित ढांचे का उपयोग करने की सलाह दूंगा - वे आपके लिए भारी भारोत्तोलन करते हैं और आपको PHP के भीतर ओओपी में उपयोग करने में मदद करेंगे। निजी तौर पर, यदि आप PHP5.3 का उपयोग कर रहे हैं तो मैं सिम्फॉमी 2 की सिफारिश करता हूं लेकिन यह पूरी तरह से व्यक्तिगत वरीयता है। मैं यह भी सुझाव दूंगा कि आपको the "Gang of Four" book की एक प्रति प्राप्त हो। यह बहुत जरूरी पढ़ना है और हालांकि यह मुख्य रूप से गैर-अनुरोध-संचालित-पर्यावरण पृष्ठभूमि से आता है, हालांकि कई पैटर्न PHP में अभी भी प्रासंगिक हैं।