विजार्ड्स और वारियर्स में नियमों की परिकल्पना

9

में ब्लॉग पोस्ट की इस श्रृंखला , एरिक Lippert जादूगरों और उदाहरण है, जहां के रूप में योद्धाओं का उपयोग कर वस्तु उन्मुख डिजाइन में एक समस्या का वर्णन करता है:

abstract class Weapon { }
sealed class Staff : Weapon { }
sealed class Sword : Weapon { }

abstract class Player 
{ 
  public Weapon Weapon { get; set; }
}
sealed class Wizard : Player { }
sealed class Warrior : Player { }

और फिर कुछ नियम जोड़ता है:

एक योद्धा केवल एक तलवार का उपयोग कर सकता है।
एक जादूगर केवल एक कर्मचारी का उपयोग कर सकता है।

वह तब आपके द्वारा चलाए जा रहे समस्याओं को प्रदर्शित करने के लिए जाता है यदि आप सी # प्रकार प्रणाली का उपयोग करके इन नियमों को लागू करने का प्रयास करते हैं (उदाहरण के लिए Wizardवर्ग को यह सुनिश्चित करने के लिए जिम्मेदार बनाते हैं कि एक विज़ार्ड केवल एक कर्मचारी का उपयोग कर सकता है)। आप लिस्कोव सबस्टीट्यूशन सिद्धांत का उल्लंघन करते हैं, रन-टाइम अपवादों को जोखिम में डालते हैं या उस कोड के साथ समाप्त हो जाते हैं जिसका विस्तार करना मुश्किल है।

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

player.Weapon = new Sword();

राज्य Commandको Rules के अनुसार संशोधित किया गया है :

... हम एक Commandवस्तु बनाते हैं जिसे Wieldदो गेम स्टेट ऑब्जेक्ट्स कहते हैं, a Playerऔर a Weapon। जब उपयोगकर्ता सिस्टम के लिए एक कमांड जारी करता है "इस विज़ार्ड को उस तलवार को मिटा देना चाहिए", तो उस कमांड का मूल्यांकन Ruleएस के एक सेट के संदर्भ में किया जाता है , जो Effectएस के अनुक्रम का उत्पादन करता है । हमारे पास एक Ruleऐसा है जो कहता है कि जब कोई खिलाड़ी किसी हथियार को छेड़ने का प्रयास करता है, तो प्रभाव यह होता है कि मौजूदा हथियार, यदि कोई है, तो उसे गिरा दिया जाता है और नया हथियार खिलाड़ी का हथियार बन जाता है। हमारे पास एक और नियम है जो पहले नियम को मजबूत करता है, जो कहता है कि पहले नियम के प्रभाव तब लागू नहीं होते हैं जब कोई जादूगर तलवार लहराने की कोशिश करता है।

मैं इस विचार को सिद्धांत रूप में पसंद करता हूं, लेकिन इस बारे में एक चिंता है कि इसका उपयोग कैसे किया जा सकता है।

कुछ भी नहीं लगता है कि एक डेवलपर को केवल एक पर सेट करके Commandsऔर चक्कर लगाने से रोकना है । संपत्ति से सुलभ होने की जरूरत है , तो यह नहीं किया जा सकता, आदेश ।RuleWeaponPlayerWeaponWieldprivate set

तो, क्या करता है ऐसा करने से एक डेवलपर को रोकने? क्या उन्हें सिर्फ याद नहीं करना है?

c# design-patterns object-oriented solid

— बेन एल
स्रोत

2

मुझे नहीं लगता कि यह प्रश्न भाषा विशिष्ट (C #) है क्योंकि यह वास्तव में OOP डिज़ाइन के बारे में एक प्रश्न है। कृपया सी # टैग हटाने पर विचार करें।

— है_Factor

1

@maybe_factor c # टैग ठीक है क्योंकि पोस्ट किया गया कोड # है।

— कोडिंगयॉशी 2

आप सीधे @EricLippert क्यों नहीं पूछते? वह समय-समय पर इस साइट पर यहां दिखाई देते हैं।

— डॉक्टर ब्राउन

@Maybe_Factor - मैंने C # टैग पर छूट दी, लेकिन इसे भाषा-विशिष्ट समाधान होने की स्थिति में रखने का निर्णय लिया।

— बेन एल

1

@DocBrown - मैंने यह सवाल उनके ब्लॉग पर पोस्ट किया था (केवल कुछ दिन पहले ही स्वीकार किया था; मैंने उस प्रतिक्रिया का लंबे समय तक इंतजार नहीं किया है)। क्या मेरे सवाल को उनके ध्यान में लाने का कोई तरीका है?

— बेन एल

9

संपूर्ण तर्क जो ब्लॉग पोस्ट की श्रृंखला को आगे बढ़ाता है वह भाग पांच में है :

हमारे पास यह मानने का कोई कारण नहीं है कि सी # प्रकार प्रणाली को डंगऑन और ड्रेगन के नियमों को एन्कोड करने के लिए पर्याप्त व्यापकता के लिए डिज़ाइन किया गया था, इसलिए हम भी क्यों कोशिश कर रहे हैं?

हमने इस समस्या को हल किया है "कोड कहां जाता है जो सिस्टम के नियमों को व्यक्त करता है?" यह उन वस्तुओं में जाता है जो सिस्टम के नियमों का प्रतिनिधित्व करते हैं, न कि उन वस्तुओं में जो खेल राज्य का प्रतिनिधित्व करती हैं; राज्य की वस्तुओं की चिंता उनके राज्य को बनाए रखती है, न कि खेल के नियमों का मूल्यांकन करने में।

हथियार, पात्र, राक्षस और अन्य खेल वस्तुएं यह जांचने के लिए ज़िम्मेदार नहीं हैं कि वे क्या कर सकते हैं या क्या नहीं। उसके लिए शासन प्रणाली जिम्मेदार है। Commandवस्तु या तो खेल वस्तुओं के साथ कुछ नहीं कर रहा है। यह सिर्फ उनके साथ कुछ करने के प्रयास का प्रतिनिधित्व करता है। नियम प्रणाली तब यह जांचती है कि क्या कमांड संभव है, और जब यह नियम प्रणाली खेल वस्तुओं पर उपयुक्त विधियों को कॉल करके कमांड निष्पादित करती है।

यदि कोई डेवलपर एक दूसरी नियम प्रणाली बनाना चाहता है जो पात्रों और हथियारों के साथ काम करती है जिसे पहले नियम प्रणाली अनुमति नहीं देती है, तो वे ऐसा कर सकते हैं क्योंकि C # में आप (बिना परावर्तन किए हैक के बिना) पता कर सकते हैं कि कोई पद्धति-कॉल कहाँ आती है से।

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

— फिलिप
स्रोत

4

मूल कोड की स्पष्ट समस्या यह है कि यह ऑब्जेक्ट मॉडलिंग के बजाय डेटा मॉडलिंग कर रहा है । कृपया ध्यान दें कि लिंक किए गए लेख में वास्तविक व्यावसायिक आवश्यकताओं का कोई उल्लेख नहीं है!

मैं वास्तविक कार्यात्मक आवश्यकताओं को प्राप्त करने की कोशिश कर रहा हूं। उदाहरण के लिए: "कोई भी खिलाड़ी किसी भी अन्य खिलाड़ियों पर हमला कर सकता है, ..."। यहाँ:

interface Player {
    void Attack(Player enemy);
}

"खिलाड़ी उस हथियार का इस्तेमाल कर सकते हैं जिसका इस्तेमाल हमले में किया जाता है, विजार्ड्स एक कर्मचारी, योद्धाओं को तलवार से मार सकता है":

public class Wizard: Player {
    ...
    public void Wield(Staff weapon) { ... }
    ...
}
public class Warrior: Player {
    ...
    public void Wield(Sword sword) { ... }
    ...
}

"प्रत्येक हथियार हमले वाले दुश्मन को नुकसान पहुंचाता है"। ठीक है, अब हमारे पास हथियार के लिए एक सामान्य इंटरफ़ेस है:

interface Weapon {
    void dealDamageTo(Player enemy);
}

और इतने पर ... क्यों वहाँ कोई नहीं Wield()है Player? क्योंकि इसमें कोई आवश्यकता नहीं थी कि कोई भी खिलाड़ी किसी भी हथियार को मिटा सकता है।

मैं छवि दे सकता हूं, कि एक आवश्यकता होगी जो कहती है: "कोई भी किसी Playerको भी लुभाने की कोशिश कर सकता है Weapon।" हालांकि यह एक पूरी तरह से अलग बात होगी। मैं इसे शायद इस तरह से मॉडल करूंगा:

interface Player {
    void Attack(Player enemy);
    void TryWielding(Weapon weapon); // Throws UnwieldableException
}

सारांश: आवश्यकताओं को मॉडल करें, और केवल आवश्यकताएं। डेटा मॉडलिंग न करें, वह ओओ मॉडलिंग नहीं है।

— रॉबर्ट ब्रुटिगम
स्रोत

1

क्या आपने श्रृंखला पढ़ी? हो सकता है कि आप उस श्रृंखला के लेखक को डेटा नहीं बल्कि आवश्यकताएं बताना चाहते हों। आपके जवाब में आपके द्वारा की गई rquirements आपकी बनी -बनाई आवश्यकताएं हैं जो C # कंपाइलर बनाते समय लेखक की आवश्यकताएं नहीं थीं।

— कोडिंगयॉशी 12

2

एरिक लिपर्ट उस श्रृंखला में एक तकनीकी समस्या का विवरण दे रहे हैं, जो ठीक है। यह प्रश्न वास्तविक समस्या के बारे में है, न कि C # सुविधाओं के बारे में। मेरा कहना है, वास्तविक परियोजनाओं में हम व्यावसायिक आवश्यकताओं का पालन करने वाले हैं (जिनके लिए मैंने उदाहरण दिए हैं, हां), संबंधों और गुणों को नहीं मानें । यही कारण है कि आप एक मॉडल प्राप्त करते हैं जो फिट बैठता है। जो कि विचित्र था।

— रॉबर्ट ब्रूटिगम

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

— वादिम समोखिन

यह सही जवाब है। लेख परस्पर विरोधी आवश्यकताओं को व्यक्त करता है (एक आवश्यकता यह कहती है कि एक खिलाड़ी [किसी भी] हथियार को मिटा सकता है, जबकि अन्य आवश्यकताओं का कहना है कि यह मामला नहीं है।) और फिर यह विवरण प्रणाली के लिए संघर्ष को सही ढंग से व्यक्त करना कितना कठिन है। संघर्ष को हटाने के लिए एकमात्र सही उत्तर है। इस मामले में, इसका मतलब है कि एक खिलाड़ी किसी भी हथियार को छेड़ सकता है।

— डेनियल टी।

2

एक तरीका होगा Wieldकमांड को पास करना Player। खिलाड़ी तब Wieldकमांड को निष्पादित करता है , जो उचित नियमों की जांच करता है और वापस लौटाता है Weapon, जो Playerतब अपने हथियार क्षेत्र के साथ सेट करता है। इस तरह, हथियार क्षेत्र में एक निजी सेटर हो सकता है और केवल Wieldखिलाड़ी को एक कमांड पास करने के माध्यम से तय किया जा सकता है ।

— Maybe_Factor
स्रोत

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

— कोडिंगयॉशी 12

2

कुछ भी नहीं डेवलपर को ऐसा करने से रोकता है। वास्तव में एरिक लिपर्ट ने कई अलग-अलग तकनीकों की कोशिश की लेकिन उनमें सभी कमजोरियां थीं। यह उस श्रृंखला का संपूर्ण बिंदु था जो डेवलपर को ऐसा करने से रोकना आसान नहीं है और उसने जो कुछ भी आजमाया वह नुकसान था। अंत में उन्होंने निर्णय लिया कि Commandनियमों के साथ किसी वस्तु का उपयोग करना है।

नियमों के साथ, आप Weaponएक Wizardहोने की संपत्ति निर्धारित कर सकते हैं, Swordलेकिन जब आप Wizardहथियार (तलवार) को फिराने के लिए कहेंगे और हमला करेंगे तो इसका कोई प्रभाव नहीं होगा और इसलिए यह किसी भी राज्य को नहीं बदलेगा। जैसा कि वह नीचे कहता है:

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

दूसरे शब्दों में, हम typeरिश्तों के माध्यम से इस तरह के नियम को लागू नहीं कर सकते हैं, जिसमें उन्होंने कई अलग-अलग तरीकों की कोशिश की, लेकिन या तो इसे पसंद नहीं किया या काम नहीं किया। इस प्रकार केवल एक चीज जो हमने कही है, वह यह है कि इसके बारे में कुछ करना है। एक अपवाद को फेंकना अच्छा नहीं था क्योंकि वह इसे अपवाद नहीं मानता।

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

मुझे लगता है कि इसका एक अच्छा समाधान है। हालांकि कुछ मामलों में मैं कोशिश सेट पैटर्न के साथ भी जाना होगा।

— CodingYoshi
स्रोत

This solution basically says you can set any weapon but when you yield it, if not the right weapon, it would be essentially useless.

मैं उस श्रृंखला में इसे खोजने में विफल रहा, क्या आप कृपया मुझे बता सकते हैं कि यह समाधान कहाँ प्रस्तावित है?

— वादिम समोखिन

@ ज़ापडलो वह इसे अप्रत्यक्ष रूप से कहते हैं। मैंने अपने उत्तर में उस हिस्से की नकल की और उसे उद्धृत किया। यहाँ यह फिर से है। उद्धरण में वह कहता है: जब कोई जादूगर तलवार लहराने की कोशिश करता है। अगर तलवार न लगाई जाए तो जादूगर तलवार कैसे उठा सकता है? इसे सेट किया गया होगा। फिर अगर कोई जादूगर तलवार

— उठाता है

हम्म, मुझे लगता है कि मूल रूप से तलवारें चलाने का मतलब है कि इसे सेट किया जाना चाहिए, नहीं? जैसा कि मैंने उस पैराग्राफ को पढ़ा है, मैं इसकी व्याख्या करता हूं कि पहला नियम का प्रभाव है that the existing weapon, if there is one, is dropped and the new weapon becomes the player’s weapon। जबकि दूसरा नियम जो

that strengthens the first rule, that says that the first rule’s effects do not apply when a wizard tries to wield a sword.

कि मुझे लगता है कि हथियार की तलवार है तो एक नियम की जाँच होती है, इसलिए इसे एक wizzard द्वारा मिटाया नहीं जा सकता है, इसलिए इसे सेट नहीं किया जाता है। इसके बजाय एक उदास ट्रॉम्बोन लगता है।

— वादिम समोखिन

मेरी सोच के लिए यह अजीब होगा कि कुछ कमांड नियम का उल्लंघन होता है। यह एक समस्या पर धुंधला होने जैसा है। एक नियम के उल्लंघन के बाद और एक अमान्य राज्य में विज़ार्ड स्थापित करने के बाद इस समस्या से निपटने क्यों? जादूगर के पास तलवार नहीं हो सकती है, लेकिन यह है! क्यों नहीं होने दिया?

— वादिम समोखिन

मैं Wieldयहाँ व्याख्या करने के तरीके पर @Zapadlo से सहमत हूँ । मुझे लगता है कि यह कमांड के लिए थोड़ा भ्रामक नाम है। कुछ ChangeWeaponज्यादा ही सटीक होगा। मुझे लगता है कि आपके पास एक अलग मॉडल हो सकता है जहां आप किसी भी हथियार को सेट कर सकते हैं लेकिन जब आप इसे उपजते हैं, अगर सही हथियार नहीं है, तो यह अनिवार्य रूप से बेकार होगा । यह दिलचस्प लगता है, लेकिन मुझे नहीं लगता कि यह एरिक लिपर्ट का वर्णन है।

— बेन एल

2

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

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

अंत में, केवल एक चीज जो डेवलपर्स को गलतियां करने से रोक सकती है, वह यह है कि सभी नियमों का पालन करने वाले (यूनिट) परीक्षणों का एक सेट है।

— larsbe
स्रोत

आप एक एपीआई का उपयोग कर रहे हैं और एपीआई यह सुनिश्चित करने के लिए है कि आप इकाई परीक्षण करेंगे या उस धारणा को बनाएंगे? Th पूरी चुनौती मॉडलिंग के बारे में है इसलिए मॉडल का उपयोग करने वाले डेवलपर के लापरवाह होने पर भी मॉडल नहीं टूटता है।

— कोडिंगयॉशी

1

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

— लार्सबे

1

मुझे यहां एक सूक्ष्मता याद आ गई होगी, लेकिन मुझे यकीन नहीं है कि समस्या टाइप सिस्टम के साथ है। शायद यह सी # में सम्मेलन के साथ है।

उदाहरण के लिए, आप Weaponसेटर को संरक्षित करके इसे पूरी तरह से सुरक्षित बना सकते हैं Player। फिर जोड़ने setSword(Sword)और setStaff(Staff)करने के लिए Warriorऔर Wizardक्रमशः है कि कॉल संरक्षित सेटर।

इस तरह, Player/ Weaponरिश्ते को सांख्यिकीय रूप से जांचा जाता है और कोड जो परवाह नहीं करता है बस एक Playerपाने के लिए ए का उपयोग कर सकता है Weapon।

— एलेक्स
स्रोत

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

— कोडिंगयॉशी

@CodingYoshi यह अपवाद क्यों होगा? यह संकलन समय पर सुरक्षित यानी जाँच योग्य है।

— एलेक्स

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

— कोडिंगयॉशी 13

@CodingYoshi पॉलिमॉर्फिक आवश्यकता यह है कि एक खिलाड़ी एक हथियार है। और इस योजना में, प्लेयर के पास वास्तव में एक हथियार है। कोई विरासत टूटी नहीं है। यह समाधान केवल तभी संकलित करेगा जब आपको नियम सही मिलेंगे।

— एलेक्स

@ कोडिंगयॉशी, इसका मतलब यह नहीं है कि आप कोड नहीं लिख सकते हैं, जैसे कि रनटाइम चेक की आवश्यकता होगी यदि आप ए Weaponको जोड़ने की कोशिश करते हैं Player। लेकिन कोई भी प्रकार की प्रणाली नहीं है जहां आप संकलन समय पर ठोस प्रकारों को नहीं जानते हैं जो संकलन के समय उन ठोस प्रकारों पर कार्य कर सकते हैं। परिभाषा से। इस योजना का मतलब है कि यह केवल उस मामले में है जिसे रनटाइम के साथ निपटाया जाना चाहिए, जैसा कि वास्तव में एरिक की किसी भी योजना से बेहतर है।

— एलेक्स

0

तो, एक डेवलपर को ऐसा करने से क्या रोकता है? क्या उन्हें सिर्फ याद नहीं करना है?

यह प्रश्न प्रभावी रूप से सुंदर पवित्र-युद्ध-ईश विषय के साथ समान है, जिसे " जहां मान्यता देना है " कहा जाता है (सबसे शायद ध्यान देने योग्य है)।

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

यदि नहीं - ठीक है, यह स्वाभाविक रूप से तात्पर्य है कि यह नियम विशिष्ट हैं और डोमेन संस्थाओं में निवास नहीं करना चाहिए। इसलिए इस नियमों का उल्लंघन करने पर ऐसी कार्रवाइयां होती हैं, जिन्हें करने की अनुमति नहीं होनी चाहिए, लेकिन अमान्य मॉडल स्थिति में नहीं।

— वदिम समोखिन
स्रोत