🙅🏻 🖖🏻 ☄️ पूर्ववत करें / फिर से करें - पूंछ कुत्ते को लहराती है 🚪 🙅🏻 🤵

इस लेख में, हम इस बारे में बात करना जारी रखेंगे कि हमने XtraRichEdit टेक्स्ट एडिटर में Undo / Redo कैसे किया।

यह सब इस तथ्य से शुरू हुआ कि हमारी टीम को इस अवधारणा को ध्यान में लाने की इच्छा के साथ एक पाठ संपादक की अवधारणा का स्रोत दिया गया था। इस तथ्य के बावजूद कि अवधारणा को विकसित करने में केवल एक महीना खर्च किया गया था, वह बहुत कुछ करने में सक्षम था: आप पाठ दर्ज कर सकते हैं और हटा सकते हैं, कर्सर को क्षैतिज और लंबवत रूप से स्थानांतरित कर सकते हैं।

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

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

public class DocumentHistoryItem : HistoryItem { readonly DocumentState previousState; readonly DocumentState nextState; public DocumentHistoryItem(DocumentState previousState, DocumentState nextState) { this.previousState = previousState; this.nextState = nextState; } public override void Undo(Document document) { document.ApplyState(previousState); } public override void Redo(Document document) { document.ApplyState(nextState); } }

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

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

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

अंत में, मौजूदा कोड में Undo / Redo को एम्बेड करने के कई असफल प्रयास करने के बाद, हम इस निष्कर्ष पर पहुंचे: Undo / Redo के साथ समस्याओं से बचने के लिए, विशेष रूप से डेटा संरचनाओं और एल्गोरिदम को फिर से डिज़ाइन करना आवश्यक है।

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

 public class CompositeHistoryItem : HistoryItem { readonly List<HistoryItem> items = new List<HistoryItem>(); public void AddItem(HistoryItem item) { items.Add(item); } protected override void UndoCore() { for (int i = items.Count - 1; i >= 0; i--) items[i].Undo(); } protected override void RedoCore() { int count = items.Count; for (int i = 0; i < count; i++) items[i].Redo(); } }

ध्यान दें कि संयुक्त संचालन के तत्वों का रोलबैक रिवर्स ऑर्डर में किया जाता है, और रोलबैक को सीधे क्रम में किया जाता है।

प्राथमिक कार्यों में क्रियाओं को तोड़ने के लिए, हमें एक विशेष तरीके से डेटा संरचनाओं को व्यवस्थित करना पड़ा। हमने पैराग्राफ के अंदर पाठ को इस तरह से रन में विभाजित किया है कि प्रत्येक अंतराल के भीतर पाठ का स्वरूपण समान था।

जब मनमाने ढंग से चयनित पाठ के स्वरूपण को बदलते हैं, तो पाठ को पहले चयन के अनुसार अंतराल में विभाजित किया जाता था, और फिर चयन के अंदर उन अंतरालों के प्रारूपण को बदल दिया जाता था। इस प्रकार, 3 प्राथमिक ऑपरेशन "अंतराल को विभाजित करते हैं", "2 आसन्न अंतराल को मिलाएं" और "अंतराल के स्वरूपण को परिवर्तित करें" को प्रतिष्ठित किया गया था।

अंतिम प्राथमिक ऑपरेशन अलग विचार का हकदार है। पूर्ववत बफर में संग्रहीत डेटा की मात्रा को कम करने के लिए, अंतराल में पाठ गुणों वाले ऑब्जेक्ट को दो सबोबेक्ट्स में विभाजित किया गया था: उत्परिवर्तनीय (CharacterFormattingBase) और अपरिवर्तनीय (CharacterFormattingInfo)। अपरिवर्तनीय वस्तुओं को कैश सूची (CharacterFormattingInfoCache) में संग्रहीत किया गया था, और सूची के तत्व अद्वितीय थे और सूची से कभी हटाए नहीं गए थे। उत्परिवर्तनीय वस्तुएं सूची में केवल अपरिवर्तनीय वस्तु का सूचकांक संग्रहीत करती हैं।

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

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

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

और अंत में, एक कार्रवाई के एक उदाहरण और प्राथमिक कार्यों में इसके विभाजन पर विचार करें।

प्रारंभ में, पाठ का एक सतत और एकल टुकड़ा है:

बोल्ड "पाठ" के एक हिस्से को हाइलाइट करें।

इस क्रिया को 3 प्राथमिक क्रियाओं में विभाजित किया जा सकता है:

हम पाठ को 2 आसन्न खंडों में तोड़ते हैं।

हम पाठ के दाहिने भाग को 2 और वर्गों में तोड़ते हैं।

इंडेक्स 1 के साथ प्लॉट के लिए, बोल्ड फ़ॉन्ट लागू करें।

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

यह पता चलता है कि डेटा को बेहतर तरीके से व्यवस्थित करने के लिए पूर्ववत करें / फिर से करें। अर्थात्: पाठ को खंडों में विभाजित किया जाना चाहिए ताकि एक खंड के पूरे पाठ में समान स्वरूपण हो। पार्सल नम्बरवार होने चाहिए। यह ऐसे डेटा संगठन के साथ है जो प्राथमिक संचालन में कार्रवाई का एक प्राकृतिक और सरल विभाजन है। और यह बदले में, पूर्ववत करें / फिर से लागू करने के सरलीकरण की ओर जाता है और संग्रहीत किए जाने वाले डेटा की मात्रा को कम करता है।

XtraRichEdit को विकसित करते समय, हमने शुरू में “पूर्ववत / फिर से” दृष्टिकोण का उपयोग करना शुरू किया। प्रत्येक क्रिया को डिजाइन करते समय, हमने पहले इस पर विचार किया कि इस कार्रवाई को पूर्ववत् / फिर से अवधारणा में कैसे रखा जाए, इसे शुरू करने के लिए क्या प्राथमिक संचालन किया जाए, और स्मृति में संग्रहीत न्यूनतम डेटा के साथ कैसे प्राप्त किया जाए। इसने हमें एक दस्तावेज़ मॉडल बनाने की अनुमति दी, जो लागू करने के लिए सरल है, जो स्मृति का कुशलतापूर्वक उपयोग करता है और दस्तावेज़ स्वरूपण के दौरान मॉडल के चारों ओर घूमते समय और इसके लिए कई प्रकार के परिवर्तन करते समय महत्वपूर्ण कम्प्यूटेशनल संसाधनों की आवश्यकता नहीं होती है।

इस विषय पर पिछला लेख | इस विषय पर अगला लेख

पूर्ववत करें / फिर से करें - पूंछ कुत्ते को लहराती है

More articles: