एक चीज करें - इस नियम को कितना दूर लेना है?

Question

तो "स्वच्छ कोड" पुस्तक में "डू वन थिंग" नियम है। लेकिन हमें वास्तव में इसे कितना लेना है।

उदाहरण के लिए निम्नलिखित बयानों: एक से अधिक बयान यहाँ है

Settings.Default.BaudRate = baudRate; 
Settings.Default.COMPort = port; 
Settings.Default.DataBits = dataBits; 
Settings.Default.Handshake = handshake; 
Settings.Default.Parity = parity; 
Settings.Default.ReadTimeout = readTimeout; 
Settings.Default.WriteTimeout = writeTimeout; 
Settings.Default.CommunicationTimeout = communicationTimeout; 
Settings.Default.Save(); 

ठीक है, यकीन है कि, लेकिन जैसे वे सिर्फ एक बात कर रहे हैं यह मेरे लिए कैसा लगता है। सेटिंग्स को सहेजना।

मेरे पास यह एक ही कार्य में है। क्या आप वास्तव में यह एपर्ट ले लेंगे और प्रत्येक सेटिंग के लिए एक ही विधि है?

आप इस नियम के साथ कब रहते हैं और आप कब नहीं करते?

Answer 1

मुझे पूरी तरह से मान्य लगता है। उस कोड के लिए स्पष्ट विधि नाम SaveSettings है, जो इंगित करता है कि विधि वास्तव में एक चीज है। किसी बारे में चिन्ता की जरूरत नहीं।

Answer 2

मैं उन्हें सभी को SaveSettings() फ़ंक्शन में रखूंगा - यदि आप उन्हें अपने स्वयं के फ़ंक्शन में डाल देते हैं, तो आपको अभी भी उन सभी कार्यों को किसी अन्य फ़ंक्शन से कॉल करने की आवश्यकता होगी।

Answer 3

मैं इस नियम संदर्भों को मान रहा हूं कि फ़ंक्शन को एकाधिक उप-फ़ंक्शंस में विभाजित करने के लिए।

आपके पास सही विचार है - बचत सेटिंग्स "एक चीज़" है और यह अपने स्वयं के कार्य में हो सकती है। अपने सेटिंग में प्रत्येक सेटिंग को ओवरकिल करना होगा।

एक और दिशानिर्देश मैंने सुना है कि "एक चीज़" अवधारणा की आपकी समझ में मदद मिल सकती है: यदि फ़ंक्शन एक या दो पृष्ठों से अधिक लंबा है, तो संभवतः यह कई सामग्रियों में अपनी सामग्री को विभाजित करके बेहतर लिखा जा सकता है।

Answer 4

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

Answer 5

हां, प्रत्येक विधि को केवल एक चीज़ करना चाहिए। लेकिन वह एक बात क्या है?

यह पर निर्भर करता है कि आपकी विधि अबास्ट्रक्शन का स्तर है। एक सेटिंग को सहेजने के लिए एक विधि (संपत्ति) एक कम अबास्ट्रक्शन है। अगला उच्च अमूर्त तब प्रस्तावित SaveSettings विधि होगा। हम एक समारोह दिशानिर्देश के लिए एक ही उद्देश्य पालन करने की कोशिश पूरे कार्यक्रम ...

Answer 6

हमारी टीम पर:

शीर्ष पर सही आप एक ही विधि/समारोह main जो भी केवल एक बात करता है। डेवलपर्स की मदद करने के लिए हमने अपने मानकों को एक सुझाव जोड़ा कि यदि कोई फ़ंक्शन 25 लाइनों से अधिक हो तो वे रिफैक्टरिंग पर विचार करें। इसलिए यदि आपके पास कोड सेटिंग गुणों की 100 पंक्तियां थीं, तो आप SaveUserSettings, SaveNetworkSettings, आदि जैसे श्रेणियों से उन्हें विभाजित करने पर विचार कर सकते हैं ..

अंतिम लक्ष्य कोड को और अधिक पठनीय बनाना है। यदि आपने अपनी विधि ली है और प्रत्येक संपत्ति को सेट करने के लिए 20 कॉल में विभाजित किया है, तो मुझे लगता है कि यह अनुवर्ती और समर्थन करने के लिए अधिक समय लेने वाला होगा।

Answer 7

अलगाव में अपना कोड देखकर, यह कहना मुश्किल है।आप तर्क दे सकते हैं कि आपका फ़ंक्शन दो चीजें करता है - सेटिंग्स को अपडेट करना और फिर परिवर्तनों को सहेजना। साथ ही, आप मूल्यों को कैसे पॉप्युलेट करते हैं, क्या वे आपके फ़ंक्शन (बेहतर) के तर्क के रूप में पास किए जाते हैं या क्या आपके फ़ंक्शन को मान मिलते हैं (कुछ और कर रहे हैं)?

वहाँ एक से अधिक कारण हो कभी नहीं करना चाहिए एक वर्ग

बदलने के लिए और समान रूप से तरीकों को लागू किया जा सकता के लिए:

मैं Single Responsibility Principle जो सारांशित किया गया है के रूप में अनुसरण करेगा। आपके उदाहरण में सेटिंग्स को अपडेट करने का कोई कारण होगा, लेकिन उन्हें सहेज नहीं पाएगा?

Answer 8

उदाहरण कोड के साथ उदाहरण कोड बेहतर होगा, जब गुणों का उपयोग किया जाए और ऑब्जेक्ट स्थिति सेट करने के लिए किसी कन्स्ट्रक्टर या विधि पर पैरामीटर का उपयोग कब किया जाए। मुझे पता है कि .NET framework guidelines में इस पर एक अनुभाग है, जहां यह घटक पैटर्न पैटर्न पर चर्चा करता है (गुणों के बहुत सारे और घटक आंतरिक स्थिति पहले और आखिरी असाइनमेंट के बीच अमान्य हो सकता है) अन्य पैटर्न बनाम (कन्स्ट्रक्टर पैरामीटर और विधि पैरामीटर के बहुत सारे और वस्तुओं आंतरिक स्थिति के बाद कोड की प्रत्येक पंक्ति को निष्पादित करता है मान्य है।

Answer 9

मैं उस विशेष पुस्तक नहीं पढ़ा है, लेकिन अवधारणा के रूप में ...

"एक बात" मतलब यह नहीं है "की एक पंक्ति कोड "।" एक बात "का अर्थ है कि फ़ंक्शन में सब कुछ तार्किक रूप से संबंधित होना चाहिए।

मैं पिछले कुछ पोस्टरों के साथ कहता हूं कि" saveSetti एनजीएस "एक चीज है"। शायद यह शब्द के साथ सिर्फ लापरवाही है, लेकिन मैं संभावित जाल को इंगित करने का अवसर लेगा। आपके मामले में, यह "saveCommunicationSettings" जैसा अधिक है, जो मुझे लगता है कि आसानी से "एक चीज़" परिभाषा फिट बैठता है। यदि आपने उस सूची में "सेटिंग्स.डिफॉल्ट.customerLoyaltyDiscount = ..." जोड़ा है, तो मैं कहूंगा कि आप शायद खतरनाक जमीन पर हैं, क्योंकि अब आप मूल्य निर्धारण गणना सेटिंग के साथ संचार सेटिंग्स को मिश्रित कर रहे हैं।

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

Answer 10

यदि आप अपनी विधि को विभाजित करना चाहते हैं तो मैं वस्तु की वास्तविक बचत से मूल्यों के मानचित्रण को तोड़ने पर विचार करूंगा। आप कह सकते हैं कि मूल्यों का मानचित्रण अमूर्तता का एक अलग स्तर है। तो आपके पास होगा:

public void save(){ 
    mapSettings(); 
    Settings.Default.Save(); 
} 

private void mapSettings(){ 
    Settings.Default.BaudRate = baudRate; 
    Settings.Default.COMPort = port; 
    Settings.Default.DataBits = dataBits; 
    Settings.Default.Handshake = handshake; 
    Settings.Default.Parity = parity; 
    Settings.Default.ReadTimeout = readTimeout; 
    Settings.Default.WriteTimeout = writeTimeout; 
    Settings.Default.CommunicationTimeout = communicationTimeout; 
} 

ऐसा लगता है जैसे मैपिंग कहीं और पुन: उपयोग किया जा सकता है या आप चाहें। साथ ही, यदि संख्या सेटिंग्स बढ़ी तो उन्हें श्रेणी के अनुसार आगे तोड़ दिया जा सकता है।

इस तरह के मामलों में मैं तर्क नहीं दूंगा कि यह इसके लायक है, और मैंने ऐसा किया है या नहीं, यह मेरे मनोदशा या आकाश में बादलों की मात्रा पर निर्भर करेगा। लेकिन हां, तकनीकी रूप से यहां दो स्तर हैं जिन्हें आप विभाजित कर सकते हैं।

Answer 11

कैसे पता चले कि कोई कार्य एक या अधिक काम करता है या नहीं? यह abstractions के स्तर पर निर्भर करता है। मैं टो उदाहरण में अमूर्त के स्तर (स्वच्छ कोड पुस्तक, अध्याय 3) का वर्णन करने के यह कोड दिखाई कोशिश

public function buildPage() { 
    $page = header(); 
    $page .= body(); 
    $page .= footer(); 
    return $page; 
} 

इस समारोह केवल करता है एक बात और सभी subfunctions buildPage वाक्यांश का हिस्सा हैं

public function sendMail() { 
    $user = $this->getUser(); 
    $this->mailer->content("send this message!") 
     ->to($user->email)->send(); 
} 

इस फ़ंक्शंस को उपयोगकर्ता ईमेल की आवश्यकता है, इसलिए getUser फ़ंक्शन भेजने की सहायता से मेल उपयोगकर्ता को ईमेल प्राप्त करने का प्रबंधन करता है। लेकिन $ उपयोगकर्ता = getUser() sendmail वाक्यांश में सबसे अच्छा अभ्यास इस कार्य के लिए वर्णित नहीं कर रहे हैं

public function sendMail($email,$message) { 
    $this->mailer->content($message)->to($email)->send(); 
}