ऑब्जेक्ट ओरिएंटेड डिज़ाइन ... सीएसएस में

मैं आपको पहले ही चेतावनी देता हूं कि मैं अपने आप को HTML / CSS / JS में विशेषज्ञ नहीं मानता। लेकिन, एक वास्तुकार के रूप में, मैं हमेशा सीएसएस के रूप में प्रस्तुत किए गए लोगों सहित, इसके सबसे विविध अभिव्यक्तियों में कोड के संगठन और व्यवस्थितकरण में रुचि रखता था। यह ब्याज विशेष रूप से बीईएम द्वारा दृढ़ता से भरा गया था, यह पहली बार मिला था, अवचेतन मन ने संज्ञानात्मक असुविधा के साथ प्रतिक्रिया की थी। और जब से मेरी परियोजनाओं में बीईएम-शैली अधिक से अधिक बार दिखाई देने लगी, मुझे समझ में आने की तत्काल आवश्यकता महसूस हुई, आखिरकार, शैलियों के संगठन के लिए मेरा दृष्टिकोण। इस प्रकार, प्रतिबिंब का यह विषय, विषय चर्चा दिखाई दिया। मैं समझता हूं कि मैंने बॉर्डर का काम संभाला है, क्योंकि सभी लेआउट डिजाइनर ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की पेचीदगियों से परिचित नहीं हैं, और अधिकांश आर्किटेक्ट्स ने एक भी सीएसएस शैली नहीं लिखी है। और, परिणामस्वरूप, मुझे इसे अजीब तरीके से संतुलित करना पड़ा ताकि हर कोई समझ सके। लेकिन 'इस जोखिम ने विषय में मेरी दिलचस्पी को और बढ़ा दिया :)

BEM को प्रश्न

मैंने इस तथ्य से शुरू करने का फैसला किया कि यह बीईएम में मेरे लिए पूरी तरह से स्पष्ट नहीं था:

1. कई लोगों का मानना ​​है कि तकनीक हमेशा और हर जगह एक प्राथमिक सत्य है, क्योंकि यैंडेक्स इसके पीछे है। ऐसा क्यों होता है जो एक विशाल कंपनी के साथ एक बड़ी कंपनी के लिए सूट करता है और इसी तरह की परियोजनाओं की एक छोटी संख्या के साथ ही काम करना चाहिए, कहते हैं, एक छोटी सी टीम में जो विभिन्न प्रकार की साइटों का कस्टम विकास करती है? उदाहरण के रूप में jQueryUI, KendoUI आदि को लें। उन्हें सैकड़ों हजारों परियोजनाओं के लिए दोहराया जाता है और इस संबंध में बहुत अधिक परिपक्वता है। इसके अलावा, यैंडेक्स bem.info पर स्पष्ट रूप से उपयोग की शर्तों को रेखांकित करता है, लेकिन कई लोग इस पैराग्राफ तक भी नहीं पहुंचते हैं, खुद को पहली पंक्तियों तक सीमित करते हैं और आश्वस्त करते हैं: "वे यैंडेक्स पर इसके साथ आए थे।"

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

अपनी शंकाओं को स्पष्ट करने के लिए, मैंने पहला इनपुट फॉर्म लिया जो कि यैंडेक्स वेबसाइट से आया था: एक मेलबॉक्स बनाना, पंजीकरण करना और प्रतिक्रिया देना।



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

Bem.info पर Yandex लिखते हैं: “हर नए प्रोजेक्ट या इंटरफ़ेस तत्व को स्क्रैच से नहीं लिखा जाना चाहिए। यदि कंपनी के अंदर कहीं इसी तरह का कार्य पहले ही किया जा चुका है, तो आपको परिणामी कोड का यथासंभव उपयोग करने की आवश्यकता है। कोड में संदर्भ निर्भरता नहीं होनी चाहिए, इसे आसानी से दूसरी जगह स्थानांतरित करने में सक्षम होना चाहिए। " आइए हम ऐसे पुन: उपयोग के एक उदाहरण को देखें।



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

3. क्लास के नामों में सहमति की कमी को एक फायदा क्यों माना जाता है? और आप इसे कैसे पसंद कर सकते हैं - <div class = "menu__item menu__item_position_first menu__item_state_current">? अंतिम लेआउट में, जिसे मैंने BEM से वंचित किया था, पृष्ठ की मात्रा आधे से गिर गई। इस मामले में, मैं यह नहीं कह रहा हूं कि यह बीईएम को छोड़ने का एक पर्याप्त कारण है और इस ओवरहेड की उपस्थिति का अर्थ स्पष्ट है। मैं सिर्फ इतना कहता हूं कि कम एन्ट्रॉपी वाले इस तरह के ब्लॉटेड सिंटैक्स के लिए मैं एक बिंदु लेता हूं।

