नामकरण सही

नामकरण: ऑब्जेक्ट‑ओरिएंटेड मूल बातें

Naming stuff: Object Oriented Basics

चलिए उदाहरण से Object/क्लास डिज़ाइन को देखें…

The Situation

क्या आपने कभी data model (कोड, SQL, या एक्सेल शीट्स में) डिज़ाइन किया है?
क्या नीचे दिया गया परिचित लगता है?

*** anti-pattern - don't copy-paste ***
* User
  - id
  - avatarUrl
  - name
  - email
  - password

* Agent
  - id
  - primaryPhoto
  - name
  - email
  - agentEmail
  - agentPhoneMain
  - agentEmailPrimary
  - agentPhonePrimary
  - agentAddressFull
  - agentCompanyName
  - agentCompanyAddress
  - *userEmail* - 'Pointer' to User table ^^^

Where’s the bug?

तकनीकी तौर पर कोई बग नहीं है, बस डेटा को पुनः व्यवस्थित करने की जरूरत है।

क्या यह आपके सामने आया है?

1. आपके ऐप में कोई भी बदलाव घंटों की थकाऊ डिबगिंग की माँग करेगा।
2. बदलती आवश्यकताएँ परिणामस्वरूप:

agentEmailPrimary जैसे फ़ील्ड का नामकरण इतना बुरा क्यों है?

शुरुआत में, आप ब्रह्मांड में पूरी नई चीज़ नहीं बना रहे हैं। अत्यधिक विशिष्टता में कुछ जाल होते हैं:

1. अत्यधिक विशिष्ट नाम में लॉक हो जाना, यानी agentEmailPrimary संभवतः आपके व्यूज़ और संबंधित कोड को 0 % पुन: उपयोग योग्य बना देता है, और लगातार परेशान करने वाले बग्स को जन्म देता है:

• टेबलों के बीच डेटा सिंक नहीं हो रहा है (यह स्पष्ट नहीं है कि user.email को agent.agentEmail में प्रसारित करना है या इसके विपरीत — इस ‘तर्क’ को लागू करने की जटिलता को नज़रअंदाज़ करें …)
• वैधता नियम/तर्क संभवतः दोहराए जा रहे हैं और असंगत हैं।
• समय के साथ आपका प्रोजेक्ट एक अस्थिर जेंगा टॉवर जैसा दिखेगा।
• हर नई फ़ाइल के साथ नाज़ुकता बढ़ती है, क्योंकि मामूली बदलावों के लिए भी अत्यधिक बारीकी से ध्यान देना पड़ता है।

1. agentEmailPrimary कई अलग‑अलग चीज़ों को दर्शा सकता है। छोटे नाम रखकर अस्पष्टता से बचें।

• बेतुकी अतिरिक्त शब्दावली से बचें। Primary? इससे और सवाल उठते हैं: क्या कोई Secondary है? क्या यह उनके Primary Next‑of‑kin के लिए है?

पर्याप्त शब्द, डैन, अब इसे कैसे होना चाहिए?

एक समाधान

// Consolidated Schema:

User
  - id
  - role: ['agent', 'lead', 'admin']
  - name
  - phone
  - address
  - email
  - password
  - company
    - name
    - address

मैंने Agent टेबल को हटा दिया, क्योंकि उसमें एजेंट‑विशिष्ट फ़ील्ड नहीं थे। और User.company ऑब्जेक्ट (जिसमें .name, .address हैं) नाम साफ़ करने के बाद एक बार प्रकट हुआ।

कुछ मार्गदर्शक सिद्धांत:

1. अनावश्यक टेबल्स को हटाएँ। क्या आपको वास्तव में एक statuses टेबल चाहिए? जब आप User टेबल में status::VARCHAR(8) फ़ील्ड जोड़ सकते हैं? ठीक है, प्रति पंक्ति अतिरिक्त बाइट्स का उपयोग करें।
2. संबंधित टेबल्स को मिलाने की कोशिश करें। Data
3. दोहराव वाले डेटा संग्रह को हटाएँ (उदाहरण – यदि कोई एनालिटिक्स समाधान है तो ActivityLogs टेबल को हटा दें)।
4. सभी फ़ील्ड नामों को एक शब्द/संज्ञा/सर्वनाम तक सीमित रखें। टेबल द्वारा प्रदान किए गए संदर्भ पर भरोसा करना ठीक है। (उदाहरण – PersonalAccount.email बनाम BusinessAccount.email – संदर्भ टेबल नाम से मिलता है।)
5. Agent.agentEmail या Agent.agentPhonePrimary जैसा कुछ नहीं है। बस इतना कहें: “यह email और phone है।”
6. अत्यधिक विशिष्ट नामों का उपयोग करके आप code-reusability और durability के एक विशिष्ट स्तर को पत्थर में ढाल देते हैं, और वह स्तर शून्य प्रतिशत है।
7. User.profileSummaryEmail जैसी बेकार चीज़ों से आप खुद को कोई फ़ायदा नहीं पहुंचा रहे हैं। 💞

सिफ़ारिश किया गया पढ़ना:

1. Maybe Normalizing Isn’t Normal
2. The Trade-offs Between Database Normalization and Denormalization
3. http://phlonx.com/resources/nf3/
4. https://en.wikipedia.org/wiki/Database_normalization