क्या OO डिज़ाइन का उपयोग करना है (क्या कोई डिज़ाइन पैटर्न है)?

Question

मेरे पास दो वस्तुएं हैं जो एक 'बार / क्लब' का प्रतिनिधित्व करती हैं (ऐसी जगह जहां आप शराब पीते हैं / सोशलाइज करते हैं)।

एक परिदृश्य में मुझे बार का नाम, पता, दूरी, स्लोगन चाहिए

दूसरे परिदृश्य में मुझे बार का नाम, पता, वेबसाइट यूआरएल, लोगो चाहिए

इसलिए मुझे एक ही चीज़ का प्रतिनिधित्व करने वाली दो वस्तुएँ मिली हैं, लेकिन विभिन्न क्षेत्रों के साथ।

मुझे अपरिवर्तनीय वस्तुओं का उपयोग करना पसंद है, इसलिए सभी फ़ील्ड कंस्ट्रक्टर से सेट किए गए हैं ।

एक विकल्प दो कंस्ट्रक्टर का है और दूसरे क्षेत्रों को शून्य करना है:

class Bar {
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
          this.url = null;
     }

     public Bar(String name, Url url){
          this.name = name;
          this.distance = null;
          this.url = url;
     }

     // getters
}

मुझे यह पसंद नहीं है क्योंकि जब आप गेटर्स का उपयोग करते हैं तो आपको चेक को शून्य करना होगा

मेरे वास्तविक उदाहरण में पहले परिदृश्य में 3 फ़ील्ड हैं और दूसरे परिदृश्य में लगभग 10 हैं, इसलिए यह एक वास्तविक दर्द होगा जिसमें दो कंस्ट्रक्टर होंगे , फ़ील्ड की मात्रा को मुझे शून्य घोषित करना होगा और फिर जब ऑब्जेक्ट उपयोग में होगा तो आप ' t पता है कि Barआप कहाँ उपयोग कर रहे हैं और इसलिए कौन से क्षेत्र अशक्त होंगे और क्या नहीं।

मेरे पास अन्य विकल्प क्या हैं?

दो कक्षाएं BarPreviewऔर कहा जाता है Bar?

कुछ प्रकार की विरासत / इंटरफ़ेस?

कुछ और जो कमाल है?

Comments

वाह, आप वास्तव Barमें एक पहचानकर्ता के रूप में एक वैध उपयोग के साथ आए हैं !

— मेसन व्हीलर

यदि आप कुछ गुण साझा कर रहे हैं, तो एक विकल्प आधार वर्ग को लागू करना होगा।

— युसुबोव

मैने इसके बारे में कभी नहीं सोचा था। मेरे बार / फू डॉग पार्लर के लिए किसी भी प्रकार का कोड लिखना वास्तव में भ्रामक हो सकता है।

— एरिक रेपेन

चलो अनुमान लगाओ खेल खेलते हैं

— gnat

@gnat लोग कैसे अनुमान लगा रहे हैं। आपके लिंक उद्धरण से: You should only ask practical, answerable questions based on actual problems that you face.और ठीक यही यहाँ हो रहा है

— ब्लंडेल

Answer 1

मेरे विचार:

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