4. कई सीएसएस सुविधाओं को छोड़ना क्यों आवश्यक है? पहचानकर्ता, संदर्भ आदि का उपयोग कर चयनकर्ता बनें।

BEM के लिए पहली प्रतिक्रिया यह थी कि मैंने इस संक्षिप्त नाम को Bardak Event Metastatic के रूप में व्याख्यायित किया। लेकिन इन सभी शिकायतों ने सिर्फ एक और निजी राय की धुनाई की, जिसने मुझे वास्तव में मना नहीं किया, दूसरों के लिए अकेले समझाने के लिए। और फिर मैंने खुद को वास्तुशिल्प तरीके से सीएसएस कक्षाओं की बहुत अवधारणा को समझने के लिए बुलाया, जैसा कि मैं आदी हूं।

अनुबंध द्वारा डिजाइन

मैंने कक्षाओं की प्रणाली भूमिका शुरू की। विशेष रूप से, एक नियम के रूप में, पूरे की तुलना में कम महत्वपूर्ण है, क्योंकि उत्तरार्द्ध उनकी राशि का सार है। तो यहाँ, बाकी सिस्टम के साथ बातचीत में सीएसएस कक्षाओं की भागीदारी अकेले लेआउट के क्षेत्र में किसी भी सुधार की तुलना में अधिक महत्वपूर्ण हो सकती है। और यहां उनकी भागीदारी बहुत गंभीर है। वास्तव में, क्लास के नाम HTML और JS के बीच एकमात्र मजबूत लिंक हैं। JS, एक तरह से या किसी अन्य की मुख्य भूमिका, DOM मॉडल से निपटना है। और सही नोड्स के लिए सबसे अच्छा तरीका क्या है? वर्ग के नाम वाले चयनकर्ता। अन्य सभी विकल्प स्केलेबल नहीं हैं। बाईपास चाइल्डनॉड्स / पैरेंटकोड? कल एक रैपर हो सकता है और कोड काम करना बंद कर देगा। टैग नामों का उपयोग करना? कल <input> बन जाएगा <textarea>, <i> बन जाएगा <em>, <pre> को <code> से बदला जाएगा और स्क्रिप्ट काम करना बंद कर देंगी। वर्ग का नाम मौलिक बातचीत इंटरफ़ेस है जिसे हम HTML में डाल सकते हैं और सिस्टम के आगे विकास के लिए जेएस में डर के बिना उपयोग कर सकते हैं।

मैंने जानबूझकर "इंटरफ़ेस" शब्द का उपयोग यहाँ किया है क्योंकि मैं ऑब्जेक्ट-ओरिएंटेड प्रथाओं के साथ एक सादृश्य बनाना चाहता था। किसी भी तरह से शीर्षक का काम करना आवश्यक है। एक समय में, बर्ट्रेंड मेयर ने एफिल भाषा के विकास के हिस्से के रूप में, अनुबंध द्वारा डिजाइन प्रतिमान की घोषणा की। मैं इसके विवरणों में गहराई तक नहीं जाऊंगा, मैं खुद को एक प्रमुख अवधारणा तक सीमित करूंगा। वस्तुएं "संविदात्मक" दायित्वों का भार वहन करती हैं और एक ही अनुबंध के माध्यम से एक-दूसरे के साथ बातचीत करती हैं। उदाहरण के लिए, एक विजेट है जो ड्रैगनेनड्रॉप द्वारा अन्य वस्तुओं को स्वीकार कर सकता है। वह सभी को बताता है: "मैं यह कर सकता हूं, इस उद्देश्य के लिए, मेरे पास, यह कहना है कि कैनड्रॉप फ़ंक्शन जिसे आप एक तर्क के रूप में एक ऑब्जेक्ट पास करते हैं, और मैं एक बूलियन मान लौटाता हूं, इस प्रकार की वस्तु को स्वीकार करता है या नहीं।" इस प्रकार, इस फ़ंक्शन का अस्तित्व, इसके हस्ताक्षर और सार उसके अनुबंध में पंजीकृत हैं। प्रणाली बिल्कुल महत्वपूर्ण नहीं है, इस अनुबंध ने फाइल अपलोड के लिए एक विजेट लिया, नोड्स को खींचने और छोड़ने की क्षमता वाला एक पेड़, या क्या यह सामान की ऐसी उन्नत टोकरी है जहां आप उन्हें माउस से कैटलॉग से स्थानांतरित कर सकते हैं। Drag'n'drop ऑपरेशन के दौरान, केवल यह जानना आवश्यक है कि एक विजेट में ये संविदात्मक दायित्व हैं। और जब आप फ़ाइल को माल की टोकरी में खींचते हैं, तो यह टोकरी के कैनड्रॉप विधि को कॉल करेगा और आपको इस ऑपरेशन की असंभवता के बारे में संकेत देगा।

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

