Try using it in your preferred language.

English

  • English
  • 汉语
  • Español
  • Bahasa Indonesia
  • Português
  • Русский
  • 日本語
  • 한국어
  • Deutsch
  • Français
  • Italiano
  • Türkçe
  • Tiếng Việt
  • ไทย
  • Polski
  • Nederlands
  • हिन्दी
  • Magyar
translation

यह एक AI अनुवादित पोस्ट है।

제이온

[ऑब्जेक्ट] अध्याय 2. ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग

  • लेखन भाषा: कोरियाई
  • आधार देश: सभी देश country-flag

भाषा चुनें

  • हिन्दी
  • English
  • 汉语
  • Español
  • Bahasa Indonesia
  • Português
  • Русский
  • 日本語
  • 한국어
  • Deutsch
  • Français
  • Italiano
  • Türkçe
  • Tiếng Việt
  • ไทย
  • Polski
  • Nederlands
  • Magyar

durumis AI द्वारा संक्षेपित पाठ

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

फिल्म बुकिंग सिस्टम


आवश्यकताओं की समीक्षा

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


ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की ओर

सहयोग, ऑब्जेक्ट, क्लास

  • ऑब्जेक्ट ओरिएंटेड ऑब्जेक्ट का उन्मुखीकरण है।
    • क्लास को परिभाषित करने के बाद, आपको यह नहीं सोचना चाहिए कि क्लास के लिए कौन से गुण और विधियाँ आवश्यक हैं।
    • आपको यह तय करना होगा कि किन वस्तुओं में कौन सी स्थिति और व्यवहार है।
    • आपको वस्तुओं को स्वतंत्र इकाइयों के बजाय एक सहयोगी समुदाय के सदस्य के रूप में देखना चाहिए।


डोमेन संरचना का पालन करने वाला प्रोग्राम संरचना

  • डोमेन समस्या को हल करने के लिए उपयोगकर्ता द्वारा प्रोग्राम का उपयोग किए जाने वाले क्षेत्र को संदर्भित करता है।

Untitled

  • सामान्य तौर पर, क्लास के नाम को संबंधित डोमेन अवधारणा के नाम के समान या कम से कम समान होना चाहिए।
  • क्लास के बीच के रिश्ते को भी जितना हो सके डोमेन अवधारणाओं के बीच के रिश्ते के समान बनाया जाना चाहिए ताकि प्रोग्राम की संरचना को समझना और अनुमान लगाना आसान हो सके।


क्लास लागू करना

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


स्वायत्त ऑब्जेक्ट

  • ऑब्जेक्ट को स्वायत्त ऑब्जेक्ट होना चाहिए जिसमें स्थिति और व्यवहार हो।
  • डेटा और कार्यों को ऑब्जेक्ट के अंदर एक साथ बाँधने को एनकैप्सुलेशन कहा जाता है।
  • एक्सेस कंट्रोल के माध्यम से बाहरी हस्तक्षेप को कम करके, ऑब्जेक्ट अपने स्वयं के व्यवहार को निर्धारित करने में सक्षम हो जाते हैं।
  • इंटरफ़ेस और कार्यान्वयन के पृथक्करण का सिद्धांत ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के लिए पालन किया जाने वाला एक प्रमुख सिद्धांत है।
    • सार्वजनिक इंटरफ़ेस: वह भाग जो बाहरी रूप से सुलभ है
    • कार्यान्वयन: वह भाग जो केवल आंतरिक रूप से सुलभ है


प्रोग्रामर की स्वतंत्रता

  • प्रोग्रामर की भूमिका को क्लास लेखक और क्लाइंट प्रोग्रामर में विभाजित किया गया है।
    • क्लास लेखक एक नया डेटा प्रकार जोड़ता है
    • क्लाइंट प्रोग्रामर क्लास लेखक द्वारा जोड़े गए डेटा प्रकार का उपयोग करता है
  • कार्यान्वयन छिपाना
    • क्लास लेखक क्लाइंट प्रोग्रामर को केवल आवश्यक भाग प्रदान करके आंतरिक कार्यान्वयन को छिपा सकता है।
    • क्लाइंट प्रोग्रामर को केवल इंटरफ़ेस जानने की आवश्यकता है, जिससे ज्ञान की मात्रा कम हो जाती है।


सहयोग करने वाली वस्तुओं का समुदाय

  • पैसे का प्रतिनिधित्व करने के लिए, केवल Long प्रकार के एक चर को घोषित करने के बजाय, Money जैसे ऑब्जेक्ट में इसे पैक करना बेहतर है। ऑब्जेक्ट का उपयोग करके, अर्थ संचार बेहतर होता है, और दोहराए गए संचालन को एक स्थान पर किया जा सकता है।
  • सिस्टम के किसी विशिष्ट कार्य को लागू करने के लिए वस्तुओं के बीच होने वाली बातचीत को सहयोग कहा जाता है।


