जावा क्लास जो एक पुस्तक

Question

मॉडल पूछने से पहले मुझे यह कहना है कि यह होमवर्क है और मैं केवल एक पुस्तक को मॉडल करने वाले वर्ग को कार्यान्वित करने के तरीकों की तलाश कर रहा हूं।

एक पुस्तक में एक शीर्षक और कई अध्याय हैं, प्रत्येक अध्याय में एक शीर्षक और एकाधिक उपचैप्टर हैं। प्रत्येक सबचप्टर में एक शीर्षक और पैराग्राफ की एक सूची होती है। प्रत्येक अनुच्छेद में एक संख्या और एक पाठ हो सकता है। मैं ओओपी में निम्नलिखित कार्यक्षमताओं को लागू करने के लिए देख रहा हूं: अध्याय हटाएं/हटाएं: अध्याय, सबचैप्टर और पैराग्राफ और पुस्तक प्रदर्शित करें। मुझे कक्षा के लिए सही संरचना खोजने में कुछ परेशानी हो रही है।

इस तरह मैं इसे लागू करने की सोच रहा हूं लेकिन ऐसा लगता है कि यह अनावश्यक और जटिल है। क्या ऐसा करने के लिए सरल और अधिक सही तरीके हैं?

public class Element<T> { 
     int nr; 
     String Title; 
     ArrayList<T> x = new ArrayList<T>(); 

     Element() { 
      nr = 0; 
      Title = ""; 
     } 

     public void removeFromElement(int index) { 
      if (index <= 0 && index > x.size()) 
       System.out.println("The chapter doesn't exist"); 
      else { 
       x.remove(index); 
       System.out.println("Succesful deletion"); 
      } 
     } 

     public void addToElement(T elem) { 
      x.add(elem); 
     } 
    } 

    public class Paragraph { 
    int nr; 
    String text; 
    } 

    public class Subchapter extends Element<Paragraph> { 
    } 

    public class Chapter extends Element<Subchapter> { 
    } 

    public class Book extends Element<Chapter> { 
    } 

Answer 1

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

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

कुछ नामकरण स्पष्ट हो सकता है (उदाहरण के लिए एनआर संख्या के रूप में) या शैली सम्मेलनों का पालन नहीं करता है (शीर्षक शीर्षक होना चाहिए)।

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

आप हमेशा माता-पिता की स्थिति को देखकर संख्या को ढूंढ सकते हैं। अनिवार्य रूप से आप उस जानकारी को डुप्लिकेट कर रहे हैं।

जैसा कि ग्रेगरी ने टिप्पणियों में बताया कि सभी चर निजी और गेटर्स और सेटर्स के माध्यम से पहुंचे जा सकते हैं।

Answer 2

यह वास्तव में सही डिजाइन नहीं है। (लेकिन मुझे पसंद है कि आप कम से कम कोड लेखन के बारे में क्या सोचते हैं)

पुस्तक अध्याय या "अध्याय तत्व" द्वारा विस्तारित नहीं है। पुस्तक में अध्याय हैं और इसमें कुछ और भी शामिल/हो सकता है।

इसलिए सही डिजाइन simpliest एक

public class Book{ 
    private String title; 
    private List<Chapter> chapters; 
} 
//other classes would look similar 

यह दृष्टिकोण अधिक स्थिर है और यह भविष्य में आसान संशोधन (या यहां तक ​​कि प्रतिस्थापन) की अनुमति देता है।

यह "phenomen" है भी नाम है, यह Composition over inheritance

Answer 3

आपका पहला तरीका बिल्कुल अच्छा है, लेकिन खाते में विकास की संभावना नहीं ले करता है।

यदि हम आपको पैराग्राफ के 0-एन उद्धरण (या कुछ और) रखने की संभावना जोड़ने के लिए कहा तो क्या होगा? क्या होगा यदि हमने आपको अपनी पुस्तक में जोड़ने के लिए कहा, एक प्रकार का अध्याय जिसमें उपचैप्टर नहीं हो सकते?

इसमें बड़े बदलावों की आवश्यकता होगी। आपको composite pattern पर एक नज़र डालना चाहिए।

इस पैटर्न के बाद, जहां तक ​​विकास के संबंध में आप अधिक लचीला होंगे।

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

("डिजाइन पैटर्न सिर पहले" पढ़ने के लिए एक अच्छी किताब होगी)।

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

ध्यान देने योग्य एक और बात: आपको अपने कोड को लॉग इन करने के लिए System.out.println() विधि का उपयोग नहीं करना चाहिए। एक लॉग एपीआई (उदाहरण के लिए log4j) और अपवाद का प्रयोग करें।

public void removeFromElement(int index) throws ChapterNotFoundException{ 
     if (index <= 0 && index > x.size()){ 
      throw new ChapterNotFoundException(String.format("Chapter %s does not exist", index)); 
     } 

     x.remove(index); 
     logger.info(String.format("Chapter %s has been removed", index)); 
    } 

Answer 4

आपका डिज़ाइन अच्छा है। कोड में कुछ बग हैं; मैं उन्हें खोजने के लिए कुछ यूनिट परीक्षण लिखने का सुझाव देता हूं (संकेत: पृष्ठों को हटाने का प्रयास करें)।

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

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