![translation](https://cdn.durumis.com/common/trans.png)
यह एक AI अनुवादित पोस्ट है।
भाषा चुनें
durumis AI द्वारा संक्षेपित पाठ
- यह फिल्म बुकिंग सिस्टम को लागू करने के लिए ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग दृष्टिकोण की व्याख्या करता है, सहयोग, ऑब्जेक्ट और कक्षा की अवधारणाओं का परिचय देता है, और डोमेन संरचना का पालन करने वाले प्रोग्राम संरचना पर प्रकाश डालता है।
- विशेष रूप से, यह वस्तुओं की स्वायत्तता और एनकैप्सुलेशन के माध्यम से बाहरी हस्तक्षेप को कम करने और प्रोग्रामर की स्वतंत्रता की गारंटी देने के लिए इंटरफ़ेस और कार्यान्वयन को अलग करने के तरीके प्रदान करता है।
- यह छूट दरों की गणना के लिए सहयोग और वंशानुगत, बहुरूपता का उपयोग करके लचीला और विस्तार योग्य कोड लिखने के तरीके की व्याख्या करता है, और अमूर्तता के महत्व और कोड पुन: उपयोग के लिए रचना के लाभों पर प्रकाश डालता है।
फिल्म बुकिंग सिस्टम
आवश्यकताओं की समीक्षा
- हम एक ऑनलाइन फिल्म बुकिंग सिस्टम को लागू करने का प्रयास कर रहे हैं।
- फिल्म फिल्म के बारे में बुनियादी जानकारी का प्रतिनिधित्व करती है।
- शीर्षक, स्क्रीनिंग समय, मूल्य जानकारी आदि
- स्क्रीनिंग दर्शकों द्वारा वास्तव में फिल्म देखने की घटना का प्रतिनिधित्व करती है।
- स्क्रीनिंग की तारीख, समय, संख्या आदि
- लोग फिल्मों को बुक करते हैं, लेकिन सच्चाई में, उन्हें एक विशिष्ट स्क्रीनिंगको बुक करना चाहिए।
- छूट की शर्तें
- मूल्य में छूट की उपलब्धता
- क्रम स्थिति: छूट की उपलब्धता का निर्धारण करने के लिए स्क्रीनिंग क्रम का उपयोग करना
- समय सीमा स्थिति: छूट की उपलब्धता का निर्धारण करने के लिए फिल्म की स्क्रीनिंग शुरू होने के समय का उपयोग करना
- छूट नीति
- छूट दर का निर्धारण
- रकम छूट नीति: बुकिंग शुल्क से एक निश्चित राशि में कटौती
- प्रतिशत छूट नीति: नियमित मूल्य से एक निश्चित प्रतिशत छूट
- प्रत्येक फिल्म के लिए एक छूट नीति असाइन की जा सकती है या बिल्कुल भी नहीं, और छूट की शर्तों को एक साथ मिलाया जा सकता है।
- यदि छूट नीति लागू है लेकिन छूट की शर्तें पूरी नहीं होती हैं, या यदि छूट नीति लागू नहीं है, तो शुल्क में कटौती नहीं की जाती है।
ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की ओर
सहयोग, ऑब्जेक्ट, क्लास
- ऑब्जेक्ट ओरिएंटेड ऑब्जेक्ट का उन्मुखीकरण है।
- क्लास को परिभाषित करने के बाद, आपको यह नहीं सोचना चाहिए कि क्लास के लिए कौन से गुण और विधियाँ आवश्यक हैं।
- आपको यह तय करना होगा कि किन वस्तुओं में कौन सी स्थिति और व्यवहार है।
- आपको वस्तुओं को स्वतंत्र इकाइयों के बजाय एक सहयोगी समुदाय के सदस्य के रूप में देखना चाहिए।
डोमेन संरचना का पालन करने वाला प्रोग्राम संरचना
- डोमेन समस्या को हल करने के लिए उपयोगकर्ता द्वारा प्रोग्राम का उपयोग किए जाने वाले क्षेत्र को संदर्भित करता है।
- सामान्य तौर पर, क्लास के नाम को संबंधित डोमेन अवधारणा के नाम के समान या कम से कम समान होना चाहिए।
- क्लास के बीच के रिश्ते को भी जितना हो सके डोमेन अवधारणाओं के बीच के रिश्ते के समान बनाया जाना चाहिए ताकि प्रोग्राम की संरचना को समझना और अनुमान लगाना आसान हो सके।
क्लास लागू करना
- क्लास को आंतरिक और बाहरी में विभाजित किया जाता है, और एक बेहतरीन क्लास को डिजाइन करने के लिए, आपको यह तय करना होगा कि कौन सा हिस्सा सार्वजनिक करना है और कौन सा हिस्सा छिपाना है।
- ऑब्जेक्ट के गुणों को निजी रूप से अवरुद्ध कर दिया जाता है, और आंतरिक स्थिति को बदलने के लिए आवश्यक विधियों को सार्वजनिक रूप से खोल दिया जाता है।
- क्लास के अंदर और बाहर के बीच अंतर करने से प्रोग्रामर को कार्यान्वयन की स्वतंत्रता प्रदान करके ऑब्जेक्ट की स्वायत्तता सुनिश्चित होती है।
स्वायत्त ऑब्जेक्ट
- ऑब्जेक्ट को स्वायत्त ऑब्जेक्ट होना चाहिए जिसमें स्थिति और व्यवहार हो।
- डेटा और कार्यों को ऑब्जेक्ट के अंदर एक साथ बाँधने को एनकैप्सुलेशन कहा जाता है।
- एक्सेस कंट्रोल के माध्यम से बाहरी हस्तक्षेप को कम करके, ऑब्जेक्ट अपने स्वयं के व्यवहार को निर्धारित करने में सक्षम हो जाते हैं।
- इंटरफ़ेस और कार्यान्वयन के पृथक्करण का सिद्धांत ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के लिए पालन किया जाने वाला एक प्रमुख सिद्धांत है।
- सार्वजनिक इंटरफ़ेस: वह भाग जो बाहरी रूप से सुलभ है
- कार्यान्वयन: वह भाग जो केवल आंतरिक रूप से सुलभ है
प्रोग्रामर की स्वतंत्रता
- प्रोग्रामर की भूमिका को क्लास लेखक और क्लाइंट प्रोग्रामर में विभाजित किया गया है।
- क्लास लेखक एक नया डेटा प्रकार जोड़ता है
- क्लाइंट प्रोग्रामर क्लास लेखक द्वारा जोड़े गए डेटा प्रकार का उपयोग करता है
- कार्यान्वयन छिपाना
- क्लास लेखक क्लाइंट प्रोग्रामर को केवल आवश्यक भाग प्रदान करके आंतरिक कार्यान्वयन को छिपा सकता है।
- क्लाइंट प्रोग्रामर को केवल इंटरफ़ेस जानने की आवश्यकता है, जिससे ज्ञान की मात्रा कम हो जाती है।
सहयोग करने वाली वस्तुओं का समुदाय
- पैसे का प्रतिनिधित्व करने के लिए, केवल Long प्रकार के एक चर को घोषित करने के बजाय, Money जैसे ऑब्जेक्ट में इसे पैक करना बेहतर है। ऑब्जेक्ट का उपयोग करके, अर्थ संचार बेहतर होता है, और दोहराए गए संचालन को एक स्थान पर किया जा सकता है।
- सिस्टम के किसी विशिष्ट कार्य को लागू करने के लिए वस्तुओं के बीच होने वाली बातचीत को सहयोग कहा जाता है।
सहयोग के बारे में एक छोटी कहानी
- ऑब्जेक्ट एक दूसरे के साथ बातचीत करने का एकमात्र तरीका संदेश भेजना या प्राप्त करना है।
- प्राप्त संदेश को संसाधित करने के लिए अपने स्वयं के तरीके को विधि कहा जाता है।
- संदेश और विधि को अलग करना महत्वपूर्ण है, यहीं से बहुरूपता की अवधारणा शुरू होती है।
छूट शुल्क प्राप्त करना
छूट शुल्क गणना के लिए सहयोग शुरू करना
- Movie क्लास में छूट नीति के बारे में विस्तृत तर्क नहीं है, और इसे DiscountPolicy इंटरफ़ेस को सौंपा गया है। वंशानुगत और बहुरूपता, अमूर्तता का उपयोग करना वास्तव में महत्वपूर्ण है।
छूट नीति और छूट की शर्तें
वंशानुगत और बहुरूपता
कंपाइल समय निर्भरता और रनटाइम निर्भरता
- कोड की निर्भरता और निष्पादन समय पर निर्भरता अलग-अलग हो सकती है।
- दोनों के बीच निर्भरता जितनी अधिक अलग होगी, कोड को समझना उतना ही कठिन होगा, लेकिन कोड अधिक लचीला और विस्तार योग्य हो जाएगा।
अंतर द्वारा प्रोग्रामिंग
- वंशानुगत आपको आसानी से और जल्दी से नई कक्षाएँ जोड़ने की अनुमति देता है जो मौजूदा कक्षाओं पर आधारित हैं, और आप मूल वर्ग के कार्यान्वयन का पुन: उपयोग कर सकते हैं।
- नई कक्षाएँ बनाने की विधि, जो केवल मूल वर्ग से भिन्न होती हैं, को अंतर द्वारा प्रोग्रामिंग कहा जाता है।
वंशानुगत और इंटरफ़ेस
- वंशानुगत मूल वर्ग द्वारा प्रदान किए गए सभी इंटरफ़ेस को संतान वर्ग को विरासत में प्राप्त करने की अनुमति देता है।
- इंटरफ़ेस ऑब्जेक्ट द्वारा समझी जाने वाली संदेशों की सूची को परिभाषित करता है।
public class Movie {
public Money calculateMovieFee(Screening screening) {
return fee.minus(discountPolicy.calculateDiscountAmount(screening));
}
- Movie DiscountPolicy को calculateDiscountAmount संदेश भेज रहा है। Movie के लिए, यह मायने नहीं रखता कि किस क्लास का उदाहरण प्रतिक्रिया दे रहा है, जब तक कि वह सफलतापूर्वक प्रतिक्रिया देता है।
- इसलिए, AmountDiscountPolicy और PercentDiscountPolicy दोनों Movie के साथ सहयोग करने के लिए DiscountPolicy का प्रतिनिधित्व कर सकते हैं।
- इस प्रकार, संतान वर्ग द्वारा मूल वर्ग को प्रतिस्थापित करने की इस प्रक्रिया को अपकास्टिंग कहा जाता है क्योंकि यह ऐसा प्रतीत होता है कि संतान वर्ग स्वचालित रूप से ऊपर के मूल वर्ग में टाइप कास्ट हो जाता है।
बहुरूपता
- बहुरूपता एक ही संदेश प्राप्त करने पर ऑब्जेक्ट के प्रकार के आधार पर अलग-अलग प्रतिक्रिया देने की क्षमता को संदर्भित करता है।
- Movie एक ही संदेश भेजता है, लेकिन वास्तव में कौन सी विधि निष्पादित होती है यह इस बात पर निर्भर करता है कि संदेश प्राप्त करने वाले ऑब्जेक्ट का प्रकार क्या है।
- बहुरूपता इस तथ्य पर आधारित है कि प्रोग्राम की कंपाइल समय निर्भरता और रनटाइम निर्भरता भिन्न हो सकती है।
- बहुरूपता निष्पादित होने वाली विधि को निष्पादन समय पर निर्धारित करता है, इसलिए इसे लेट बाइंडिंग या डायनेमिक बाइंडिंग कहा जाता है।
इंटरफ़ेस और बहुरूपता
- यदि आपको कार्यान्वयन साझा करने की आवश्यकता नहीं है और आप केवल इंटरफ़ेस साझा करना चाहते हैं, तो आप अमूर्त वर्ग के बजाय इंटरफ़ेस का उपयोग कर सकते हैं।
अमूर्तता और लचीलापन
अमूर्तता की शक्ति
- अमूर्तता के लाभ
- अमूर्तता के स्तर को अलग से देखकर, आप उच्च स्तर पर आवश्यकताओं की नीति का वर्णन कर सकते हैं।
- डिजाइन अधिक लचीला हो जाता है।
लचीला डिजाइन
- अमूर्तता डिजाइन को विशिष्ट स्थितियों से जुड़ने से रोकती है, जिससे लचीला डिजाइन बनता है।
अमूर्त वर्ग और इंटरफ़ेस ट्रेडऑफ़
public abstract class DiscountPolicy {
private List conditions;
public DiscountPolicy(DiscountCondition... conditions) {
this.conditions = Arrays.asList(conditions);
}
public Money calculateDiscountAmount(Screening screening) {
for (DiscountCondition condition : conditions) {
if (condition.isSatisfiedBy(screening)) {
return getDiscountAmount(screening);
}
}
return Money.ZERO;
}
abstract protected Money getDiscountAmount(Screening screening);
}
public class NoneDiscountPolicy extends DiscountPolicy {
@Override
protected Money getDiscountAmount(Screening screening) {
return Money.ZERO;
}
- वर्तमान में NoneDiscountPolicy वास्तव में DiscountPolicy के calculateDiscountAmount() मेथड में छूट की शर्तों की अनुपस्थिति में 0 लौटाने के कारण कोई समस्या नहीं है। हालाँकि, उपयोगकर्ता दृष्टिकोण से, Movie के पैरामीटर में एक छूट नीति डालनी होती है जो None नीति है, इसलिए इसे जोड़ा गया था।
- इसलिए, अवधारणात्मक रूप से, NoneDiscountPolicy क्लास भ्रमित करने वाली है, इसलिए इसे नीचे दिए गए अनुसार संशोधित करने से समझ में आता है।
public interface DiscountPolicy {
Money calculdateDiscountAmount(Screening screening);
}
public abstract class DefaultDiscountPolicy implements DiscountPolicy {
private List conditions;
public DefaultDiscountPolicy(DiscountCondition... conditions) {
this.conditions = Arrays.asList(conditions);
}
public Money calculateDiscountAmount(Screening screening) {
for (DiscountCondition condition : conditions) {
if (condition.isSatisfiedBy(screening)) {
return getDiscountAmount(screening);
}
}
return Money.ZERO;
}
abstract protected Money getDiscountAmount(Screening screening);
}
public class NoneDiscountPolicy implements DiscountPolicy {
@Override
public Money calculateDiscountAmount(Screening screening) {
return Money.ZERO;
}
}
public class PercentDiscountPolicy extends DefaultDiscountPolicy {
private double percent;
public PercentDiscountPolicy(double percent, DiscountCondition... conditions) {
super(conditions);
this.percent = percent;
}
@Override
protected Money getDiscountAmount(Screening screening) {
return screening.getMovieFee().times(percent);
}
}
public class AmountDiscountPolicy extends DefaultDiscountPolicy {
private Money discountAmount;
public AmountDiscountPolicy(Money discountAmount, DiscountCondition... conditions) {
super(conditions);
this.discountAmount = discountAmount;
}
@Override
protected Money getDiscountAmount(Screening screening) {
return discountAmount;
}
- ऊपर की तरह, DiscountPolicy को इंटरफ़ेस के रूप में अमूर्त बनाना और इसे NoneDiscountPolicy और DefaultDiscountPolicy में विभाजित करना, जो सामान्य छूट नीति का प्रतिनिधित्व करता है।
- सिर्फ NoneDiscountPolicy के लिए इंटरफ़ेस जोड़ने से बढ़ी हुई जटिलता की तुलना में दक्षता कम हो सकती है।
- आपको यह समझना चाहिए कि कार्यान्वयन से संबंधित सभी चीजें ट्रेडऑफ़ का विषय हो सकती हैं। दूसरे शब्दों में, आपके द्वारा लिखे गए प्रत्येक कोड का एक उचित कारण होना चाहिए।
कोड पुन: उपयोग
- वंशानुगत का उपयोग कोड को पुन: उपयोग करने के लिए किया जा सकता है।
- हालाँकि, कोड को पुन: उपयोग करने के लिए, वंशानुगत के बजाय रचना का उपयोग करना बेहतर है।
- वर्तमान कोड में, Movie DiscountPolicy के कोड का पुन: उपयोग करने का तरीका रचना है।
- यदि आप Movie को सुपरक्लास के रूप में रखते हैं और इसे AmountDiscountMovie और PercentDiscountMovie में विभाजित करते हैं, तो इसे वंशानुगत का उपयोग करके कहा जाएगा।
वंशानुगत
- वंशानुगत के नुकसान
- यह एनकैप्सुलेशन का उल्लंघन करता है।
- आपको मूल वर्ग की आंतरिक संरचना को अच्छी तरह से जानना होगा।
- मूल वर्ग को बदलने पर संतान वर्ग भी बदलने की संभावना अधिक होती है।
- यह डिजाइन को कम लचीला बनाता है।
- यह मूल वर्ग और संतान वर्ग के बीच संबंध को संकलन समय पर निर्धारित करता है।
- निष्पादन समय पर ऑब्जेक्ट के प्रकार को बदलना संभव नहीं है।
- हालाँकि, रचना आपको changeDiscountPolicy() जैसे मेथड का उपयोग करके निष्पादन समय पर उदाहरण को बदलने की अनुमति देती है।
- यह एनकैप्सुलेशन का उल्लंघन करता है।
रचना
- इंटरफ़ेस में परिभाषित संदेशों के माध्यम से कोड का पुन: उपयोग करने की विधि को रचना कहा जाता है।
- यह एनकैप्सुलेशन को लागू करने और ढीले युग्मन को बनाए रखने में सक्षम है।
- बहुरूपता के लिए इंटरफ़ेस का पुन: उपयोग करने के मामले में, आपको वंशानुगत और रचना को संयोजित करके उपयोग करना चाहिए।
- उदाहरण के लिए, DiscountPolicy इंटरफ़ेस को उप-कार्यान्वयन को लागू करने के लिए वंशानुगत का उपयोग करने की आवश्यकता है।
स्रोत
- ऑब्जेक्ट