सहयोग के बारे में एक छोटी कहानी

  • ऑब्जेक्ट एक दूसरे के साथ बातचीत करने का एकमात्र तरीका संदेश भेजना या प्राप्त करना है।
  • प्राप्त संदेश को संसाधित करने के लिए अपने स्वयं के तरीके को विधि कहा जाता है।
  • संदेश और विधि को अलग करना महत्वपूर्ण है, यहीं से बहुरूपता की अवधारणा शुरू होती है।


छूट शुल्क प्राप्त करना

छूट शुल्क गणना के लिए सहयोग शुरू करना

  • Movie क्लास में छूट नीति के बारे में विस्तृत तर्क नहीं है, और इसे DiscountPolicy इंटरफ़ेस को सौंपा गया है। वंशानुगत और बहुरूपता, अमूर्तता का उपयोग करना वास्तव में महत्वपूर्ण है।


छूट नीति और छूट की शर्तें

Untitled


वंशानुगत और बहुरूपता

कंपाइल समय निर्भरता और रनटाइम निर्भरता

  • कोड की निर्भरता और निष्पादन समय पर निर्भरता अलग-अलग हो सकती है।
  • दोनों के बीच निर्भरता जितनी अधिक अलग होगी, कोड को समझना उतना ही कठिन होगा, लेकिन कोड अधिक लचीला और विस्तार योग्य हो जाएगा।


अंतर द्वारा प्रोग्रामिंग

  • वंशानुगत आपको आसानी से और जल्दी से नई कक्षाएँ जोड़ने की अनुमति देता है जो मौजूदा कक्षाओं पर आधारित हैं, और आप मूल वर्ग के कार्यान्वयन का पुन: उपयोग कर सकते हैं।
  • नई कक्षाएँ बनाने की विधि, जो केवल मूल वर्ग से भिन्न होती हैं, को अंतर द्वारा प्रोग्रामिंग कहा जाता है।


वंशानुगत और इंटरफ़ेस

  • वंशानुगत मूल वर्ग द्वारा प्रदान किए गए सभी इंटरफ़ेस को संतान वर्ग को विरासत में प्राप्त करने की अनुमति देता है।
  • इंटरफ़ेस ऑब्जेक्ट द्वारा समझी जाने वाली संदेशों की सूची को परिभाषित करता है।
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 में विभाजित करना, जो सामान्य छूट नीति का प्रतिनिधित्व करता है।

Untitled

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


कोड पुन: उपयोग

  • वंशानुगत का उपयोग कोड को पुन: उपयोग करने के लिए किया जा सकता है।
  • हालाँकि, कोड को पुन: उपयोग करने के लिए, वंशानुगत के बजाय रचना का उपयोग करना बेहतर है।
  • वर्तमान कोड में, Movie DiscountPolicy के कोड का पुन: उपयोग करने का तरीका रचना है।
  • यदि आप Movie को सुपरक्लास के रूप में रखते हैं और इसे AmountDiscountMovie और PercentDiscountMovie में विभाजित करते हैं, तो इसे वंशानुगत का उपयोग करके कहा जाएगा।


वंशानुगत

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


रचना

  • इंटरफ़ेस में परिभाषित संदेशों के माध्यम से कोड का पुन: उपयोग करने की विधि को रचना कहा जाता है।
  • यह एनकैप्सुलेशन को लागू करने और ढीले युग्मन को बनाए रखने में सक्षम है।
  • बहुरूपता के लिए इंटरफ़ेस का पुन: उपयोग करने के मामले में, आपको वंशानुगत और रचना को संयोजित करके उपयोग करना चाहिए।
    • उदाहरण के लिए, DiscountPolicy इंटरफ़ेस को उप-कार्यान्वयन को लागू करने के लिए वंशानुगत का उपयोग करने की आवश्यकता है।


स्रोत

  • ऑब्जेक्ट
제이온
제이온
제이온
제이온
[इफ़ेक्टिव जावा] आइटम 6. अनावश्यक ऑब्जेक्ट निर्माण से बचें जावा में अनावश्यक ऑब्जेक्ट निर्माण को कम करके प्रदर्शन को बेहतर बनाने के तरीकों के बारे में बताता है। स्ट्रिंग, बूलियन, रेगुलर एक्सप्रेशन, व्यू ऑब्जेक्ट, ऑटो बॉक्सिंग जैसे विभिन्न उदाहरणों के साथ ऑब्जेक्ट पुन: उपयोग के महत्व पर जोर दिया गया है। खासकर रक्ष

28 अप्रैल 2024