मैं इस विचार को HTML + CSS + JS में अनुवाद करने की कोशिश करूंगा। सबसे पहले, दो सरल अनुबंधों की कल्पना करें - कंटेनर और आइटम, वे सीएसएस कक्षाओं के नाम भी हैं। पहला हमें बताता है कि वह आइटम के साथ काम करने के लिए प्रतिबद्ध है। वह परवाह नहीं करता है कि इसके पीछे टैग या DOM नोड क्या है। यह एक सूची आइटम, मेनू आइटम, टैब नियंत्रण पर टैब हो सकता है। वह किसी के साथ काम कर सकता है अगर यह व्यक्ति अनुबंध मद को पूरा करने के लिए तैयार है। इस प्रकार, हम "फूट डालो और जीतो" के सिद्धांत पर कार्य को अलग-अलग कार्यात्मक क्षेत्रों में तोड़ देते हैं। कार्य करना, उदाहरण के लिए, एक मेनू के साथ, हम इसके सभी प्रकार के कार्यों को उन में विभाजित करते हैं जो कंटेनर + आइटम के सिद्धांत के अनुसार मेनू आइटम के आयोजन के लिए जिम्मेदार हैं, और अन्य सभी।

आइटम अनुबंध के लिए, हम कुछ फ़ंक्शन getParent () {रिटर्न $ (this.dom) .closest ("कंटेनर") को परिभाषित कर सकते हैं। }। कंटेनर के लिए, रिमोट इटेम, अप इटेम, डाउन इटेम, आदि जैसे कार्यों का एक पूरा गुच्छा। चयनकर्ताओं में केवल .container और .item का उपयोग करते हुए, आप जानते हैं कि आप सूची, मेनू, बुकमार्क और किसी भी अन्य प्रकार के संग्रह के लिए समान फ़ंक्शन का उपयोग कर सकते हैं। या, दूसरे शब्दों में, आप एक बार सूचियों और कंटेनरों के साथ काम करने के लिए फ़ंक्शन लिखते हैं, भविष्य में आप बस उनका उपयोग करते हैं। यदि आपने अपनी लाइब्रेरी में एक नया फ़ंक्शन जोड़ा है, तो यह स्वचालित रूप से उपयोग किया जा सकता है जहां भी कंटेनर इस तरह से व्यवस्थित किए गए थे। यह प्रोग्रामिंग में बहुत अच्छा काम करता है, तो यहां भी काम क्यों नहीं किया जाता है?

उदाहरण

आइए इस उदाहरण को एक्सट्रापोल करने की कोशिश करते हैं, कहते हैं, टैब पर।

<div class="tabbed"> <ul class="_tabs container selectable"> <li class="tab item selected">…</li> <li class="tab item">…</li> … </ul> <div class="_pages container selectable"> <div class="panel item selected">…</div> <div class="panel item">…</div> … </div> </div> 

टैब्ड इंटरफ़ेस _tabs और _pages कंटेनरों तक पहुंच प्रदान करने के लिए प्रतिबद्ध है। इसका मतलब यह है कि यदि आपके पास कोई वस्तु है जो इस अनुबंध को लागू करती है, तो आपको संबंधित कंटेनरों तक पहुंचने के लिए getTabs और getPages विधियों को कॉल करने का अधिकार है। हम बाद के बारे में जानते हैं कि वे कंटेनर अनुबंध को लागू करते हैं, जिसका अर्थ है कि उनके पास बुकमार्क संग्रह के साथ काम करने के लिए सभी आवश्यक कार्य हैं, जिसमें पहले / अंतिम / विषम / सम और अन्य सूचियों के लिए विशिष्ट शैलियों का प्रसंस्करण शामिल है। यही है, टैब को हटाने के लिए फ़ंक्शन को सुदृढ़ करना आवश्यक नहीं होगा।

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

 getSelected: function() { return $(this.dom).find(".item.selected").first(); }, deselect: function() { $(this.dom).getSelected().removeClass("selected") ; }, select: function (item) { this.deselect(); $(item.dom).addClass("selected"); } 

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

यदि, आप कहते हैं, आप ड्रैग एंड एनलड्रॉप के साथ टैब को खींचने और छोड़ने की क्षमता जोड़ना चाहते हैं, तो बस ड्रैग / ड्रॉप कॉन्ट्रैक्ट्स जोड़ें, जो तुरंत इस उद्देश्य के लिए तैयार किए गए सभी विशिष्ट कार्यों को सक्षम करेगा।

लेकिन अगर आप केवल BEM शैली में tabbed_tabs__item लिखते हैं, तो रंग तुरंत फीका हो जाएगा। आखिरकार, सभी कोड जो हमेशा ".item" चयनकर्ता के साथ काम करते थे, विभिन्न प्रकार के विजेट के लिए काम करना बंद कर दिया। आपके पास कई प्रकार के टैब डिस्प्ले हैं, लेकिन अब वे भी काम नहीं करते हैं। उन्हें मुझ पर आपत्ति हो सकती है कि एक ही jQuery के लिए विशेष एक्सटेंशन हैं जो मुझे इस सभी वाक्यविन्यास कचरे से निपटने में मदद करेंगे। लेकिन मुझे अभी तक समझ नहीं आया कि समस्याएं क्यों पैदा होती हैं, और फिर उन्हें हल करें।

मानकों

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

ऐसे अनुबंधों के आधार पर, आंतरिक मानकों को लागू करना और सत्यापनकर्ताओं को लागू करना बहुत आसान है जो कोड की गुणवत्ता को निरंतर समीक्षा के तहत रखेगा। यह प्रक्रिया में सभी प्रतिभागियों को, नए जुड़े लोगों सहित, उसी तरह से सोचने की अनुमति देगा। शुरुआत में - अनिवार्य रूप से, और फिर आदत से बाहर। आखिरकार, जैसे ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में, कॉन्ट्रैक्ट्स को वैसे ही पेश नहीं किया जाता है, बल्कि एक विचारशील कार्य का परिणाम होता है, इसलिए सीएसएस वर्ग के नामों में अनायास, विचारहीन रूप से उत्पन्न नहीं होना चाहिए। आखिरकार, BEM, हालांकि विकास के संरचनात्मक पहलू को नियंत्रित करने की कोशिश कर रहा है, लेकिन पूरी तरह से सिस्टम को याद करता है। कोई टैब टैब कहेगा, कोई टैब-कंट्रोल, कोई दूसरा टैब-विजेट। उदाहरण के लिए, लेख की शुरुआत में उदाहरण से Yandex लॉगिन फ़ॉर्म को "बी-डोमिक" कहा जाता है। यह बहुत अच्छा है कि इसे लॉगिन, साइनअप या कुछ और सार्थक नहीं कहा जाए, लेकिन "द्वि-घर"। मुझे पुराने संस्थान की याद है "एक घर के साथ पाई और एक प्यारे के साथ पाई।" शीर्ष रचनात्मक, लेकिन सत्यापन और रीफैक्टरिंग के लिए नरक। यदि आप अचानक लॉगिन के सभी रूपों को खोजना चाहते हैं और वहां नए विकल्प जोड़ते हैं (जैसे, कुछ नई सामाजिक सेवा के माध्यम से पहचान करना), तो आपको इस द्वि-घर को पकड़ना होगा, यह पता लगाना होगा कि यांडेक्स मेल में इसे पहले से ही बी-मेल-डोमिक कहा जाता है, कवर पेज से “लॉग इन टू मेल” लिंक पहले से ही b-popupa__wrap वर्ग के साथ एक लॉगिन फ़ॉर्म है। और कितने "अद्भुत खोजों" को आपने अभी तक तैयार किया है ...

यह मुझे लगता है कि लेआउट डिजाइनरों को वर्ग के नामों का आविष्कार नहीं करना चाहिए। HTML और JS के बीच इंटरफेस प्रदान करना डिजाइनरों द्वारा किया जाना चाहिए। वे इस जानकारी को एचटीएमएल / सीएसएस श्रमिकों को अनुबंध, व्यवस्थित और संचारित करते हैं। यह जेएस कोड को स्केलेबिलिटी देता है, और कॉरपोरेट मानकों के अनुसार पुन: उपयोग, और रीफैक्टरिंग, और सत्यापन होता है, जिसका अर्थ है गुणवत्ता। यह मुझे लगता है कि यह काफी काफी है क्योंकि यह प्रतिबिंबित होने का कारण है।

सीएसएस प्रीप्रोसेसर

अंत में, मैं ध्यान देता हूं कि इस तरह की शैलियाँ काफी आसानी से और व्यवस्थित रूप से LESS / SASS / Stylus के पूर्वजों की भावना में वर्णित हैं:

 .tabbed { … ._tabs { …. .item { …. .selected { … } } } … } 

इस तरह, विभिन्न खाल को आसानी से एकत्र और पुन: उपयोग किया जा सकता है। इसके अलावा, संकलन के दौरान यह सब शब्दार्थ BEM चयनकर्ताओं को उत्पन्न करेगा, क्योंकि .tabbed__tabs.item {...} और .tabbed_tabs__item {...} के बीच कोई महत्वपूर्ण अंतर नहीं है।