2.2 سافٹ ویئر ڈیزائن کے اصول

جائزہ اور محرکات

سافٹ ویئر ڈیزائن کے اصول کوڈ کو اس طرح ترتیب دینے کے رہنما اصول ہیں کہ آپ وقت کے ساتھ اسے سمجھ، بدل اور بڑھا سکیں۔ ان میں نام زد مخففات شامل ہیں (SOLID پانچ اشیا پر مبنی ڈیزائن اصولوں کے لیے، DRY خود کو نہ دہرائیں کے لیے، KISS اسے سادہ رکھیں کے لیے، YAGNI آپ کو اس کی ضرورت نہیں پڑے گی کے لیے)، ساختی تصورات (جوڑ، ہم آہنگی، تشویشات کی علیحدگی)، فہرست بند ڈیزائن کے نمونے، اعلیٰ سطحی ماڈلنگ کے طریقے جیسے ڈومین پر مبنی ڈیزائن (سافٹ ویئر کو کاروباری شعبے کی زبان میں ماڈل کرنا)، اور اشیا پر مبنی، فنکشنل اور ڈیٹا پر مبنی اسلوب کے درمیان انتخاب۔ ان میں سے کوئی قانون نہیں۔ یہ دبا ہوا تجربہ ہیں، اور آپ کو انہیں فہم کے ساتھ لاگو کرنا ہوتا ہے۔

بڑی ٹیموں کے لیے مشترک اصولوں کی قدر ہم آہنگی ہے۔ جب سینکڑوں انجینئر ایک ہی نظام پر کام کرتے ہیں تو انہیں ڈیزائن کی بحثوں کے لیے مشترک لغت اور مشترک ڈیفالٹس کا سیٹ چاہیے تاکہ آزادانہ لکھے گئے ماڈیول آپس میں فٹ ہوں۔ اچھا ڈیزائن ہی بہت سے لوگوں کو مسلسل ٹکراؤ کے بغیر متوازی طور پر نظام بدلنے دیتا ہے۔ یہی نظام کو دہائی بعد بھی قابل تبدیل رکھتا ہے، جو انٹرپرائز اور سرکاری نظاموں کی عام عمر ہے، ان کے اصل مصنفین کی مدت ملازمت سے کہیں آگے۔

اہم مہارت اصولوں کو یاد کرنا نہیں۔ یہ جاننا ہے کہ ہر ایک کب گمراہ کرتا ہے۔ ہر اصول کی ناکامی کا انداز ہے: DRY غلط تجرید پیدا کر سکتا ہے، SOLID بے ضرورت بالواسطگی پیدا کر سکتا ہے، YAGNI اس توسیع پذیری کو بھوکا رکھ سکتا ہے جس کی آپ کو واقعی ضرورت ہو۔ یہ باب اصولوں کو ایسے آلات سمجھتا ہے جن کا اطلاق کا دائرہ ہے، اور جوڑ اور ہم آہنگی پر زور دیتا ہے جو وہ گہری خصوصیات ہیں جن کی خدمت یہ مخففات کرنا چاہتے ہیں۔

بنیادی اصول

• پہلے جوڑ اور ہم آہنگی سنبھالیں؛ زیادہ تر نام زد اصول ان دو خصوصیات کو بہتر کرنے کے بالواسطہ طریقے ہیں۔
• تبدیلی کے لیے بہتری لائیں: اچھا ڈیزائن ان تبدیلیوں کی لاگت کم کرتا ہے جو آپ کو واقعی کرنی ہوں گی۔
• اب کام کرنے والا سادہ ترین ڈیزائن ترجیح دیں، مگر جہاں تبدیلی کا امکان ہو وہاں حدود رکھیں۔
• غلط تجرید سے تکرار سستی ہے؛ نمونہ صاف ہونے تک انتظار کریں۔
• انحصارات کو واضح بنائیں اور انہیں مستحکم چیزوں کی طرف رکھیں۔
• شعبے کو شعبے کی زبان میں ماڈل کریں؛ سافٹ ویئر کی حدوں کو کاروباری حدوں کے ساتھ ہم آہنگ کریں۔
• نمونے مسئلے کے مطابق چنیں، نظریے کے مطابق نہیں؛ زیادہ تر بڑے نظام عملی طور پر ملے جلے ہیں۔

سفارشات

SOLID کو چیک لسٹ کے بجائے عدسے کے طور پر استعمال کریں

ماڈیولز کو ہم آہنگ رکھنے کے لیے واحد ذمہ داری لاگو کریں، انحصار کے الٹاؤ کو وہاں جہاں حقیقی حد ہو انحصارات کو تجریدات کی طرف رکھنے کے لیے، اور کھلا-بند وہاں جہاں توسیع کے نکتے حقیقی ہوں۔ مخفف کو مطمئن کرنے کے لیے انٹرفیس، فیکٹریاں اور تہیں نہ گھڑیں جب صرف ایک نفاذ ہو اور دوسرا نظر میں نہ ہو۔ بالواسطگی کی لاگت ہے، اور آپ ہر پڑھت پر ادا کرتے ہیں۔

DRY کو متن پر نہیں، علم پر لاگو کریں

DRY ایک مستند علم کے ٹکڑے کو نہ دہرانے کے بارے میں ہے۔ یہ ان لائنوں کو ختم کرنے کے بارے میں نہیں جو محض ملتی جلتی لگتی ہیں۔ کوڈ کے دو ٹکڑے جو ملتے جلتے لگتے ہیں مگر مختلف وجوہات سے بدلتے ہیں انہیں الگ رہنا چاہیے۔ غیر متعلقہ چیزوں کو جوڑنے والی قبل از وقت مشترک تجرید پر تھوڑی تکرار کو ترجیح دیں۔ حقیقی نمونہ دو یا تین بار ظاہر ہونے کے بعد تجرید نکالیں۔

KISS اور YAGNI کو قیاس آرائی کا مقابلہ کرنے دیں

ان تقاضوں کے لیے بنائیں جو آپ کے پاس ہیں، ان کے لیے نہیں جن کا آپ تصور کرتے ہیں۔ قیاس آرائی پر مبنی عمومیت سے بچیں، جیسے ترتیب دینے کے قابل فریم ورکس، پلگ اِن نظام، اور توسیع کے نکتے جو کسی نے مانگے نہ ہوں۔ توازن یہ ہے کہ کچھ لچک واقعی جلد بنانا سستا ہے، جیسے مستحکم انٹرفیس یا صاف جوڑ۔ YAGNI قیاس آرائی پر مبنی نفاذ کے خلاف دلیل دیتا ہے، سوچی سمجھی حدود کے خلاف نہیں۔

کم جوڑ اور اعلیٰ ہم آہنگی کے لیے واضح طور پر ڈیزائن کریں

ہر ماڈیول سے ایک اچھی طرح متعین کام کروائیں (ہم آہنگی)، اور تنگ انٹرفیسز کے ذریعے جتنے کم ممکن ہو دوسرے ماڈیولز پر انحصار کریں (کم جوڑ)۔ جب ڈیزائن کا جائزہ لیں تو پوچھیں کہ کون سی تبدیلیاں ماڈیول کی حدوں کے پار لہریں بناتی ہیں۔ وہ لہریں جوڑ کا حقیقی پیمانہ ہیں۔ تشویشات کی علیحدگی وہی خیال ہے جو تہوں اور بین شعبہ جاتی تشویشات پر لاگو ہے۔

ڈیزائن کے نمونوں کو لغت کے طور پر اور ضد نمونوں کو انتباہ کے طور پر استعمال کریں

نمونے بار بار آنے والے حلوں کے مفید مشترک نام ہیں۔ ان تک تب پہنچیں جب مسئلہ واقعی ان سے ملتا ہو۔ نفیس نظر آنے کے لیے نمونے مسلط نہ کریں، کیونکہ نمونوں سے بھرا کوڈ اکثر حد سے زیادہ انجینئرنگ کی علامت ہے۔ عام ضد نمونے (گاڈ آبجیکٹس، جہاں نامناسب ہو وہاں خون کی کمی والے ماڈل، کیچڑ کی بڑی گیندیں، تقسیم شدہ یک سنگی) تشخیصی لیبل کے طور پر سیکھیں۔

جہاں شعبہ پیچیدہ ہو وہاں ڈومین پر مبنی ڈیزائن اپنائیں

بھرپور کاروباری قواعد والے نظاموں کے لیے DDD کے تکنیکی اور حکمت عملی کے آلات استعمال کریں: شعبے کے ماہرین کے ساتھ مشترک ہمہ گیر زبان، محدود سیاق جو نظام کو آزادانہ ماڈل شدہ ٹکڑوں میں کاٹتے ہیں، اور سیاق کے نقشے جو بتاتے ہیں کہ وہ ٹکڑے کیسے جڑے ہیں۔ محدود سیاق انٹرپرائز کے پیمانے پر خاص طور پر قیمتی ہیں، کیونکہ وہ ٹیم کی ملکیت کو ماڈل کی حدوں کے ساتھ ہم آہنگ کرتے ہیں۔ DDD سادہ CRUD (بنانا، پڑھنا، اپ ڈیٹ، حذف) نظاموں کے لیے ضرورت سے زیادہ ہے۔

نمونے موزونیت سے چنیں

حالت والے رویے کو غلاف دینے اور شعبوں کو ماڈل کرنے کے لیے اشیا پر مبنی انداز استعمال کریں۔ تبدیلیوں، ہم زمانیت، اور ناقابل تغیر ہونے کے ذریعے پیش گوئی کی اہلیت کے لیے فنکشنل اسلوب استعمال کریں۔ جہاں کارکردگی اور کیش کا رویہ غالب ہو وہاں ڈیٹا پر مبنی ڈیزائن استعمال کریں۔ بڑے نظام تینوں ملاتے ہیں۔ انتخاب فی جزو کریں، اور اسلوبوں کے درمیان حدود صاف رکھیں۔

سمجھوتے: فوائد اور نقصانات

اصول / طریقہ	اچھی طرح لاگو ہو تو	ناکامی کا انداز
SOLID	جہاں تبدیلی ہوتی ہے وہاں صاف جوڑ؛ قابل جانچ اکائیاں	انٹرفیسز اور تہوں کا پھیلاؤ؛ بلا صلہ بالواسطگی
DRY	حقیقی علم کے لیے سچائی کا واحد ماخذ	غلط تجرید جو غیر متعلقہ کوڈ کو جوڑتی ہے
KISS / YAGNI	دبلے، قابل فہم نظام	کم ڈیزائن شدہ جوڑ؛ ضروری لچک کی مہنگی بعد کی تعمیر
ڈیزائن کے نمونے	مشترک لغت؛ آزمودہ ساختیں	نمونوں کی اندھی نقل؛ اتفاقی پیچیدگی
ڈومین پر مبنی ڈیزائن	ہم آہنگ ماڈل اور ٹیمیں؛ قابو شدہ پیچیدگی	سادہ شعبوں پر بھاری رسم؛ غلط جگہ کی سیاق کی حدود
فنکشنل / ناقابل تغیر	پیش گوئی کی اہلیت؛ زیادہ محفوظ ہم زمانیت	فطری طور پر حالت والے مسائل کے لیے بے ڈھنگا؛ کارکردگی کے سرپرائز

بار بار آنے والا کھنچاؤ کم ڈیزائن اور زیادہ ڈیزائن کے درمیان ہے۔ کم ڈیزائن شدہ نظام جوڑ جمع کرتے ہیں اور سخت ہو جاتے ہیں۔ زیادہ ڈیزائن شدہ نظام تجرید میں ڈوب جاتے ہیں جسے کسی کو سمجھنا اور برقرار رکھنا پڑتا ہے۔ جواب مقررہ نکتہ نہیں۔ یہ نظم و ضبط ہے: فیصلے اس وقت تک مؤخر کریں جب تک کافی معلومات نہ ہو، جبکہ وہ جوڑ رکھیں جو آپ کو اپنا ارادہ بدلنے دیں۔

اپنی ٹیم کے ساتھ بحث کے سوالات

1. مشترک تجرید نکالنے کی آپ کی ٹھوس حد کیا ہے، اور آپ DRY کو غلط تجرید پیدا کرنے سے کیسے روکتے ہیں؟ یہ باب صاف کہتا ہے کہ تکرار غلط تجرید سے سستی ہے، اور یہ کہ نمونہ دو یا تین بار ظاہر ہونے تک نکالنے کا انتظار کریں۔ بڑی ٹیم میں خطرہ یہ ہے کہ کوئی دو ملتے جلتے ٹکڑوں کو ٹیموں کی حدوں کے پار مشترک ماڈیول میں فیکٹر کر دے، پھر ایک کال کرنے والے میں ہر آئندہ تبدیلی دوسرے میں لہر بناتی ہے۔ جو اشارہ لانا ہے وہ یہ ہے کہ کیا نقلیں ایک ہی وجہ سے بدلتی ہیں یا محض ابھی ملتی جلتی لگتی ہیں۔ تین کا اصول طے کریں، اور لازمی کریں کہ امیدوار تجرید نے کال کرنے والوں کو جوڑنے سے پہلے واقعی مل کر تبدیلی دکھائی ہو۔ وہ ایک اتفاق جوڑ کی ایسی قسم کو روکتا ہے جسے جب بہت سی ٹیمیں انحصار کرنے لگیں تو کھولنا مہنگا ہے۔

2. آپ جوڑ اور ہم آہنگی کو اندازے پر چھوڑنے کے بجائے ڈیزائن ریویو میں نظر آنے والا کیسے بناتے ہیں؟ بنیادی اصول جوڑ اور ہم آہنگی کو ہر مخفف سے اوپر رکھتے ہیں، اور جوڑ کی تعریف ماڈیول کی حدوں کے پار لہریں بنانے والی تبدیلیوں سے کرتے ہیں۔ وجدان سینکڑوں انجینئروں میں نہیں پھیلتا جو ہر ایک نظام کا اپنا کونا دیکھتا ہے۔ وہ شواہد لائیں جو مشین پیدا کر سکے: انحصار کے گراف، اور مشترک تبدیلی کا ڈیٹا جو دکھائے کہ کون سے ماڈیول ایک ہی کمٹس میں بار بار ایک ساتھ ترمیم ہو رہے ہیں۔ ریویو میں واضح سوال شامل کریں جو پوچھے کہ تبدیلی آپ کو کن ماڈیول کی حدوں کو پار کرنے پر مجبور کرتی ہے۔ جب دو ماڈیول ہمیشہ ایک ساتھ بدلتے ہوں تو یہ آپ کا اشارہ ہے کہ یا تو انہیں ضم کریں یا ان کے درمیان حد ٹھیک کریں۔

3. آپ کے نظاموں میں ڈومین پر مبنی ڈیزائن کا جواز دینے کے لیے کافی بھرپور شعبے اور سادہ CRUD ایپ جہاں یہ ضرورت سے زیادہ ہے، کے درمیان لکیر کہاں ہے؟ باب DDD کے محدود سیاق کی سفارش اس لیے کرتا ہے کہ وہ ٹیم کی ملکیت کو ماڈل کی حدوں کے ساتھ ہم آہنگ کرتے ہیں، اور خبردار کرتا ہے کہ DDD سادہ بنانے-پڑھنے-اپ ڈیٹ-حذف نظاموں کے لیے ضرورت سے زیادہ ہے اور حقیقی ماڈلنگ کے بغیر رسم میں بگڑ جاتا ہے۔ کسی بھی سمت میں غلط کرنا مہنگا ہے: پتلے شعبے پر بھاری DDD سادہ ایپ کو رسم میں دفن کر دیتا ہے، جبکہ بہت سی ٹیموں کا پھیلا ہوا مشترک ماڈل مسلسل بین ٹیم ہم آہنگی مجبور کرتا ہے۔ وہ اشارے لائیں جو واقعی فیصلہ کرتے ہیں: کاروباری قواعد کی کثافت، اور کتنی ٹیموں کو حصوں کا آزادانہ مالک بننا ہے۔ حکمت عملی کی مشینری پیچیدہ مرکز کے لیے رکھیں، اور سادہ کناروں کو سادہ رہنے دیں۔ یہ آپ کو DDD کے تماشے اور کیچڑ کی بڑی گیند دونوں سے دور رکھتا ہے۔

4. تجرید، انٹرفیس، یا ڈیزائن کا نمونہ اس بالواسطگی کے قابل کب ہے جو وہ جوڑتا ہے، اور ڈیزائن کو حد سے زیادہ انجینئر شدہ کہنے کا اختیار کس کو ہے؟ باب صاف ہے کہ بالواسطگی کی لاگت ہے جو آپ ہر پڑھت پر ادا کرتے ہیں، اور SOLID کو مطمئن کرنے یا نفیس نظر آنے کے لیے انٹرفیس، فیکٹریاں اور تہیں گھڑنا ناکامی کا انداز ہے۔ بڑی ٹیم میں دباؤ دوسری طرف چلتا ہے: ریویورز اضافی تجرید کو اس لیے گزار دیتے ہیں کہ وہ نظم و ضبط والی لگتی ہے، اور کوئی کم ساخت کے حق میں بحث کرنے والا شخص نہیں بننا چاہتا۔ متصادم غور حقیقی ہے، کیونکہ کچھ جوڑ واقعی اپنی جگہ کماتے ہیں اور انہیں بعد میں ہٹانا مہنگا ہے۔ بحث میں ٹھوس شواہد لائیں: انٹرفیس کے آج دراصل کتنے نفاذ ہیں، توسیع کا نکتہ کبھی کتنی بار لچکا، اور ایک کوڈ کے راستے کی پیروی کے لیے قاری کو کتنی فائلیں کھولنی پڑتی ہیں۔ اتفاق کریں کہ ایک نفاذ جس کا دوسرا نظر میں نہ ہو اسے inline کرنے کی ڈیفالٹ وجہ ہے، اور نام لیں کہ کون ڈیزائن کو حد سے زیادہ انجینئر شدہ کہہ سکتا ہے بغیر اسے توہین کی طرح پڑھے۔ اپنے مصنفین سے دہائی بھر جینے والے انٹرپرائز اور سرکاری نظاموں میں بے جا بالواسطگی وہ محصول ہے جو ہر آئندہ نگہبان ادا کرتا ہے، اس لیے “یہ تجرید ہمیں کیا دیتی ہے” کو مستقل ریویو سوال سمجھیں، ذاتی چیلنج نہیں۔

5. آپ کیسے طے کرتے ہیں کہ ہر جزو کون سا نمونہ استعمال کرے، اشیا پر مبنی، فنکشنل، یا ڈیٹا پر مبنی، اور ان کے درمیان حدود صاف کیسے رکھتے ہیں؟ باب دلیل دیتا ہے کہ بڑے نظام عملی طور پر ملے جلے ہیں اور آپ کو فی جزو موزونیت سے چننا چاہیے، حالت والے شعبوں کے لیے اشیا پر مبنی، تبدیلیوں اور ہم زمانیت کے لیے فنکشنل، اور جہاں کارکردگی اور کیش کا رویہ غالب ہو وہاں ڈیٹا پر مبنی ڈیزائن۔ بغیر انتظام کے نمونے کا انتخاب اس پر آ جاتا ہے کہ ماڈیول پہلے کس نے لکھا، اور قابل تغیر حالت خالص تبدیلیوں میں رس جاتی ہے، یا فنکشنل خالص پسندی فطری طور پر حالت والے مسئلے سے لڑتی ہے۔ جو شواہد لانے کے قابل ہیں وہ آپ کی اصل تکلیف کہاں ہے: کون سے اجزا چھپی ہوئی حالت کی وجہ سے ٹیسٹ کرنا مشکل ہیں، کون سے گرم راستے کیش سے بندھے ہیں، اور موجودہ اسلوب کہاں بے ڈھنگے متبادل پر مجبور کرتا ہے۔ ہر تہہ کا ڈیفالٹ نمونہ سوچ سمجھ کر طے کریں اور لکھیں کہ اسلوبوں کے درمیان جوڑ کہاں گرتے ہیں، تاکہ فنکشنل مرکز اور لازمی کنارہ ایک دوسرے میں نہ رسیں۔ ضابطے کے پابند یا سرکاری نظام کے لیے جہاں کسی مدت کا حساب قابل آڈٹ اور دوبارہ پیدا ہونے کے قابل ہونا چاہیے، ناقابل تغیر، فنکشنل مرکز اکثر پسند نہیں بلکہ تعمیل کا تقاضا ہے، اور اس پابندی کو حد کی پیروی کرنے کے بجائے اسے چلانا چاہیے۔

6. آپ ان اصولوں کو عقیدے میں سخت ہونے سے کیسے روکتے ہیں، اور ڈیزائن کے فیصلے کے پیچھے استدلال کہاں ریکارڈ کرتے ہیں تاکہ آئندہ ٹیم اس پر نظر ثانی کر سکے؟ اس باب کے ہر اصول کا اطلاق کا دائرہ اور ناکامی کا انداز ہے، اور پورا فریم انہیں فہم سے لاگو کرنے کے آلات سمجھتا ہے، نافذ کرنے کے قوانین نہیں۔ بڑی ٹیم میں اصول خاموشی سے قاعدہ بن جاتا ہے: DRY کسی بھی تکرار کو منع کرتا ہے، SOLID ہر کلاس کے لیے انٹرفیس لازمی کرتا ہے، اور عملی استثنا ریویو میں نتیجے کے بجائے مخفف کا حوالہ دینے والوں سے روکے جاتے ہیں۔ کھنچاؤ یہ ہے کہ کچھ یکسانیت واقعی سینکڑوں انجینئروں کو ہم آہنگ ہونے میں مدد دیتی ہے، اس لیے آپ ہر اصول کو محض اختیاری نہیں کہہ سکتے۔ ایسی مثالیں لائیں جہاں اصول کی لفظی پیروی نے بدتر ڈیزائن پیدا کیا، اور فیصلوں کے ریکارڈ لائیں، اگر ہوں، جو بتاتے ہیں کہ کوئی حد یا تجرید کیوں موجود ہے۔ اتفاق کریں کہ اصول ڈیفالٹس ہیں جن سے انجینئر ریکارڈ شدہ وجہ کے ساتھ ہٹ سکتا ہے، اور نتیجہ خیز ڈیزائن کے انتخابات مختصر فن تعمیر کے فیصلے کے ریکارڈ میں گرفت کریں تاکہ اگلی ٹیم صرف کوڈ نہیں بلکہ استدلال وراثت میں پائے۔ انٹرپرائز اور سرکاری نظاموں میں جہاں اصل مصنفین بہت پہلے جا چکے ہوں اور آڈٹ پوچھتے ہیں کہ نظام اس شکل کا کیوں ہے، وہ تحریری سلسلہ اس ڈیزائن میں جسے آئندہ ٹیمیں محفوظ طریقے سے بدل سکیں اور جسے چھونے سے وہ ڈریں، فرق ہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ سادہ ترین ڈیزائن کو ترجیح دیں جو ریلیز ہو اور حقیقی دوسرے استعمال کے معاملے کے جوڑ مجبور کرنے تک ایک اچھی طرح فیکٹر شدہ ماڈیول رکھیں۔ آپ کا سب سے کم یاب وسیلہ انجینئرنگ کی توجہ ہے، اس لیے قبل از وقت انٹرفیس، تہیں اور قیاس آرائی کے فریم ورکس خالص لاگت ہیں۔ کوئی مشترک تجرید نکالنے سے پہلے تین کا اصول مانیں، اور YAGNI کو وہ توسیع کے نکتے مارنے دیں جو کسی نے ابھی مانگے نہیں۔

چھوٹا کاروبار۔ کوئی مخصوص آرکیٹیکٹ نہ ہو اور بجٹ تنگ ہو تو اپنے نمونے ایجاد کرنے کے بجائے اس ڈیزائن پر انحصار کریں جو فریم ورکس اور لائبریریوں میں پہلے سے بنا ہے جو آپ خریدتے ہیں۔ مخصوص ڈیزائن کی کوشش ان چند قواعد کے لیے رکھیں جو واقعی آپ کا کاروبار ہیں، اور باقی سب کو روایتی رکھیں تاکہ ٹھیکیدار یا نیا بھرتی پڑھ سکے۔ تھوڑی تکرار جسے آپ سمجھتے ہیں چالاک تجرید سے بہتر ہے جسے صرف اس کا مصنف برقرار رکھ سکتا ہو۔

بڑا ادارہ۔ مشترک اصولوں کا صلہ بہت سی ٹیموں میں ہم آہنگی ہے: ڈیزائن ریویو کے لیے مشترک لغت، اور محدود سیاق جو ماڈل کی حدوں کو ٹیم کی ملکیت کے ساتھ ملاتے ہیں تاکہ گروہ آزادانہ ارتقا کریں۔ انحصار اور مشترک تبدیلی کے ڈیٹا سے جوڑ اور ہم آہنگی کو واضح طور پر سنبھالیں، اور نتیجہ خیز ڈیزائن کے فیصلے ریکارڈ کریں تاکہ نظام اپنے مصنفین کے چلے جانے کے بہت بعد بھی قابل تبدیل رہیں۔ غلط تجرید سے جو ٹیموں کو جوڑتی ہے اور حد سے زیادہ انجینئرنگ سے جو ہر قاری پر محصول لگاتی ہے، برابر خبردار رہیں۔

حکومت۔ آڈٹ کی اہلیت اور دوبارہ پیدا ہونے کی اہلیت اکثر ڈیزائن طے کرتی ہیں۔ ناقابل تغیر، فنکشنل مرکز آپ کو کسی مدت کے لیے تاریخی حساب بالکل ٹھیک دوبارہ پیدا کرنے دیتا ہے، جس کی ضمانت چھپی قابل تغیر حالت والا الجھا ہوا آبجیکٹ گراف نہیں دے سکتا۔ سیاق کی حدود پر مشترک جدولوں کے بجائے واضح شائع شدہ معاہدوں کو ترجیح دیں، اور ڈیزائن اور اس کے فیصلوں کے ریکارڈ کو آڈیٹرز اور اس ٹیم کے لیے قابل مطالعہ رکھیں جو دہائی بعد نظام وراثت میں پائے۔

مثالیں

اسٹارٹ اپ۔ تین انجینئروں کا اسٹارٹ اپ جو اپنی پہلی پروڈکٹ بنا رہا ہے ہر فیچر کو انٹرفیسز اور فیکٹریوں کی تہوں میں بانٹنے کی خواہش کا مقابلہ کرتا ہے، اور حقیقی دوسرے استعمال کے معاملے کے ظاہر ہونے تک ایک اچھی طرح فیکٹر شدہ ماڈیول رکھتا ہے۔ جب وہی منطق سائن اپ اور بلنگ کے بہاؤ میں تیسری بار ظاہر ہوتی ہے تو وہ قیاس آرائی کے فریم ورک کے بجائے ایک چھوٹا مشترک فنکشن نکالتے ہیں۔ یہ کوڈ بیس کو اتنا چھوٹا رکھتا ہے کہ ان میں سے کوئی بھی اسے ذہن میں رکھ سکے، اور جو چند جوڑ وہ کھینچتے ہیں وہاں گرتے ہیں جہاں پروڈکٹ کے بدلنے کا سب سے زیادہ امکان ہے۔

بڑا ادارہ۔ ایک بڑا بیمہ پلیٹ فارم پالیسی، دعووں اور بلنگ کو الگ محدود سیاق کے طور پر ماڈل کرتا ہے، ہر ایک کی مالک مخصوص ٹیم ہے جس کا اپنا ڈیٹا ماڈل اور سروس کی حد ہے۔ جہاں سیاق ملتے ہیں، جیسے دعویٰ پالیسی کا حوالہ دیتا ہے، وہ مشترک ڈیٹا بیس جدولوں کے بجائے واضح شائع شدہ معاہدوں کے ذریعے بات کرتے ہیں۔ یہ تینوں ٹیموں کو آزادانہ ارتقا کرنے دیتا ہے، اور ہمہ گیر زبان انڈر رائٹرز اور ایکچوریز کے ساتھ گفتگو کو درست رکھتی ہے۔ ایک پرانا ورژن ایک پھیلا ہوا ماڈل بانٹتا تھا، اور ہر تبدیلی بین ٹیم ہم آہنگی مانگتی تھی۔

حکومت۔ ایک قومی ٹیکس پراسیسنگ نظام اپنے حساب کے انجن کے لیے جان بوجھ کر ڈیٹا پر مبنی، فنکشنل مرکز کو ترجیح دیتا ہے۔ ٹیکس کے قواعد ناقابل تغیر ان پٹ ریکارڈز پر خالص تبدیلیوں کے طور پر ظاہر کیے جاتے ہیں، جو انہیں کسی ٹیکس سال کے لیے قابل آڈٹ، قابل جانچ اور دوبارہ پیدا ہونے کے قابل بناتا ہے۔ لازمی، حالت والے حصے (ورک فلو، اطلاعات) کناروں پر رکھے جاتے ہیں۔ آڈیٹرز قاعدے کے مخصوص ورژن کی طرف اشارہ کر سکتے ہیں اور کوئی بھی تاریخی حساب بالکل ٹھیک دوبارہ پیدا کر سکتے ہیں، جو ایسا قانونی تقاضا ہے جس کی ضمانت چھپی قابل تغیر حالت والا الجھا ہوا آبجیکٹ گراف نہیں دے سکتا۔

کاروباری جواز: محرکات، ROI اور TCO

ڈیزائن کا معیار نظام کی تبدیلی کی اہلیت میں سرمایہ کاری ہے، اور تبدیلی کی اہلیت ملکیت کی کل لاگت پر حاوی ہے۔ نظام کی زیادہ تر لاگت پہلی ریلیز کے بعد ترمیم اور توسیع میں آتی ہے۔ اچھی طرح ڈیزائن شدہ نظام تبدیلی کی لاگت کو وقت کے ساتھ تقریباً سیدھا رکھتے ہیں۔ بری طرح ڈیزائن شدہ نظاموں میں ہر تبدیلی کی لاگت اس وقت تک چڑھتی ہے جب تک نظام عملاً ناقابل ترمیم ہو کر دوبارہ لکھنا نہ پڑے، جو سب سے مہنگا نتیجہ ہے۔

اپنانے کی لاگت بنیادی طور پر مہارت اور ریویو کا نظم و ضبط ہے: اصول سکھانا، اور آگے ڈیزائن کا وقت لگانا۔ انہیں نہ اپنانے کی لاگت تکنیکی قرض کا سست جمع ہونا، گرتی ہوئی ترسیلی رفتار، بڑھتے نقائص کی شرح، اور بالآخر مہنگی دوبارہ تحریر ہے۔ قیادت کے سامنے دلیل رکھنے کے لیے ڈیزائن کے نظم و ضبط کو ترسیل کی پیش گوئی کی اہلیت اور دوبارہ تحریر کے پروگراموں سے بچنے سے جوڑیں، اور پیشگی اشارے ٹریک کریں جیسے تبدیلی کی ناکامی کی شرح اور وقت کے ساتھ ملتے جلتے فیچرز کے نفاذ میں لگا وقت۔ الٹی ناکامی پر بھی نظر رکھیں: غیر یقینی مستقبل کے لیے ڈیزائن میں حد سے زیادہ سرمایہ کاری بھی قدر تباہ کرتی ہے۔ اس لیے دلیل مناسب ڈیزائن کی ہے، جو اس سے ماپی جائے کہ آئندہ تبدیلی کتنی ممکن اور کتنی مہنگی ہے۔

ضد نمونے اور خامیاں

• قیاس آرائی پر مبنی عمومیت: تصوراتی تقاضوں کے لیے توسیع پذیری بنانا جو کبھی نہیں آتے۔
• غلط تجرید: DRY کو مطمئن کرنے کے لیے غیر متعلقہ کوڈ کو زبردستی جوڑنا، ایسا جوڑ جو تکرار سے بدتر ہے۔
• نمونوں کی اندھی نقل: ڈیزائن کے نمونوں کو ان کی خاطر لاگو کرنا، بغیر فائدے کے بالواسطگی جوڑنا۔
• خون کی کمی والے یا گاڈ آبجیکٹس: بغیر رویے کے ماڈل، یا ہر کام کرنے والے آبجیکٹس؛ دونوں غلط جگہ کی ذمہ داریوں کا اشارہ ہیں۔
• تقسیم شدہ یک سنگی: جسمانی طور پر بٹی ہوئی سروسز جو اب بھی سختی سے جڑی ہیں، دونوں طریقوں کی لاگتیں ملاتی ہوئی۔
• کیچڑ کی بڑی گیند: کوئی نظر آنے والی ساخت نہیں؛ ہر تبدیلی ہر چیز کو خطرے میں ڈالتی ہے۔
• DDD کا تماشا: ڈومین ماڈلنگ کے بغیر لغت اور فولڈر کی ساخت اپنانا جو اسے قدر دیتی ہے۔

پختگی کا ماڈل