[इफ़ेक्टिव जावा] आइटम 5. संसाधनों का उल्लेख न करें, डिपेंडेंसी इंजेक्शन का उपयोग करें यदि कोई वर्ग आंतरिक रूप से एक से अधिक संसाधनों पर निर्भर करता है, तो सिंगलटन और स्टैटिक उपयोगिता वर्गों के बजाय डिपेंडेंसी इंजेक्शन का उपयोग करना बेहतर होता है। डिपेंडेंसी इंजेक्शन के माध्यम से, आप वर्ग की लचीलापन, पुन: उपयोग और परीक्षण क्षमता में सुधार क

28 अप्रैल 2024

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

25 अप्रैल 2024

#मार्केटिंग - बिक्री सूत्र जानने पर कठिन बिक्री बैठक आसान हो जाती है बिक्री बैठकों की प्रभावी ढंग से तैयारी और उनमें भाग लेने के तरीके जानें। डेटाबेस, औसत ऑर्डर वैल्यू और क्लोजिंग दर से बनी बिक्री सूत्र का उपयोग करके बैठक के विषय को निर्धारित करें, और प्रत्येक कारक के विश्लेषण के माध्यम से समस्याओं और समाधानों को प्रस्तुत
30대의 존버살이를 씁니다.
30대의 존버살이를 씁니다.
30대의 존버살이를 씁니다.
30대의 존버살이를 씁니다.

17 जनवरी 2024

शेयर चुनते समय स्टाइल से भी ज़्यादा मायने रखते हैं ये 3 मुद्दे: 1) अच्छी कंपनी की, 2) अच्छा शेयर, 3) अच्छी कीमत पर ग्रोथ स्टॉक बनाम वैल्यू स्टॉक मायने नहीं रखता. अच्छी कंपनी का अच्छा शेयर अच्छी कीमत पर खरीदना ही असली निवेश का राज है. बढ़ती कंपनी, विश्वसनीय प्रबंधन और उचित मूल्यांकन ही मुख्य हैं। निजी निवेशकों के लिए भी मूल्यांकन के प्रति लचीला रवैया होना ज़रूरी है।
고집스런가치투자
고집스런가치투자
고집스런가치투자
고집스런가치투자

3 अप्रैल 2024

[गैर-प्रमुख, डेवलपर के रूप में जीवित रहना] 14. नौसिखिए डेवलपर द्वारा अक्सर पूछे जाने वाले तकनीकी साक्षात्कार सामग्री का सारांश नौसिखिए डेवलपर के लिए तकनीकी साक्षात्कार की तैयारी के लिए एक मार्गदर्शिका। मुख्य मेमोरी क्षेत्र, डेटा संरचना, RDBMS और NoSQL, प्रक्रियात्मक और ऑब्जेक्ट-ओरिएंटेड, ओवरराइडिंग और ओवरलोडिंग, पेज रिप्लेसमेंट एल्गोरिदम, प्रक्रिया और थ्रेड, OSI 7 लेयर, TCP और UD
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자

3 अप्रैल 2024

भौतिक डेटा मॉडलिंग भौतिक डेटा मॉडलिंग संबंधपरक डेटाबेस की तालिकाओं को वास्तविक उपयोग के लिए डिज़ाइन करने की प्रक्रिया है, जिसमें भंडारण स्थान दक्षता, डेटा विभाजन, इंडेक्स डिज़ाइन आदि शामिल हैं, जिसका उद्देश्य प्रदर्शन अनुकूलन है। धीमी क्वेरी विश्लेषण, इंडेक्स उपयोग, कैशे अन
제이의 블로그
제이의 블로그
제이의 블로그
제이의 블로그
제이의 블로그

9 अप्रैल 2024

अनटच ट्रेंड? समाज के गहन ढाँचे पर ध्यान दें। -3 कोविड-19 के बाद बदलते समाज के ढाँचे और इसके अनुसार मार्केटिंग रणनीतियों में बदलाव पर नज़र डालते हैं। Zugehörigkeit, Alltag, Umfang, सार्वजनिक स्थानों पर उपस्थिति जैसे चार गहन ढाँचों का विश्लेषण करते हैं और यह बताते हैं कि ब्रांड इन परिवर्तनों का सामना कैस
Byungchae Ryan Son
Byungchae Ryan Son
Byungchae Ryan Son
Byungchae Ryan Son

30 अप्रैल 2024

ऑटोमेटिक ट्रेडिंग प्रोग्राम में सुधार के लिए विचार यह एक ग्रिड ट्रेडिंग ऑटोमेशन प्रोग्राम के लिए सुधार के विचारों का परिचय देता है, जिसमें बड़े आयोजनों के प्रबंधन, निवेश निधि प्रबंधन तर्क, शॉर्ट पोजीशन को जोड़ने जैसे सुझाव दिए गए हैं। विशेष रूप से, यह बताता है कि होल्डिंग फ़ंक्शन के माध्यम से, गिरने पर बे
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마

21 अप्रैल 2024