2012-07-28 12 views
5

कौन सा एक एपीआई डिजाइन करने के लिए बेहतर तरीका होगा:स्वच्छ एपीआई डिजाइन

Example A: 
public class UserService { 
    public void addUser(final User user); 
    public void addUserToIndex(final User user, final int index); 
    public User lookUpUser(final User user); 
    public User getUserByIndex(final int index); 
    public void removeUser(final User user); 
    public List<User> getAllUsers(); 
} 

Example B: 
public class UserService { 
    public void add(final User user); 
    public void add(final User user, final int index); 
    public User lookUp(final User user); 
    public User get(final int index); 
    public void remove(final User user); 
    public List<User> getAll(); 
} 

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

कुकू

+1

+1 उदाहरण के लिए बी, लेकिन मुझे शायद ही यह प्रश्न रचनात्मक लगता है क्योंकि उत्तर बहुत ही व्यक्तिपरक है –

+0

मुझे लगता है कि एक सामान्य उपयोग 'userService.addUser (उपयोगकर्ता) 'होगा जो विकल्प ए को अनावश्यक बनाता है। – Xion

+2

'सार्वजनिक शून्य जोड़ें (अंतिम उपयोगकर्ता उपयोगकर्ता, अंतिम int अनुक्रमणिका) की बजाय; ', आपको' सार्वजनिक शून्य डालने (अंतिम उपयोगकर्ता उपयोगकर्ता, अंतिम int अनुक्रमणिका) पर विचार करना चाहिए;'। मेरा मानना ​​है कि यह जावा एपीआई में आमतौर पर इस्तेमाल किया जाने वाला नाम है। –

उत्तर

3

दो मुख्य सवाल है, जो आप अपनी पसंद बहुत आसान बनाने के लिए जवाब देने के लिए की आवश्यकता है:

  1. आप कर रहे हैं पूरी तरह से 100% यकीन है कि आप एक से अधिक इकाई के साथ इस सेवा मशक्कत करनी पड़ती है कभी नहीं होगा?

    दूसरे शब्दों में, क्या कोई परिदृश्य हो सकता है जहां UserService में getRoles() जैसी अतिरिक्त विधियां होंगी? अगर उत्तर हाँ है, तो आप निश्चित रूप से विकल्प ए के साथ जा रहे हैं।

  2. यदि आप निश्चित रूप से प्रति सेवा एक इकाई प्राप्त करने जा रहे हैं, तो क्या आपको प्रति सेवा इंटरफ़ेस की भी आवश्यकता है या आप एक सामान्य जेनेरिक एक का उपयोग करेंगे?

    तो, आपके विकल्प बी के बजाय आप

    public class Service<T> { 
        public void add(final T entity); 
        public void add(final T entity, final int index); 
        public T lookUp(final T entity); 
        public T get(final int index); 
        public void remove(final T entity); 
        public List<T> getAll(); 
    } 
    

    कंक्रीट सेवाओं को और अधिक विशिष्ट कार्यक्षमता की जरूरत है कि तब यह सामान्य सेवा विस्तार कर सकते हैं की तरह कुछ हो सकता है।

2

आधुनिक IDEs इन दिनों, मैं टोमाज़ से सहमत देखते हुए कि एक नहीं बल्कि व्यक्तिपरक सवाल है।

आपको यह विचार करना होगा कि कोड क्या दिख सकता है (और एपीआई के लिए संभावित विस्तार)।

a.add(b); // :P this would make no sense at all 
a.addUser(b) // is at least more descriptive 

वर्बोज़ विधि नामों के लिए और उसके लिए एक तर्क है। व्यक्तिगत रूप से आधुनिक आईडीई की क्षमताओं के साथ, मैं कहूंगा कि तर्क धीरे-धीरे वजन कम कर रहा है।

व्यक्तिगत रूप से, मैं उदाहरण एक पसंद करते हैं, यह क्या प्रत्येक विधि कर रही है

+0

अगर मैं 'a.add (बी)' कोड विरासत में मिला तो मुझे परेशान होगा, मैं थोड़ा और उम्मीद करूँगा 'ए' और' बी' के नाम से रचनात्मकता। – akf

+0

मैं आपको उस व्यक्ति के साथ पेश करूंगा जो पूरे पुस्तकालयों को बकवास के टुकड़े के लिए लिखा है जिसे मैंने अब विरासत में मिला है। कोड के साथ पेश किए गए प्रत्येक नए डेवलपर – MadProgrammer

1

आपकी समस्या बनाम 'हो रही उलझन में' 'वर्बोज़ हो रही' है करने के इरादे बहुत स्पष्ट है। वर्बोज़ प्राप्त करने से ग्राहक को विधि नाम पर देखकर कार्यक्षमता का अनुमान लगाकर कोड को कोड मिल जाता है। हालांकि, मैं दूसरे संस्करण को पसंद करता हूं, क्योंकि विधि हस्ताक्षर (और वापसी प्रकार) यह स्पष्ट करता है कि यह क्या करता है। आईडीई समर्थन और उचित टिप्पणी/दस्तावेज़ के साथ, दूसरा संस्करण अधिक terse और समान रूप से आसान है।

UserService#add(User) की व्याख्या करने का कोई अन्य तरीका adding user के अलावा कुछ भी नहीं करेगा; वही अन्य तरीकों के लिए चला जाता है। कोड छोटा दिखता है और यह कम टाइपिंग है।

1

पहला दृष्टिकोण क्लीनर लगता है। सामने अधिक जानकारी देता है।कोड पढ़ने वाले लोग तुरंत कोड के अर्थ को जान लेंगे, जो किसी और के कोड को डीबग करने या बनाए रखने के दौरान महत्वपूर्ण है।

package java.security.acl 

public interface Group extends Principal 
{ 

    public boolean addMember(Principal user); 
    public boolean removeMember(Principal user); 
    public boolean isMember(Principal member); 
    public Enumeration<? extends Principal> members(); 
} 

स्प्रिंग

JDK7

:

public interface GroupManager { 

    List<String> findAllGroups(); 
    List<String> findUsersInGroup(String groupName); 
    void createGroup(String groupName, List<GrantedAuthority> authorities); 
    void deleteGroup(String groupName); 
    void renameGroup(String oldName, String newName); 
    void addUserToGroup(String username, String group); 
    void removeUserFromGroup(String username, String groupName); 
    List<GrantedAuthority> findGroupAuthorities(String groupName); 
    void addGroupAuthority(String groupName, GrantedAuthority authority); 
    void removeGroupAuthority(String groupName, GrantedAuthority authority); 
} 

आप देख सकते हैं

यहाँ 2 उदाहरण है कि क्या आप सबसे अच्छा डिजाइन किया चौखटे के 2 से कर रहे हैं के निकट स्थित हैं इन इंटरफेस से, अगर मैं कोड पढ़ रहा था, तो यह तुरंत बताना होगा कि कोड वापस जाने और ऑब्जेक्ट के प्रकार को देखने के बिना क्या कर रहा है।

मैं आपके उदाहरण ए के लिए वोट देता हूं। यह सिर्फ सभी के जीवन को सरल बनाता है।

+0

का मतलब है आपका मतलब है कि ए क्लीनर है? – kukudas

+0

ओह क्षमा करें .. आप सही हैं .. संपादित करेंगे ..: डी –

+0

आपके इनपुट के लिए कोई समस्या नहीं धन्यवाद। हालांकि यदि आप जावा संग्रह एपीआई को देखते हैं तो इसे ऐड() भी जोड़ा जाता है और addElement या addObject नहीं जोड़ा जाता है। – kukudas

संबंधित मुद्दे