हैशटेबल संपत्ति भंडारण के लिए उपयुक्त है?

Question

मैं एक्शनस्क्रिप्ट 3 पृष्ठभूमि से आया हूं और यह मेरी पहली बार मेरी जिंदगी में किसी भी जावा को लिख रहा है। हैशटेबल्स फ्लैश में शब्दकोशों के समान दिखते हैं, लेकिन मैं यह सुनिश्चित करना चाहता हूं कि मैं उनका उपयोग सही तरीके से कर रहा हूं। मेरा मानना ​​है कि हैशटेबल स्ट्रिंग्स को कुंजी और टाइपफेसेस के रूप में ऑब्जेक्ट्स के रूप में स्वीकार करने के लिए टाइप किया गया है। क्या ये सही है? क्या कोई अलग संग्रह उप-वर्ग है जो इस तरह के कुछ के लिए अधिक उपयुक्त होगा? हर तरह से, कृपया मेरे एन 00 बी जावा को फाड़ें। मुझे यह सीखना है।

package com.typeoneerror.apps.app_name.utils; 

import android.content.Context; 
import android.graphics.Typeface; 

import java.util.Hashtable; 

public class FontRegistry 
{ 
    private static FontRegistry _instance; 

    private Context       _context; 
    private Hashtable<String, Typeface>  _fonts; 

    private FontRegistry() 
    { 
     _fonts = new Hashtable<String, Typeface>(); 
    } 

    public static FontRegistry getInstance() 
    { 
     if (_instance == null) 
     { 
      _instance = new FontRegistry(); 
     } 
     return _instance; 
    } 

    public void init(Context context) 
    { 
     _context = context; 

    } 

    public Typeface getTypeface(int resourceId) 
    { 
     String fontName = _context.getResources().getString(resourceId); 
     if (!_fonts.containsKey(fontName)) 
     { 
      String fontPath = "fonts/" + fontName; 
      Typeface typeface = Typeface.createFromAsset(_context.getAssets(), fontPath); 
      _fonts.put(fontName, typeface); 
     } 
     return (Typeface)_fonts.get(fontName); 
    } 
} 

Answer 1

आपके लिए दो सुझाव।

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

दूसरा, कार्यान्वयन एक हैश मैप होना चाहिए, हैशटेबल नहीं। हैशटेबल सब कुछ सिंक्रनाइज़ करता है, जहां हैश मैप नहीं करता है।

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

तो,

private Map<String, Typeface>  _fonts; 

और

_fonts = new HashMap<String, Typeface>(); 

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

संपादित करें: एक अंतिम नाइटपिक। आप रजिस्ट्री के लिए सिंगलटन पैटर्न का उपयोग कर रहे हैं। यह आपको बाद में काट सकता है, इसलिए सिंगलेट्स http://accu.org/index.php/journals/337 से बचने पर विचार करें। लेकिन, इसे अनदेखा करते हुए, आप घोषणापत्र में सिंगलटन स्थिर उदाहरण को तुरंत चालू करने से बेहतर हो सकते हैं। यह पहली बार लाने के दौरान एक संभावित विवाद से बच सकता है।

तो:

private static FontRegistry _instance = new FontRegistry; 

Answer 2

मेरी टिप्पणी पर विस्तार करने के लिए, getInstance() अपने क्रियान्वयन की सुरक्षित थ्रेड नहीं है। क्या तुम सच में सिंगलटन पैटर्न का उपयोग करना चाहिए, तो आप "बिल प्यूघ" संस्करण (जो मैं तो एकदम wikipedia article से कॉपी किया है) का उपयोग कर सकते हैं:

public class Singleton { 

    // Private constructor prevents instantiation from other classes 
    private Singleton() { 
    } 

    /** 
    * SingletonHolder is loaded on the first execution of Singleton.getInstance() 
    * or the first access to SingletonHolder.INSTANCE, not before. 
    */ 
    private static class SingletonHolder { 
     public static final Singleton INSTANCE = new Singleton(); 
    } 

    public static Singleton getInstance() { 
     return SingletonHolder.INSTANCE; 
    } 
} 

इसके अलावा आप जब एंड्रॉयड नहीं करने के लिए "रिसाव के लिए विकसित करने सावधान रहना चाहिए "एक Context। यहां एक good article है, ऐसा क्यों करना बुरा है, और इससे कैसे बचें। निचली पंक्ति यह है कि staticContext (या एक ऑब्जेक्ट जो स्वयं Context का संदर्भ देता है) का संदर्भ हो सकता है इसका मतलब यह हो सकता है कि आपका Activity उदाहरण कचरा एकत्र नहीं किया जा सकता है।