سوفٹ ویر پروگرامنگ میں کچھ تجربہ رکھنے والا کوئی بھی سافٹ ویئر کوڈ دوسروں کے لکھا ہوا ، اپنے کیریئر کے راستے پر مبنی فیصلے کے پیرامیٹرز استعمال کرتا ہے۔
اپنے پیشہ ورانہ کیریئر کے دوران ، میں نے بہت سارے ڈویلپرز کو جانا ہے ، اور میں نے ہزاروں کوڈ لائنز دیکھے ہیں اور جب مجھے کسی ڈویلپر کی مہارت کا اندازہ لگانے کی ضرورت ہوتی ہے تو میں بنیادی طور پر دو عوامل پر غور کرتا ہوں:
خوش قسمتی سے ، کچھ بنیادی اصول یا اصول ہیں جن کو کوڈنگ میں بہتر بنانا آسان بنا دیتا ہے۔
مخفف SOLID کا مطلب ہے:
S: واحد ذمہ داری کا اصول
O: کھلا اصول
L: لیسکوف متبادل اصول
I: انٹرفیس الگ کرنے کا اصول
D: انحصار کو الٹ دینے کا اصول
آئیے پہلے سولیڈ اصول یعنی ایک کے بارے میں ڈیل کرتے ہوئے شروع کرتے ہیں
کسی کلاس (یا ماڈیول) کے ارتقاء کے لئے تبدیل کرنے کی صرف ایک ہی وجہ ہونی چاہئے۔
تصور خود ہی بہت آسان ہے ، لیکن اس سادگی کے حصول کے لئے عمل درآمد کا راستہ بہت پیچیدہ ہوسکتا ہے۔ کسی کلاس کو تبدیل کرنے کی ایک ہی وجہ ہونی چاہئے۔
لیکن کیوں؟
تبدیل کرنے کی صرف ایک وجہ ہونا کیوں اتنا ضروری ہے؟
مثال کے طور پر ، اگر تبدیل کرنے کی دو مختلف وجوہات ہیں تو ، یہ قابل فہم ہے کہ دو مختلف ٹیمیں دو مختلف وجوہات کی بنا پر ایک ہی کوڈ پر کام کرسکتی ہیں۔ ہر ایک کو اپنا حل خود نافذ کرنا ہوگا ، جو کسی مرتب شدہ زبان (جیسے C ++ ، C # یا جاوا) کی صورت میں ، ان ماڈیولز کا باعث بن سکتا ہے جو دیگر ٹیموں یا درخواست کے دیگر حصوں سے مطابقت نہیں رکھتے ہیں۔
ایک اور مثال ، اگر آپ ترجمانی شدہ زبان استعمال کررہے ہیں تو ، آپ کو مختلف وجوہات کی بناء پر ایک ہی طبقے یا ماڈیول کی جانچ کرنا پڑسکتی ہے۔ اس کا مطلب ہے کہ کوالٹی کنٹرول کے ل more مزید کام ، وقت اور کوشش کا۔
کلاس یا ماڈیول میں ہونی والی ایک خصوصیت کی نشاندہی کرنا ٹیسٹوں کو چلانے کے ل run بس ایک چیک لسٹ میں دیکھنے سے کہیں زیادہ پیچیدہ ہے۔
لیکن آئیے کم تکنیکی نقطہ نظر سے سوچنے کی کوشش کریں ، یعنی ہم اپنے طبقے یا ماڈیول کے صارف کا تجزیہ کرنے کی کوشش کریں ، وہی اسے استعمال کرے گا۔ ایک بنیادی پہلو جس کو ہمیں ہمیشہ دھیان میں رکھنا چاہئے ، یہ حقیقت ہے کہ جو ایپلی کیشن یا سسٹم ہم تیار کرتے ہیں ان کے استعمال کرنے والے کسی خاص ماڈیول کے ذریعہ خدمات انجام دیتے ہیں وہی اس میں ترمیم کی درخواست کریں گے۔ خدمت کرنے والے کلاس یا ماڈیول کو تبدیل کرنے کے لئے کہیں گے۔
ماڈیولز اور ان کے استعمال کی کچھ مثالیں:
لہذا اگر پہلا قدم ماڈیول کے ساتھ باہمی گفتگو کرنے والے اداکاروں یا اداکار کی تلاش کرنا ہے تو ، افراد کو تمام کرداروں سے جوڑنا مشکل ہوسکتا ہے۔ ایک چھوٹی کمپنی میں ، ایک شخص متعدد کردار ادا کرسکتا ہے جبکہ ایک بڑی کمپنی میں بہت سے لوگ ہوسکتے ہیں جن کا ایک ہی کردار ہوتا ہے۔
لوگوں یا صارفین کی بجائے کردار کی شناخت کرنا زیادہ معقول معلوم ہوتا ہے۔
لہذا:
آئیے کچھ مثالوں کو دیکھیں
فرض کریں کہ ہمارے پاس ایک کتابی کلاس موجود ہے جو کتاب کے تصور اور اس کی فعالیت کو سمیٹتی ہے۔
کلاس کتاب {
فنکشن getTitle () {
"ایک زبردست کتاب" واپس کرو۔
}
فنکشن getAuthor () {
"الیسیینڈرو بیریکو" واپس؛
}
فنکشن اگلا صفحہ () {
// اگلا صفحہ
}
فنکشن پرنٹکرنٹ پیج () {
گونج "موجودہ صفحے کا مواد"؛
}
}
یہ بہت عام کلاس ہے۔ ہمارے پاس ایک کتاب ہے ، اور کلاس ہمیں عنوان دے سکتی ہے ، وہ ہمیں مصنف دے سکتے ہیں ، اور وہ آگے بڑھ سکتے ہیں۔ آخر میں ، یہ سکرین پر موجودہ صفحے پرنٹ کرنے کی بھی صلاحیت رکھتا ہے۔
تاہم ، ایک چھوٹا سا مسئلہ ہے۔
کتاب اعتراض کے انتظام میں شامل اداکاروں کے بارے میں سوچنا ، وہ کون ہوسکتے ہیں؟
ہم یہاں دو مختلف اداکاروں کے بارے میں آسانی سے سوچ سکتے ہیں۔ کتاب کا انتظام (کے طور پر لائبریریناور ڈیٹا جمع کرنے کا طریقہ کار (جیسے ہم صارف تک مواد کو کس طرح پہنچانا چاہتے ہیں: آن اسکرین ، گرافیکل یوزر انٹرفیس ، صرف متن کا صارف انٹرفیس ، شاید پرنٹ کریں)۔
لہذا ہمارے پاس دو بہت مختلف اداکار ہیں جو کلاس کے ساتھ بات چیت کرتے ہیں۔
مختصر طور پر یہ کلاس اس کے مابین ملاوٹ کرتی ہے۔
یہ مسئلہ ہوسکتا ہے کیونکہ یہ واحد ذمہ داری کے اصول (ایس آر پی) کی خلاف ورزی کرتا ہے۔
ہم کس طرح تبدیل ہو سکتے ہیں ، واحد ذمہ داری کے اصول کا احترام کرنے کے لئے ہم اس ضابطہ کو کیسے بہتر بنا سکتے ہیں؟
درج ذیل کوڈ پر ایک نظر ڈالیں:
کلاس کتاب {
فنکشن getTitle () {
"اوشانو میری" واپس؛
}
فنکشن getAuthor () {
"الیسیینڈرو بیریکو" واپس؛
}
فنکشن ٹرن پیج () {
// اگلا صفحہ
}
فنکشن getCurrentPage () {
گونج "موجودہ صفحے کا مواد"؛
}
}
انٹرفیس پرنٹر {
فنکشن پرنٹ پیج ($ صفحہ)؛
}
کلاس اسٹیمپلیبرو پرنٹر imple
فنکشن پرنٹ پیجز ($ صفحہ)
گونج $ صفحہ؛
}
}
کلاس HtmlPrinter پرنٹر لاگو {
فنکشن پرنٹ پیجز ($ صفحہ)
گونج ' '. . صفحہ ' '؛
}
}
یہ بہت ہی عمدہ مثال سے پتہ چلتا ہے کہ کس طرح کاروباری منطق سے پریزنٹیشن کو الگ کرنا ہے ، اور ایس آر پی کی تعمیل میں یہ ہمارے منصوبے کی لچک میں بہت زیادہ فوائد پیش کرتا ہے۔
آئیے ایک اور مثال دیکھیں:
مندرجہ بالا جیسی مثال ملتی ہے جب کوئی شے اپنے آپ کو پریزنٹیشن سے محفوظ اور بازیافت کرسکتی ہے۔
کلاس کتاب {
فنکشن getTitle () {
"اوشانو میری" واپس؛
}
فنکشن getAuthor () {
"الیسیینڈرو بیریکو" واپس؛
}
فنکشن ٹرن پیج () {
// اگلا صفحہ
}
فنکشن getCurrentPage () {
"موجودہ صفحے کا مواد" واپس کریں؛
}
تقریب کو بچانے کے () {
$ فائل کا نام = '/ دستاویزات /'۔ $ this-> getTitolo ()۔ '-'۔ $ this-> getAuthor ()؛
file_put_contents ($ فائل کا نام ، سیریلائز ($ یہ))؛
}
}
پہلے کی طرح ، یہاں بھی ہم مختلف اداکاروں کی شناخت کرسکتے ہیں جیسے کتاب کا انتظام (کے طور پر لائبریریناور استقامت. جب بھی ہم صفحے سے دوسرے صفحے پر جانے کے راستے کو تبدیل کرنا چاہتے ہیں ، ہمیں اس کلاس کو تبدیل کرنے کی ضرورت ہے۔ ہمارے پاس تبدیلی کی کئی وجوہات ہوسکتی ہیں۔
کلاس کتاب {
فنکشن getTitle () {
"اوشانو میری" واپس؛
}
فنکشن getAuthor () {
"الیسیینڈرو بیریکو" واپس؛
}
فنکشن ٹرن پیج () {
// اگلا صفحہ
}
فنکشن getCurrentPage () {
"موجودہ صفحے کا مواد" واپس کریں؛
}
}
کلاس سادہ فلپیرسٹسٹ {
فنکشن سیونگ (کتاب $ کتاب)
name فائل کا نام = '/ دستاویزات /'۔ $ book-> getTitle ()۔ '-'۔ $ book-> getAuthor ()؛
فائل_پٹ_کونٹس ($ فائل نام ، سیریلائز ($ کتاب))؛
}
}
ثابت قدمی کے عمل کو کسی دوسرے طبقے میں منتقل کرنا ذمہ داریوں کو واضح طور پر الگ کردے گا اور ہم اپنے کتابوں کی کلاس کو متاثر کیے بغیر استقامت کے طریقوں کا تبادلہ کرنے میں آزاد ہوں گے۔ مثال کے طور پر ، ڈیٹا بیس پرسٹسٹ کلاس کو نافذ کرنا معمولی بات ہوگی ، اور کتابی کاروائیوں کے ارد گرد تعمیر کردہ ہمارے کاروبار کی منطق تبدیل نہیں ہوگی۔
دوسرا اصول اوپن / بند -> پڑھ کر جاری رکھیں
Ercole Palmeri
سمارٹ لاک مارکیٹ کی اصطلاح پیداوار، تقسیم اور استعمال کے ارد گرد کی صنعت اور ماحولیاتی نظام سے مراد ہے…
سافٹ ویئر انجینئرنگ میں، ڈیزائن پیٹرن ان مسائل کا بہترین حل ہیں جو عام طور پر سافٹ ویئر ڈیزائن میں پائے جاتے ہیں۔ میں جیسا ہوں…
صنعتی مارکنگ ایک وسیع اصطلاح ہے جس میں کئی تکنیکوں کو شامل کیا جاتا ہے جو کسی کی سطح پر مستقل نشانات بنانے کے لیے استعمال ہوتی ہیں…
درج ذیل سادہ ایکسل میکرو مثالیں VBA کا تخمینہ پڑھنے کے وقت کا استعمال کرتے ہوئے لکھی گئیں: 3 منٹ مثال…