हालाँकि, आपके पास दो स्थान हैं जिनमें इस बार ऑब्जेक्ट के डेटा की आवश्यकता है, और दोनों को केवल एक सबसेट की आवश्यकता है (और आप नहीं चाहते कि डेटा को बदला जाए)। सामान्य उत्तर "डेटा ट्रांसफर ऑब्जेक्ट" या डीटीओ है; एक POJO (सादा ol 'जावा ऑब्जेक्ट) अचल संपत्ति पाने वालों से युक्त है। इन डीटीओ का उत्पादन मुख्य बार डोमेन ऑब्जेक्ट पर एक विधि को कॉल करके किया जा सकता है: "toScenario1DTO ()" और "toScenario2DTO ()"; परिणाम एक हाइड्रेटेड डीटीओ होने का अर्थ है (जिसका अर्थ है कि आपको केवल एक ही स्थान पर लंबे, जटिल कंस्ट्रक्टर का उपयोग करना होगा)।

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

EDIT: एक उदाहरण प्रदान करने के लिए:

public class Bar {
     private String name;
     private Address address; 
     private Distance distance;
     private Url url;
     private Image logo;
     private string Slogan;

     public OnlineBarDto ToOnlineDto()
     {
         return new OnlineBarDto(name, address, url, logo);
     }

     public PhysicalBarDto ToPhysicalDto()
     {
         return new PhysicalBarDto(name, address, distance, slogan);
     }

     public void UpdateFromDto(PhysicalBarDto dto)
     {
         //validation logic here, or mixed into assignments

         name = dto.Name;
         address = dto.Address;
         distance = dto.Distance;
         slogan = dto.Slogan;
     }

     public void UpdateFromDto(OnlineBarDto dto)
     {
         //Validate DTO fields before performing assignments

         name = dto.Name;
         address = dto.Address;
         url= dto.Url;
         logo = dto.Logo;
     }

     // getters/setters - As necessary within the model and data access layers;
     // other classes can update the model using DTOs, forcing validation.
}

public class PhysicalBarDto
{
     public final String Name;
     public final Address Address;
     public final Distance Distance;
     public final String Slogan;

     public PhysicalBarDto(string Name, Address address, Distance distance, string slogan) 
     { //set instance fields using parameter fields; you know the drill }
}

public class OnlineBarDto
{
     public final String Name;
     public final Address Address;
     public final Image Logo;
     public final Url Url;

     public OnlineBarDto(string Name, Address address, Url url, Image logo) 
     { //ditto }
}

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

Comments

क्या संक्षिप्त DTO के लिए खड़ा है? मुझे काफी कुछ नहीं मिला जो आपका कहना है कि आप इसे एक उदाहरण के रूप में डाल सकते हैं। फी , डेटा एक सर्वर से आता है, इसलिए एक बार या तो इस वर्ग का रूप 'हाइड्रेटेड' हो जाता है, तो खेतों को बदलने की आवश्यकता नहीं होगी, बस यूआई पर प्रदर्शित करने के लिए उपयोग किया जाता है

— ब्लंडेल

डीटीओ "डेटा ट्रांसफर ऑब्जेक्ट" के लिए खड़ा है, और "रिच" डोमेन लेयर से यूआई जैसी ऊपरी परतों तक डेटा ले जाने के लिए उपयोग की जाने वाली बहुत ही सरल संरचना के डेटा वर्ग को संदर्भित करता है, वास्तविक डोमेन परत को यूआई को उजागर किए बिना (परिवर्तन की अनुमति देता है) जब तक डीटीओ को बदलना नहीं पड़ता तब तक यूआई को प्रभावित किए बिना डोमेन पर बनाया जाएगा।)

— कीथ्स

उत्परिवर्तन का कोई असर नहीं होता है इसलिए संशोधन या दृढ़ता पर कभी भी।

@JarrodRoberson - क्या आप मजाक कर रहे हैं? यदि कोई वर्ग अपरिवर्तनीय है (तात्कालिकता के बाद इन-प्लेस नहीं बदला जा सकता है) तो डेटा लेयर में डेटा में बदलाव करने का एकमात्र तरीका अलग-अलग सदस्यों के साथ एक ही रिकॉर्ड (एक ही पीके) का प्रतिनिधित्व करने वाला एक नया उदाहरण बनाना है। जबकि "म्यूटिंग" तरीके जो एक नया उदाहरण उत्पन्न करते हैं, इसे आसान बना सकते हैं, फिर भी संशोधन और दृढ़ता पर इसका बहुत बड़ा असर पड़ता है।

— कीथ

@JarrodRoberson समुदाय को सुनें। तुम गलत हो। । वास्तव में इस पूरे उत्तर की आधी टिप्पणियों से पता चलता है कि हमें बोर्ड के आसपास कुछ बुनियादी OO की स्कूली शिक्षा की आवश्यकता है - यह बहुत ही घृणित है ..

— David Cowden

Answer 2

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

Comments

आप कहते हैं कि लेकिन क्या आप Barकक्षा का उपयोग करके एक उदाहरण दे सकते हैं

— ब्लंडेल

Answer 3

बिल्डर पैटर्न (यह करने के लिए या कुछ और करीब) उपयोग की यहाँ हो सकता है।

अपरिवर्तनीय वस्तुओं का होना एक सराहनीय बात है, लेकिन वास्तविकता यह है कि जावा में परावर्तन के साथ, वास्तव में कुछ भी नहीं है;

Comments

मैं देख सकता हूं कि कैसे HawaiianPizzaBuilderकाम करता है क्योंकि इसके लिए जिन मूल्यों की आवश्यकता होती है वे हार्डकोडेड हैं। हालाँकि यदि आप मानों को पुनः प्राप्त कर लेते हैं और किसी निर्माणकर्ता को पास कर देते हैं तो आप इस पैटर्न का उपयोग कैसे कर सकते हैं? HawaiianPizzaBuilderअभी भी सभी टिककर खेल है कि होता है SpicyPizzaBuilderतो अशक्त संभव है है। जब तक आप इसे @ जारोड्स के साथ नहीं मिलाते Null Object Pattern। एक कोड उदाहरण के साथ Barआपकी बात पूरी होगी

— Blundell

+1 मैं इस तरह के मामलों में बिल्डर का उपयोग करता हूं, एक आकर्षण की तरह काम करता है - जिसमें शामिल है, लेकिन जब मैं यह चाहता हूं तो अशक्त के बजाय उचित चूक स्थापित करने तक सीमित नहीं है

— gnat

Answer 4

यहां मुख्य बिंदु यह है कि "बार" क्या है और आप इसे एक या दूसरे संदर्भ में कैसे उपयोग करते हैं , के बीच अंतर है।

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

(और भी गूढ़ होने के लिए: प्रत्येक बार का उदाहरण उस वस्तु की तुलना में एक अलग जीवनचक्र होता है जो आपके कार्यक्रम के चलने पर उसका प्रतिनिधित्व करता है। भले ही आपके पास एक स्रोत कोड हो जो उस उदाहरण को बनाता है, इसका मतलब है कि बार इकाई जैसा कि वर्णित है, "मौजूद है।" "अपने स्रोत कोड में निष्क्रिय स्थिति में, और" जागृत "जब कोड वास्तव में इसे मेमोरी में बनाता है ...)

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

उत्तरार्द्ध को दो अलग-अलग इंटरफेस द्वारा दर्शाया जा सकता है , जिसमें आवश्यक पहुंच विधियाँ (getName (), getURL (), getDistance ()) शामिल हैं, और बार वर्ग को दोनों को लागू करना चाहिए। (और शायद "दूरी" "स्थान" में बदल जाएगी, और getDistance () किसी अन्य स्थान से गणना हो जाती है :-))

लेकिन निर्माण बार इकाई के लिए है न कि आप उस इकाई का उपयोग करना चाहते हैं: एक निर्माता, सभी क्षेत्र।

संपादित करें: मैं कोड लिख सकता हूँ! :-)

public interface Place {
  String getName();
  Address getAddress();
}

public interface WebPlace extends Place {
   URL getUrl();
   Image getLogo();
}

public interface PhysicalPlace extends Place {
  Double getDistance();
  Slogon getSlogon();
}

public class Bar implements WebPlace, PhysicalPlace {
  private final String name;
  private final Address address;
  private final URL url;
  private final Image logo;
  private final Double distance;
  private final Slogon slogon;

  public Bar(String name, Address address, URL url, Image logo, Double distance, Slogon slogon) {
    this.name = name;
    this.address = address;
    this.url = url;
    this.logo = logo;
    this.distance = distance;
    this.slogon = slogon;
  }

  public String getName() { return name; }
  public Address getAddress() { return address; }
  public Double getDistance() { return distance; }
  public Slogon getSlogon() { return slogon; }
  public URL getUrl() { return url; }
  public Image getLogo() { return logo; } 
}

Answer 5

उपयुक्त पैटर्न

आप जिस चीज की तलाश कर रहे हैं, वह आमतौर पर के रूप में संदर्भित है Null Object Pattern। यदि आपको वह नाम पसंद नहीं है जिसे आप इसे कॉल कर सकते हैं Undefined Value Pattern, तो वही शब्दार्थ भिन्न लेबल। कभी-कभी इस पैटर्न को कहा जाता है Poison Pill Pattern।

इन सभी मामलों में, ऑब्जेक्ट एक अशक्त है या Default Valueइसके बजाय null. It doesn't replace the semantic ofnull null के लिए खड़ा है but makes it easier to work with the data model in a more predictable way because`अब एक वैध स्थिति नहीं होनी चाहिए ।

यह एक पैटर्न है जहां आप किसी दिए गए वर्ग के एक विशेष उदाहरण को एक के nullरूप में अन्यथा विकल्प का प्रतिनिधित्व करने के लिए आरक्षित करते हैं Default Value। इस तरह से आपको जाँच नहीं करनी है null, आप अपने ज्ञात NullObjectउदाहरण के विरुद्ध पहचान की जाँच कर सकते हैं । आप सुरक्षित रूप से इस पर और इसके बारे में चिंता किए बिना तरीकों को कॉल कर सकते हैं NullPointerExceptions।

इस तरह आप अपने nullअसाइनमेंट को अपने प्रतिनिधि NullObjectउदाहरणों से बदल देते हैं और आप काम कर जाते हैं।

उचित वस्तु उन्मुख विश्लेषण

इस तरह आपके पास Interfaceबहुरूपता के लिए एक आम हो सकता है और अभी भी इंटरफ़ेस के विशिष्ट कार्यान्वयन में डेटा की अनुपस्थिति के बारे में चिंता करने से सुरक्षा है। तो कुछ Barमें वेब उपस्थिति नहीं हो सकती है, और कुछ में निर्माण के समय स्थान डेटा नहीं हो सकता है। Null Object Patterआपको इनमें से प्रत्येक के लिए एक डिफ़ॉल्ट मान प्रदान करता है जो markerउस डेटा के लिए है जो एक ही बात कहता है, यहां कुछ भी आपूर्ति नहीं की गई है, बिना NullPointerExceptionसभी जगह की जांच के साथ सौदा किए बिना ।

उचित वस्तु उन्मुख डिजाइन

पहले एक abstractकार्यान्वयन है जो सभी विशेषताओं का एक सुपर सेट है जो दोनों Barको Clubसाझा करता है।

class abstract Establishment 
{
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(final String name, final Distance distance, final Url url)
     {
          this.name = name;
          this.distance = distance;
          this.url = url;
     }

     public Bar(final String name, final Distance distance)
     {
          this(name, distance, Url.UNKOWN_VALUE);
     }

     public Bar(final String name, final Url url)
     {
          this(name, Distance.UNKNOWN_VALUE, url);
     }

     // other code
}

तो फिर तुम इस के उप वर्गों को लागू कर सकते Establishmentवर्ग और सिर्फ विशिष्ट बातें आप में से प्रत्येक के लिए की जरूरत को जोड़ने Barऔर Clubवर्गों है कि अन्य पर लागू नहीं होता।

हठ

यदि सही ढंग से निर्मित ये प्लेसहोल्डर ऑब्जेक्ट किसी विशेष हैंडलिंग के बिना भी डेटाबेस में पारदर्शी रूप से संग्रहीत किए जा सकते हैं।

भविष्य दृढ़

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

Answer 6

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

class EstablishmentInformation {
     private final String name;

     public EstablishmentInformation(String name){
          this.name = name;
     }

     // getters
}

class EstablishmentLocationInformation {
    EstablishmentInformation establishmentInformation;
     private final Distance distance;

     public EstablishmentLocationInformation (String name, Distance distance){
          this.establishmentInformation = new EstablishmentInformation(name)
          this.distance = distance;
     }
}

class EstablishmentWebSiteInformation {
    EstablishmentInformation establishmentInformation;
     private final Url url;

     public EstablishmentWebSiteInformation(String name, Url url){
          this.establishmentInformation = new EstablishmentInformation(name)
          this.url = url;
     }
}

Answer 7

इस पर काबू पाने के लिए वास्तव में कोई आवश्यकता नहीं है। आपको दो अलग-अलग प्रकार की वस्तु की आवश्यकता है? दो कक्षाएं बनाएं।

class OnlineBar {
     private final String name;
     private final Url url;
     public OnlineBar(String name, Url url){
          this.name = name;
          this.url = url;
     }

     // ...
}
class PhysicalBar {
     private final String name;
     private final Distance distance;
     public PhysicalBar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
     }
     //...
}

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

Comments

@ डेविड: ओह नोएस। उन्हें पसंद है, आम में एक पूरे डेटा सदस्य। आपातकालीन!

— डेडएमजी जूल

कुछ सामान्य इंटरफ़ेस के बिना इस समाधान में कोई बहुरूपता नहीं है , इनमें से किसी भी वर्ग को इस डिजाइन निर्णय के साथ दूसरे के लिए प्रतिस्थापित नहीं किया जा सकता है। ऐसा नहीं है कि उनके पास विशेषताओं का एक ही सुपरसेट नहीं है, यह है कि डिफ़ॉल्ट रूप से उनमें से कुछ विशेषताएँ हैं null। याद रखें का nullअर्थ डेटा की अनुपस्थिति है, विशेषता की अनुपस्थिति।

@DeadMG यह वास्तव में मूल वस्तुओं में साझा मूल्यों को समूहीकृत करने के विचार में एक अभ्यास है। यदि आपने इसे उस संदर्भ में प्रस्तावित किया है, तो आपके समाधान को पूरा क्रेडिट नहीं मिलेगा।

— डेविड काउडेन

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

— डेडएमजी

@DeadMG लेकिन प्रतिबिंब एक पर्यावरण का उपयोग करके क्रॉस प्लेटफॉर्म मोबाइल ऐप लिखने की कोशिश कर रहा है - यह काम कर सकता है, लेकिन यह सही नहीं है । प्रतिबिंब का उपयोग करके किसी विधि को कॉल करने का दंड सामान्य विधि कॉल की तुलना में कहीं भी 2 और 50 गुना धीमा है। परावर्तन एक इलाज नहीं है-सभी ..

— डेविड काउडन

Answer 8

इस प्रकार की समस्या वाले किसी भी व्यक्ति के लिए मेरा जवाब है कि इसे प्रबंधनीय चरणों में तोड़ दिया जाए ।

1. पहले सिर्फ दो कक्षाएं बनाएं BarOneऔर BarTwo(या दोनों Barको अलग-अलग पैकेज में कॉल करें )
2. अलग-अलग वर्गों के रूप में अपनी वस्तुओं का उपयोग शुरू करें अब के लिए कोड दोहराव के बारे में चिंता न करें। जब आप एक से दूसरे में क्रॉस ओवर (डुप्लिकेट तरीके) प्राप्त करेंगे, तो आप ध्यान देंगे
3. आपको पता चल सकता है कि वे किसी भी तरह से संबंधित नहीं हैं, और इसलिए आपको खुद सेbar पूछना चाहिए कि क्या वे दोनों वास्तव में एक हैं यदि आप अपमानजनक वर्ग का नाम नहीं बदलते हैं जो अब इसका प्रतिनिधित्व करता है।
4. यदि आपके सामान्य क्षेत्र या व्यवहार को आप फिर से interfaceया superclassसामान्य व्यवहार के साथ निकाल सकते हैं
5. एक बार आपके पास interfaceया superclassआप अपनी कार्यान्वयन वस्तुओं को बनाने builderया factoryपुनः प्राप्त करने के लिए एक या बना सकते हैं

(4 और 5 इस सवाल के अन्य उत्तर क्या हैं)

Answer 9

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

public class Location {
    protected final String name;
    protected final String address:

    public Location (String locName, String locAddress) {
    name = locName;
    address = locAddress
    }

}

public class Bar extends Location {
    private final int dist;
    private final String slogan;

    public Bar(String barName, String barAddress,
               int distance, String barSlogan) {
    super(locName, locAddress);
    dist = distance;
    slogan = barSlogan;
    }
}

और BarPreview वर्ग के लिए इसी तरह ।।

यदि यह आपको रात में बेहतर नींद देता है, तो मेरे कोड में स्थान के सभी उदाहरणों को कुछ भी बदल दें ।

Comments

ओपी चाहता है कि उदाहरण अपरिवर्तनीय हो , इसका मतलब है कि सब कुछ होना चाहिए final।

यह काम कर सकता है, आपको final@David फ़ील्ड की आवश्यकता है । Barनहीं होना चाहिए extend Locationकि हालांकि मतलब नहीं है। शायद Bar extends BaseBarऔर BarPreview extends BaseBarये नाम वास्तव में बहुत अच्छा नहीं लगता है, हालांकि, मैं कुछ और अधिक सुरुचिपूर्ण की उम्मीद कर रहा था

— ब्लंडेल

@JarrodRoberson मैं सिर्फ उसके लिए स्केच कर रहा हूं .. बस इसे अंतिम रूप से जोड़ने के लिए अपरिवर्तनीय होना चाहिए। यह एक नो-ब्रेनर है। ओपी के सवाल के साथ मूलभूत समस्या यह है कि वह नहीं जानता कि एक आधार वर्ग और दो अलग-अलग वर्ग कैसे होते हैं जो एक आधार वर्ग का विस्तार करते हैं। मैं बस उस का विस्तार कर रहा हूं।

— डेविड काउडन

@Blundell दुनिया में आप किस बारे में बात कर रहे हैं? एक बार है एक स्थान । बस अपने स्थान को अपने आधार के साथ बदलें और यह ठीक वैसी ही बात है .. आप जानते हैं कि जब एक वर्ग एक और वर्ग का विस्तार करता है, तो उसका नाम आधार [ClassThatWillExtend] नहीं होता है?

— डेविड काउडन

@DavidCowden, क्या आप हर दूसरे जवाब के नीचे टिप्पणी के रूप में अपने जवाब का विज्ञापन करने के लिए रुक सकते हैं, कृपया?

— मार्किटानी