जावा मॉडल ऑब्जेक्ट्स डिजाइन

Question

तो मैं कुछ प्रभावी जावा पढ़ रहा हूं! और पुस्तक के सबसे प्रेरक वर्गों में से एक अपरिवर्तनीय वस्तु/बिल्डर अनुभाग है जहां ब्लोच सिर्फ पीओजेओ के बजाय "बिल्डर" वर्ग के बारे में लिखता है।

नोट: मैं मॉडल के बारे में बात कर रहा हूँ यहाँ वस्तुओं: उदाहरण के लिए की तरह एक अनुच्छेद या एक कार।

इस तरह मैंने पहले इन वस्तुओं लिखा है: अब

public class Car { 

    private String name; 

    public void setName(String name) { 
     this.name = name; 
    } 

    public String getName() { 
     return name; 
    } 
} 

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

अब निश्चित रूप से आप name फील्ड फ़ाइनल बना सकते हैं और इसे कन्स्ट्रक्टर में तर्क के रूप में उपयोग कर सकते हैं, लेकिन फिर यदि आपके पास बड़ी ऑब्जेक्ट रैपिंग है उदाहरण के लिए कई SQL-टेबल्स तो आपके पास एक बदसूरत कन्स्ट्रक्टर होगा:

public Car(int horsepowers, String name, String brand, int yearManufactured, 
    User owner, List<User> previousOwners) { 
    //Set the values 
} 

ऑब्जेक्ट बनाते समय यह अपठनीय हो जाता है, और यह केवल छह फ़ील्ड है!

तो, बलोच (अचल स्थिति के साथ) निम्नलिखित

public class Car { 

    public static class Builder { 

     private String name; 

     public Builder setName(String name) { 
      this.name = name; 
      return this; 
     } 

     public Car build() { 
      reeturn new Car(this); 
     } 
    } 

    private final String name; 

    private Car(Builder builder) { 
     name = builder.name; 
    } 

    public String getName() { 
     return name; 
    } 
} 

//Construction example 
Car car = new Car.Builder().setName("Speedy").build(); 

अब यह हमें अचल स्थिति देता है पता चलता है! और यदि आपके पास ऐसी कुछ वस्तुएं हैं जो आदिम या अपरिवर्तनीय नहीं हैं तो उन्हें Builder के सेटर्स में कॉपी करें और उन्हें Car के गेटर्स में दोबारा कॉपी करें।

लेकिन यह बहुत शब्दशः है और यदि वर्ग पर्याप्त छोटा है तो मैं कन्स्ट्रक्टर तर्कों का उपयोग कर रहा हूं। यदि किसी वर्ग को एक उत्परिवर्तनीय फ़ील्ड की आवश्यकता होती है तो मैं उस क्षेत्र को उत्परिवर्तनीय बना देता हूं, यदि कक्षा में पर्याप्त गुण हैं (> 4 कुछ)।

एक और समस्या यह है कि एंड्रॉइड और कक्षा के साथ काम करने के लिए उदाहरण के लिए Bitmap है, तो आपको वास्तविक बिटमैप वापस करना होगा और इसकी प्रतिलिपि नहीं लेनी चाहिए क्योंकि यह प्रदर्शन - महंगा है।

मैंने इस तरह के कई प्रश्न देखे हैं लेकिन मुझे इस प्रश्न पर एक अच्छा जवाब नहीं मिल रहा है: क्या इन डिज़ाइनों पर कोई मानक है और उनका डिज़ाइन कैसा है? लाभ/पराजय क्या हैं?

अग्रिम धन्यवाद!

संपादित करें:

सवाल यह है:

सबसे अच्छा तरह से एक बड़ी एक वस्तु मॉडल है कि अपरिवर्तनीय और एक साथ होना चाहिए) क्षेत्रों की एक छोटी संख्या और बी के निर्माण के लिए) क्या है क्षेत्रों की संख्या? उपर्युक्त और इसी तरह के मुद्दों का उल्लेख Bitmap समस्या को कैसे संभालें? कुछ क्षेत्रों को परिवर्तनीय बनाना?

अस्पष्ट होने के लिए खेद है।

Answer 1

Design Patterns पुस्तक वर्तमान में डिज़ाइन पैटर्न के अल्फा और ओमेगा है। हालांकि यह नया नहीं है लेकिन ऐसा लगता है कि यह समय की परीक्षा पास कर चुका है।

आप प्रत्येक डिज़ाइन पैटर्न के विस्तृत वास्तविक जीवन उदाहरण पढ़ सकते हैं, वे एक दूसरे से कैसे संबंधित हैं, उन्हें कैसे और कब उपयोग करें और प्रत्येक के लिए पूरी तरह से स्पष्टीकरण दें। बिल्डर पैटर्न पाठ्यक्रम में शामिल है।

अपने प्रश्न का उत्तर देने के लिए मैं अपने विचार प्रस्तुत कर सकता हूं हालांकि वे निश्चित रूप से आधिकारिक नहीं हैं।

मुझे लगता है कि यदि आपके पास छोटी संख्या में फ़ील्ड हैं तो आप कन्स्ट्रक्टर का उपयोग कर जा सकते हैं। यदि आप checkstyle लेते हैं उदाहरण के लिए यह 7 पैरामीटर पर एक चेतावनी निकालता है।

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

यदि आप 7 से अधिक पैरामीटर हैं तो मुझे लगता है कि बिल्डर बेहतर है। मैं वर्तमान परियोजना में इसका उपयोग कर रहा हूं जो मैं बड़े पैमाने पर काम कर रहा हूं।

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

तो यदि फ़ील्ड का एक समूह है जो उत्परिवर्तनीय नहीं होना चाहिए तो उन्हें अंतिम चिह्नित करें और एक कन्स्ट्रक्टर/निर्माता का उपयोग करें और उत्परिवर्तनीय लोगों के लिए सेटर्स प्रदान करें।

Answer 2

मैं इसे "उत्तर" के रूप में इनपुट कर रहा हूं इसलिए मेरे पास व्याख्या करने की जगह है, लेकिन यह वास्तव में एडम एरोड द्वारा शुरू किए गए धागे पर एक टिप्पणी है।

जोहान, सबसे पहले मुझे लगता है कि आप प्रभावी जावा में आइटम 2 के बारे में बात कर रहे हैं।

ध्यान दें कि प्रस्तुत किया गया है कि बिल्डर पैटर्न एडम एरोइड का एक रूप है। जोश ब्लोच प्रभावी जावा में इसके लिए कोड दिखाए जाने से पहले इस सीधे अधिकार का उल्लेख करता है: "यह बिल्डर पैटर्न [गामा 95, पृष्ठ 9 7] का एक रूप है।" (यह पृष्ठ 13 पर है।) बाद में उन्होंने एक और पैटर्न (उसी पुस्तक से) का उपयोग करने का एक तरीका बताया: "एक निर्माता जिसका पैरामीटर सेट किया गया है, एक अच्छा सार कारखाना बनाता है [गामा 95, पृष्ठ 87]

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

Answer 3

इस कोड के साथ प्रयास करें:।

public static boolean isEmailValid(String email) { 

    boolean isValid = false; 

    String expression = "^[\\w\\.-]+@([\\w\\-]+\\.)+[A-Z]{2,4}$"; 
    CharSequence inputStr = email; 

    Pattern pattern = Pattern.compile(expression, Pattern.CASE_INSENSITIVE); 
    Matcher matcher = pattern.matcher(inputStr); 
    if (matcher.matches()) { 
     isValid = true; 
    } 
    return isValid; 
}