👩‍🚒 😁 🈂️ पूर्ववत करें / फिर से करें - सादगी का भ्रम 🎸 👨‍👧‍👧 👲🏽

किसी भी पाठ और ग्राफिक्स संपादक में इस तरह के एक सरल और परिचित फ़ंक्शन। ऐसा लगता है, इसके कार्यान्वयन में क्या कठिनाइयाँ हो सकती हैं? जब हमने पहली बार XtraRichEdit टेक्स्ट एडिटर के लिए Undo / Redo के विकास का सामना किया, तो हमें आश्चर्य हुआ , लेकिन हमें क्या दृष्टिकोण अपनाना चाहिए?

यह स्पष्ट था कि परिवर्तनों के इतिहास के लिए जिम्मेदार एक वस्तु होनी चाहिए। इस ऑब्जेक्ट में व्यक्तिगत कार्यों का प्रतिनिधित्व करने वाले तत्वों की एक सूची होनी चाहिए। प्रत्येक ऐसे तत्व को कार्रवाई (पूर्ववत) को वापस करने के लिए पर्याप्त जानकारी संग्रहीत करनी चाहिए, और इसे (Redo) भी दोहराना चाहिए।

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

public abstract class HistoryItem { public abstract void Undo(Document document); public abstract void Redo(Document document); }

पूर्ववत बफर के लिए वर्ग का पहला प्रोटोटाइप इस प्रकार था:

 public class History { readonly List<HistoryItem> items = new List<HistoryItem>(); public History(Document document) { this.document = document; } public void Undo() { } public void Redo() { } public void Add(HistoryItem item) { items.Add(item); } }

हाथ बाहर पहुंचें और पूर्ववत विधि लिखें:

 public void Undo() { items[items.Count - 1].Undo(document); }

गर्व से, शान से ... लेकिन पूरी तरह से गलत।

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

 public bool CanUndo { get { return items.Count > 0; } } public void Undo() { if (!CanUndo) return; items[items.Count - 1].Undo(document); }

और फिर से हमें गलत कोड मिलता है। आखिरकार, यदि आप एक पंक्ति में कई बार पूर्ववत् विधि को कॉल करते हैं, तो सूची में अंतिम तत्व के लिए फिर से और फिर से पूर्ववत् कहा जाएगा, जो गलत है। हम परिवर्तन करते हैं:

 public void Undo() { if (!CanUndo) return; items[items.Count - 1].Undo(document); items.RemoveAt(items.Count - 1); }

अब सब ठीक है। खैर, यह रेडो के लिए नीचे उतरने का समय है। कुछ भी जटिल नहीं है ...

 public void Redo() { if (!CanRedo) return; // ??? }

ऊप्स! हम पहुंचे।

Undo के हमारे कार्यान्वयन में, रोलबैक प्रक्रिया में, हम अनियमित रूप से रोल किए गए बैक एलिमेंट्स को खो देते हैं, इसलिए Redo करने के लिए कोई भी नहीं है। आपको क्लिपबोर्ड में वर्तमान आइटम की ओर इशारा करते हुए एक इंडेक्स प्राप्त करना होगा। तो:

 int currentIndex = -1; public bool CanUndo { get { return currentIndex >= 0; } } public bool CanRedo { get { return items.Count > 0 && currentIndex < items.Count - 1; } } public void Undo() { if (!CanUndo) return; items[currentIndex].Undo(document); this.currentIndex--; } public void Redo() { if (!CanRedo) return; this.currentIndex++; items[currentIndex].Redo(document); } public void Add(HistoryItem item) { items.Add(item); this.currentIndex++; }

पहले से ही बेहतर है, कम से कम यह कुछ व्यावहारिक जैसा दिखता है। कृपया ध्यान दें कि पूर्ववत करें के मामले में सूचकांक रोलबैक के बाद बदलता है, और रोलो के पहले - रोलबैक के मामले में। इतिहास में एक तत्व जोड़ते समय हम सूचकांक को बढ़ाना भी नहीं भूले।

और अब आइए Add विधि को ध्यान से देखें और अपने आप से पूछें कि अगर हम इतिहास में 5 क्रियाओं को करते हैं और रिकॉर्ड करते हैं तो यह कैसे व्यवहार करेगा, तो उनमें से 3 को वापस ले लिया और एक नई क्रिया करने जा रहे हैं? यह सोचने और देखने के बाद कि यह दूसरों द्वारा कैसे किया गया था (हमारे सामने सब कुछ पहले ही चोरी हो चुका है), हम इस निष्कर्ष पर पहुंचे कि इस मामले में क्रियाओं के इतिहास का एक हिस्सा जो वर्तमान सूचकांक के बाद स्थित है, उसे खो दिया जाना चाहिए, और इसके बजाय नए कार्यों को रिकॉर्ड किया जाना शुरू होगा:

 public void Add(HistoryItem item) { CutOffHistory(); items.Add(item); this.currentIndex++; } void CutOffHistory() { int index = currentIndex + 1; if (index < Count) items.RemoveRange(index, Count - index); }

अब, अंत में, पूर्ववत करें / फिर से लागू करना सरल हो गया है।

आइए इस बारे में सोचें कि हम इसका उपयोग कैसे करेंगे। पहली चीज जो आपके सिर में जाती है वह है क्रियाओं का क्रम:

एक क्रिया करें;
हमने इस कार्रवाई के बारे में जानकारी आगे रोलबैक / रिट्री के लिए पूर्ववत बफर में डाल दी।

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

हम एक पूर्ववत बफर तत्व बनाते हैं, और इसे आगे रोलबैक / रीडो के लिए पूर्ववत बफर में डालते हैं;
इस तत्व के लिए Redo चलाएँ:

 void DoAction() { HistoryItem item = CreateActionHistoryItem(); document.History.Add(item); item.Redo(document); }

यह सुंदर और खूबसूरती से निकला। किसी कार्रवाई का पहला निष्पादन अपने वर्तमान स्थिति से उस कार्रवाई का Redo है। रोलबैक - वर्तमान स्थिति से पूर्ववत करें। उस समय वर्तमान स्थिति से किसी ऑपरेशन को फिर से निष्पादित करना।

अंतिम वाक्यों में, हमने कई बार राज्य शब्द का इस्तेमाल किया है। तथ्य यह है कि पूर्ववत बफर में संग्रहीत जानकारी बचत के समय पूरी तरह से सही है। हालाँकि, पहले से ही अगले क्षण यह गलत हो सकता है। सबसे सरल उदाहरण है। हमारे पास पाठ है "हैलो वर्ल्ड!"।

हम "विश्व" शब्द से पहले "DevExpress" पाठ डालने का संचालन करते हैं। उसी समय, हम पूर्ववत जानकारी में डाल देंगे कि पाठ "DevExpress" सूचकांक 6 (0 से गिनती) के साथ स्थिति में डाला गया था।

हम निम्नलिखित क्रिया करते हैं: पाठ की शुरुआत में "हम कहते हैं:" लाइन डालें। बेशक, इस कार्रवाई के बाद, उस स्थिति के बारे में जानकारी जहां आप लाइन डालना चाहते हैं "DevExpress" गलत हो जाएगा।

यदि इस समय आप पहले ऑपरेशन के लिए पूर्ववत् कहते हैं, तो दस्तावेज़ की सामग्री दूषित हो जाएगी। जानकारी के सही होने के लिए, पुनर्गणना आवश्यक है।

क्या कुछ मामलों में पुनर्गणना के बिना करना संभव है? बेशक, हम कर सकते हैं, अगर हम मानते हैं कि प्रत्येक ऑपरेशन का रोलबैक दस्तावेज़ को उस स्थिति में लाता है जो ऑपरेशन के समय था। इसी तरह की आवश्यकता को दोहराने के संचालन पर लगाया जाना चाहिए।

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

यहां कुछ विचार दिए गए हैं जिनका उपयोग आप अपने स्वयं के पाठ या छवि संपादक के लिए एक साधारण पूर्ववत करें / फिर से करें प्रबंधक को लागू करते समय कर सकते हैं। हालांकि, जीवन में सब कुछ थोड़ा अलग तरीके से होता है, जैसा कि हम आपको अगले लेख में बताएंगे।

और यहां एक ही विषय पर एक चरम लेख का लिंक दिया गया है।

पुनश्च:

इस लेख को लिखने की प्रक्रिया में, हमारी दिलचस्पी बन गई, और जब पूर्ववत् दिखाई दिया तो ऐसी उपयोगी बात कब हुई?

परिश्रमपूर्वक चलते हुए, वे इस नतीजे पर पहुँचे कि 1971 से 1976 की अवधि में यह कहीं हुआ था। तो, आधुनिक एड एडिटर मैनुअल दावा करते हैं कि यह पूर्ववत समर्थन करता है। हालांकि, 1 9 71 के लिए पहले यूनिक्स से मैनुअल में , अभी तक पूर्ववत का कोई उल्लेख नहीं है। लेकिन vi संपादक में, जिसका पहला संस्करण 1976 में जारी किया गया था, पूर्ववत मूल रूप से लग रहा था।

पूर्ववत शब्द का उल्लेख किया गया था, शायद पहली बार, 1976 में भी: "यह काफी उपयोगी होगा, ताकि उपयोगकर्ताओं को कम से कम तुरंत पूर्ववर्ती कमांड (कुछ विशेष 'पूर्व कमांड' जारी करके) वापस ले सकें।" (लांस ए) मिलर और आईबीएम के जॉन सी। थॉमस, "इंटरएक्टिव सिस्टम के उपयोग में व्यवहार के मुद्दे।") (एनवाई टाइम्स पत्रिका, 5 वें पैराग्राफ देखें)।

पूर्ववत करें / फिर से करें - सादगी का भ्रम

More articles: