ऑब्जेक्ट ओरिएंटेड डिजाइन

Question

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

यह उन कलाकारों के साथ एक क्लास आरेख उत्पन्न करता है जिनके पास सभी कार्य हैं, और आंतरिक कक्षाएं जिनमें केवल डेटा है।

यह सही प्रतीत नहीं होता है। वस्तुओं का मॉडल कैसे करें इस बारे में सोचने का एक और तरीका है?

प्रश्न 2। इसके अलावा, पाठ्यक्रम अपने वास्तविक दुनिया के समकक्षों के बाद वस्तुओं को मॉडलिंग पर जोर देता है लेकिन यह आवश्यक नहीं है कि डोमेन मॉडल में यह समझदारी हो। अर्थात। एक चिकित्सा अभ्यास में, उनके पास Patient: CreateAppointment(), CancelAppointment() है लेकिन ऐसा नहीं है कि इसे कैसे कार्यान्वित किया जाएगा (आप इसके बजाय नियुक्ति संग्रह को संशोधित करेंगे)। क्या इस बारे में सोचने का कोई और तरीका है?

उदाहरण Q1

सचिव: RecordAppointment(), RecordAppointmentCancellation()

नियुक्ति: समय, तिथि, ... (कोई तरीकों)

उदाहरण Q2

डॉक्टर: SeePatient()

जबकि SeePatient एक यूज़-केस है, यह वास्तविक वर्ग पर एक विधि के लिए कोई मतलब नहीं है। आप इसके बारे में कैसे सोचते हैं?

Answer 1

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

वे क्या एक वस्तु अपने विधि के लिए क्या कर सकते हैं के बारे में सोच की सलाह देते हैं, और क्या अपनी जिम्मेदारियों को उसके गुण

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

उदाहरण के लिए दिशानिर्देश इस वस्तु के साथ बहुत अच्छी तरह से काम करता है:

public class Tree 
{ 
    public int Height { get; set; } 
    public void Grow(int byHowMuch) 
    { 
     Height += byHowMuch; 
    } 
} 

हालांकि यह निश्चित रूप से बिल अपने दाहिने फिट बैठता है लगता है कि यह "लगता है" नहीं है सही:

public class Secretary 
{ 
    public void MakeAppoinment(Patient patient) 
    { 
     //make the appointment 
    } 
} 

तो समाधान क्या है? यह आपके लिए सिखाया जा रहा है और इसे लागू करने का विषय है। सीखना और समझना design patterns विकासशील प्रणालियों के साथ बहुत मदद करेगा जो एक वृक्ष से अधिक कार्यात्मक हैं जो जानता है कि कैसे बढ़ना है।

सिफारिश की पठन:

• Design Patterns: Elements of Reusable Object-Oriented Software (भी चार या GOF के गिरोह के रूप में जाना)
• Head First Design Patterns
• Head First Object-Oriented Analysis and Design

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

• Is Single Responsibility Principle a rule of OOP?
• Are there any rules for OOP?
• why is OOP hard for me?

इसके अतिरिक्त, यह बाहर की जाँच करने के लिए अच्छा होगा:

स्टैक ओवरफ़्लो जो काम का हो सकता है कुछ संबंधित प्रश्नों से भी अधिक है:

• Single responsibility principle
• Don't repeat yourself
• PrinciplesOfOod

अंत में, क्या एक आवेदन वस्तु उन्मुख करता है की एक एकल परिभाषा नहीं है। आप पैटर्न, सिद्धांत आदि कैसे लागू करते हैं, आपके कार्यक्रम को परिभाषित करेंगे। तथ्य यह है कि आप खुद से ये प्रश्न पूछ रहे हैं कि आप सही रास्ते पर हैं।

Answer 2

Q1 क्या आपकी वस्तुओं की संभावित जिम्मेदारियों को प्राधिकरण या अनुबंध आवश्यकताओं के रूप में व्याख्या किया जाना चाहिए, जैसा कि उन्हें क्या करना चाहिए? इसलिए, अपने क्यू 2 से एक चिकित्सा उदाहरण लेने के लिए, एक ऑब्जेक्ट शेड्यूलर भूमिका (लगता है सी #/जावा इंटरफेस, या ओबीजे-सी प्रोटोकॉल) के साथ एक वस्तु CanEditAppointments या EditsAppointments के आसपास विशेषता है।

Q2 एक उपयोग के मामले दृष्टिकोण से, एक मरीज को एक नियुक्ति बनाने के लिए सक्षम हो सकता है, और इसलिए आप CreateAppointment के लिए एक विधि के साथ अपने ऑब्जेक्ट मॉडल में एक रोगी को लागू हो सकता है()। लेकिन, encapsulation के मामले में, आप CreateAppointment() में एक अपॉइंटमेंट ऑब्जेक्ट को तुरंत चालू कर देंगे, और उसके बाद अपना समय, दिनांक, रोगी, चिकित्सक इत्यादि सेट करने के लिए अपॉइंटमेंट ऑब्जेक्ट पर विधियों को सेट करें या सेट करें

और क्योंकि नियुक्ति संग्रह डेटाबेस की तरह स्थायी भंडारण होने की संभावना है, यह संभवतः संग्रह में जोड़ने के लिए अपॉइंटमेंट ऑब्जेक्ट की ज़िम्मेदारी होगी (नियुक्ति.Schedule() डेटाबेस में स्वयं को सहेजने के लिए आपके डेटा एक्सेस लेयर के माध्यम से जाता है)।

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

Answer 3

आप सही हैं कि कई मामलों में उच्च क्रम की चीजें हैं जो अधिक स्वाभाविक रूप से व्यवहार, जैसे सिस्टम या उपयोगकर्ता होते हैं।

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

जावा में ऐसे वर्ग बनाने के लिए विनिर्देश और मानक हैं, अर्थात् ईजेबी में स्टेटलेस सत्र बीन। स्प्रिंग फ्रेमवर्क में स्टीरियोटाइप "सेवा" के साथ समान विचार हैं जिन्हें कक्षाओं में व्यावसायिक तर्क के लिए मुखौटा के रूप में टैग करने के लिए लागू किया जा सकता है।

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

DCI Architecture इसका औपचारिकरण है और ऐसा करने का प्रयास है, लेकिन साथ ही ऑब्जेक्ट ओरिएंटेशन के लिए सही रहने की कोशिश कर रहा है, क्योंकि ऑब्जेक्ट्स को व्यवहार की आवश्यकता होती है।

Answer 4

मुझे अभी भी भ्रम का अनुभव है: "क्या मैं आपको कुछ और करने के लिए कह रहा हूं" या "क्या मैं किसी और से मुझसे कुछ पूछ रहा हूं"?

शायद आपको बस बार्बी, या जीआई खेलना है। जो ऑब्जेक्ट इंटरैक्शन को समझने के लिए है और जहां जिम्मेदारियां जाती हैं। भारत-सरकार जो घायल हो गया (या बार्बी ने नाखून तोड़ दिया) तो वह डॉ के कार्यालय को बुलाता है। "अरे डॉक्टर, यह जो है, मुझे नियुक्ति की ज़रूरत है।" तो आप, बच्चे, बार्बी को चिकित्सक के पास जाने के लिए कहें, जिसे कॉल करने और कॉल करने के लिए डॉक्टर को जानने की आवश्यकता है - एक संदर्भ और सार्वजनिक MakeAppointment() विधि। डॉ। कार्यालय को किताबों पर नियुक्ति करने की जरूरत है - यह स्वयं की बुकएपॉइंटमेंट() विधि है जो नियुक्ति अनुरोधों को संभालने के लिए कार्यालय की प्रक्रिया है।

public abstract GenderAppropriateDolly { 
    protected DrOffice Drkilldare; 
    public override MakeAppointment() {throw new NotImplementedException();} 
} 


public class GIJoe : GenderAppropriateDolly { 
    DrKilldare = new DrOffice(); 
    List<Appointment> myAppointments = new List<Appointment>; 

    public void MakeAppointment() { 
     myAppointments.Add(DrKilldare.BookAppointment(this)); 
    } 
} 

public class DrOffice { 
    List<Appointment> officeAppointments = new List<Appointments>; 

    public Appointment BookAppointment(GenderAppropriateDolly forWhom) { 
     Appointment newappt = new Appointment(formWhom); 
     this.Appointments.Add(newappt); 

     return newappt; 
    }  
} 

public class Kid { 
    GenderAppropriateDolly myRoleModel = new GIJoe(); 

    // Joe got wounded so ... 
    myRoleModel.MakeAppointment(); 
}