विकल्प प्रकार चर और विधियों के लिए सामान्य नामकरण सम्मेलन जो उन्हें वापस भेजते हैं

Question

विकल्प प्रकार चर और विधियों को नाम देने के कुछ लोकप्रिय तरीके क्या हैं जो विकल्प प्रकारों को उनके गैर-विकल्प समकक्षों से अलग करने के लिए विकल्प प्रकार लौटाते हैं?

मान लीजिए कि वर्तमान में एक डीएओ में findById विधि है जो किसी इकाई या शून्य का उदाहरण देता है, अगर हम उस विधि को बहिष्कृत करते हैं और एक विकल्प प्रकार लौटाते हैं तो उसे कैसे नामित करना चाहिए?

अब मान लीजिए कि हम इस नई विधि का उपयोग करने के लिए कोड को दोबारा प्रतिक्रिया दे रहे हैं, हम विकल्प प्रकार के साथ इकाई चर के सभी संदर्भों को प्रतिस्थापित नहीं करना चाहते हैं, हम विकल्प प्रकार चर को कैसे नामित करना चाहिए?

interface Dao<ENTITY ,ID> { 
    @Deprecated 
    ENTITY findById(ID id); 

    //What naming convention should we use? 
    Optional<ENTITY> maybeFindById(ID id); 
} 

public class MyService { 
    PersonDao personDao; 

    public void changeAge(final Long id,final int age) { 

    //final Person person = personDao.findById(id); 
    //if(person !=null) 

    //What naming convention should we use? 
    final Optional<Person> maybePerson = personDao.maybeFindById(id); 

    if (maybePerson.isPresent()){ 
     final Person person = maybePerson.get(); 
     person.setAge(age); 
    } 
} 

Answer 1

मुझे लगता है कि यह वास्तव में एक सुंदर राय आधारित प्रश्न है, जिसमें वास्तव में कोई आधिकारिक या सही उत्तर नहीं हो सकता है।

उसने कहा, मेरी प्राथमिकता केवल उन विधियों का नाम है जो Optional सामान्य रूप से लौटती हैं, उदा। Optional<Foo> findById(Id id)। विधि वास्तव में ऐसी विधि से अलग नहीं है जो null को "परिणाम न दें" का अर्थ दे सके, सिवाय इसके कि रिटर्न प्रकार इसे और अधिक स्पष्ट बनाता है।

एक Optional चर का सवाल है, मैं सिर्फ उन्हें optionalFoo की तरह नाम के लिए करते हैं ... लेकिन सामान्य रूप में मुझे लगता है कि कैसे आप एक स्थानीय चर (या यहां तक ​​कि क्षेत्र) नाम एक बहुत कैसे आप एक विधि नाम से भी कम समय मायने रखती है।

Answer 2

यदि ऐसा नहीं लगता कि यह दो अलग-अलग तरीकों से एक अच्छा विचार है। अगर प्रवासन के बारे में संदेह है, तो पुराने को रखें।

लेकिन वहाँ दो चरणों में पूरे कोड refactor करने के लिए एक तरीका है:

पहले, से

interface Dao<ENTITY ,ID> { 
    ENTITY findById(ID id); 
} 

को

interface Dao<ENTITY ,ID> { 
    default ENTITY findById(ID id) { return newFindById(id).orElse(null); } 
    Optional<ENTITY> newFindById(ID id); 
} 

मैं अपने प्रश्न से लगता है कि अनुकूल इंटरफेस बदल इंटरफेस के कार्यान्वयन एक मुद्दा नहीं है। अब अपने रिफैक्टरिंग टूल को इनलाइन पुराना, अब default, findById विधि पर बताएं।

दूसरा, विधि newFindById से findById का नाम बदलें।

Person maybePerson = personDao.findById(id); // may be null 

Person maybePerson = personDao.findById(id).orElse(null); 

---

इस तरह से आप के लिए:

इस तरह आप चले गए interface

को

interface Dao<ENTITY ,ID> { 
    Optional<ENTITY> findById(ID id); 
} 

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

ध्यान रखें कि आपके उदाहरण विधि तो बल्कि तरह दिखना चाहिए:

public void changeAge(final Long id,final int age) { 
    personDao.findById(id).ifPresent(person -> person.setAge(age)); 
} 

नोट दोनों रूपों, पुनर्संशोधित पुराने कोड और नए कोड में, प्रकार Optional तो वहाँ के एक चर नाम के लिए कोई जरूरत नहीं है कि एक नामकरण सम्मेलन की कोई ज़रूरत नहीं है।

रिफैक्टरिंग के लिए जावा 8 सक्षम उपकरण की आवश्यकता है।