• سطح 1، آغاز: ڈیزائن فی البدیہہ اور ردعملی ہے؛ جوڑ بلا روک ٹوک جمع ہوتا ہے؛ اصول نامعلوم ہیں یا نعروں کے طور پر پکارے جاتے ہیں، اور تجریدیں انفرادی عادت سے ظاہر یا غائب ہوتی ہیں۔
• سطح 2، ترقی: ٹیمیں اصول جانتی ہیں اور لاگو کرتی ہیں، مگر غیر مستقل اور اکثر عقیدے کی طرح؛ کچھ گروہ جوڑ اور ہم آہنگی کو سوچ سمجھ کر سنبھالتے ہیں جبکہ دوسرے نہیں، اور پورے ادارے میں مشترک لغت نہیں۔
• سطح 3، معیار بندی: مشترک ڈیزائن کی لغت، تجرید نکالنے کے لیے تین کا اصول، جوڑ اور ہم آہنگی کا تجزیہ، اور ٹیموں سے ہم آہنگ محدود سیاق دستاویزی اور پورے ادارے میں متوقع ہیں، انفرادی پسند پر چھوڑنے کے بجائے ڈیزائن ریویو میں مستقل لاگو۔
• سطح 4، انتظام: ڈیزائن کی صحت بنیادی خطوط کے مقابل ناپی جاتی ہے: جوڑ اور مشترک تبدیلی کا ڈیٹا، تبدیلی کی ناکامی کی شرح، اور ملتے جلتے فیچرز کے نفاذ کا وقت وقت کے ساتھ ٹریک ہوتے ہیں، تاکہ تجریدیں اور حدود شواہد پر شامل، برقرار یا ہٹائی جائیں، اور حد سے زیادہ انجینئرنگ اور غلط تجرید رائے کے بجائے ڈیٹا سے پکڑی جائیں۔
• سطح 5، ہم آہنگی: ڈیزائن کا نظم و ضبط ادارے بھر میں ترسیل اور خطرے کی منصوبہ بندی سے مربوط ہے؛ اصول باریکی اور معلوم ناکامی کے انداز کے ساتھ لاگو ہوتے ہیں؛ نمونے اور حد کے انتخابات سوچے سمجھے اور مسلسل نظر ثانی شدہ ہیں، اور ادارہ شعبہ اور شواہد بدلنے کے ساتھ معمول کے مطابق تجریدیں دوبارہ فیکٹر، دوبارہ دائرہ بند، اور ریٹائر کرتا ہے۔

بحث کے لیے خیالات

• آپ آئندہ تقاضا جاننے سے پہلے ضروری جوڑ اور قیاس آرائی پر مبنی عمومیت میں فرق کیسے کرتے ہیں؟
• DRY نے آپ کی ٹیم کو کب غلط تجرید کی طرف لے جایا، اور آپ نے اسے کیسے پہچانا؟
• محدود سیاق کی حدود کہاں گرنی چاہئیں، اور انہیں تنظیمی چارٹ کی کتنی نقل کرنی چاہیے؟
• آپ کے سیاق میں کوڈ سے پہلے کتنا ڈیزائن ہونا چاہیے، اور آپ فیصلے کیسے ریکارڈ کرتے ہیں؟
• آپ کے نظام کے کون سے حصے زیادہ فنکشنل یا ڈیٹا پر مبنی اسلوب سے فائدہ اٹھائیں گے؟
• آپ ڈیزائن کے اصولوں کو عقیدے میں سخت ہونے سے کیسے روکتے ہیں جو عملی استثنا کی مزاحمت کرتا ہے؟

اہم نکات

• جوڑ اور ہم آہنگی وہ خصوصیات ہیں جو اہم ہیں؛ مخففات ان مقاصد کے ذرائع ہیں۔
• ہر اصول کی ناکامی کا انداز ہے؛ جانیں کہ ہر ایک کب گمراہ کرتا ہے۔
• قبل از وقت یا غلط تجرید پر تھوڑی تکرار کو ترجیح دیں۔
• پیچیدہ شعبوں کو ٹیم کی ملکیت سے ہم آہنگ کرنے کے لیے DDD اور محدود سیاق استعمال کریں۔
• نمونے موزونیت سے چنیں؛ بڑے نظام عملی طور پر ملے جلے ہیں۔
• ان تبدیلیوں کے لیے ڈیزائن کریں جو آپ کو واقعی چاہییں، کم اور زیادہ ڈیزائن دونوں سے بچتے ہوئے۔

حوالہ جات اور مزید مطالعہ

• Robert C. Martin, Clean Architecture and Agile Software Development, Principles, Patterns, and Practices
• Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
• Vaughn Vernon, Implementing Domain-Driven Design
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software
• Martin Fowler, Refactoring: Improving the Design of Existing Code and Patterns of Enterprise Application Architecture
• David L. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules
• Sandi Metz, Practical Object-Oriented Design