میں اکثر ایسے ڈویلپرز سے ملتا ہوں جنہوں نے SOLID کے اصولوں کے بارے میں نہیں سنا ہے (ہم . - ترجمہ) یا آبجیکٹ اورینٹڈ پروگرامنگ (OOP)، یا سنا، لیکن عملی طور پر ان کا استعمال نہ کریں۔ یہ مضمون OOP اصولوں کے فوائد کو بیان کرتا ہے جو ڈویلپر کو اس کے روزمرہ کے کام میں مدد کرتے ہیں۔ ان میں سے کچھ اچھی طرح سے جانا جاتا ہے، دوسروں کو اتنا نہیں، لہذا مضمون ابتدائی اور پہلے سے ہی تجربہ کار پروگرامرز دونوں کے لئے مفید ہو گا.
ہم آپ کو یاد دلاتے ہیں: "Habr" کے تمام قارئین کے لیے - "Habr" پروموشنل کوڈ کا استعمال کرتے ہوئے کسی بھی Skillbox کورس میں داخلہ لینے پر 10 rubles کی رعایت۔
Skillbox تجویز کرتا ہے: تعلیمی آن لائن کورس .
خشک (خود کو نہ دہرائیں)
ایک کافی آسان اصول، جس کا نچوڑ نام سے واضح ہے: "اپنے آپ کو نہ دہرائیں۔" ایک پروگرامر کے لیے، اس کا مطلب ہے ڈپلیکیٹ کوڈ سے بچنے کی ضرورت کے ساتھ ساتھ کام میں تجرید کو استعمال کرنے کی صلاحیت۔
اگر کوڈ میں دہرائے جانے والے دو حصے ہیں، تو انہیں ایک طریقہ میں جوڑ دیا جانا چاہیے۔ اگر ایک ہارڈ کوڈ شدہ قدر ایک سے زیادہ بار استعمال کی جاتی ہے، تو یہ اسے عوامی مستقل میں تبدیل کرنے کے قابل ہے۔
کوڈ کو آسان بنانے اور اسے برقرار رکھنے میں آسانی پیدا کرنے کے لیے یہ ضروری ہے، جو OOP کا بنیادی کام ہے۔ آپ کو یونین کا بھی غلط استعمال نہیں کرنا چاہیے، کیونکہ ایک ہی کوڈ OrderId اور SSN دونوں سے چیک پاس نہیں کرے گا۔
Encapsulation کو تبدیل کریں۔
زیادہ تر کمپنیوں کے سافٹ ویئر پروڈکٹس مسلسل تیار ہو رہے ہیں۔ اس کا مطلب ہے کہ کوڈ کو تبدیل کرنے کی ضرورت ہے، اسے برقرار رکھنے کی ضرورت ہے۔ آپ encapsulation کے ساتھ اپنی زندگی کو آسان بنا سکتے ہیں۔ یہ آپ کو اپنے موجودہ کوڈ بیس کو زیادہ مؤثر طریقے سے جانچنے اور برقرار رکھنے کی اجازت دے گا۔ .
اگر آپ جاوا میں لکھ رہے ہیں تو .
کشادگی / قربت کا اصول
اس اصول کو درج ذیل بیان کو پڑھ کر آسانی سے یاد کیا جا سکتا ہے: "سافٹ ویئر کے اداروں (کلاسز، ماڈیولز، فنکشنز، وغیرہ) کو توسیع کے لیے کھلا ہونا چاہیے، لیکن ترمیم کے لیے بند ہونا چاہیے۔" عملی طور پر، اس کا مطلب یہ ہے کہ وہ سورس کوڈ کو تبدیل کیے بغیر اپنے رویے کو تبدیل کرنے کی اجازت دے سکتے ہیں۔
اصول اہم ہے جب سورس کوڈ میں تبدیلی کے لیے نظر ثانی، یونٹ ٹیسٹنگ، اور دیگر طریقہ کار کی ضرورت ہوتی ہے۔ کھلے/بند اصول کی پابندی کرنے والے کوڈ کو توسیع دینے پر تبدیل نہیں ہوتا، اس لیے اس کے ساتھ بہت کم مسائل ہیں۔
یہاں کوڈ کی ایک مثال ہے جو اس اصول کی خلاف ورزی کرتی ہے۔
اگر آپ کو اس میں کچھ تبدیل کرنے کی ضرورت ہے، تو اس میں کافی وقت لگے گا، کیونکہ آپ کو کوڈ کے وہ تمام حصے تبدیل کرنے ہوں گے جن کا مطلوبہ ٹکڑے سے تعلق ہے۔
ویسے، کھلا پن-بندی SOLID کے اصولوں میں سے ایک ہے۔
واحد ذمہ داری کا اصول (SRP)
SOLID سیٹ سے ایک اور اصول۔ اس کا کہنا ہے کہ "صرف ایک وجہ ہے جو طبقاتی تبدیلی کا باعث بنتی ہے۔" کلاس کا صرف ایک کام ہے۔ اس کے کئی طریقے ہو سکتے ہیں، لیکن ان میں سے ہر ایک عام مسئلہ کو حل کرنے کے لیے استعمال ہوتا ہے۔ تمام طریقوں اور خصوصیات کو صرف اس کی خدمت کرنی چاہئے۔
اس اصول کی اہمیت یہ ہے کہ یہ سافٹ ویئر کے ایک ٹکڑے اور کوڈ کے درمیان تعلق کو ڈھیلا کر دیتا ہے۔ ایک کلاس میں ایک سے زیادہ فنکشنلٹیز کو شامل کرنا دو فنکشنز کے درمیان تعلق کو متعارف کراتا ہے۔ اس طرح، اگر آپ ان میں سے ایک کو تبدیل کرتے ہیں، تو پہلے سے متعلق دوسرے کو خراب کرنے کا ایک بہت بڑا موقع ہے۔ اور اس کا مطلب ہے کہ تمام مسائل کی پیشگی شناخت کرنے کے لیے جانچ کے چکر میں اضافہ کرنا۔
انحصار الٹا اصول (DIP)
مندرجہ بالا ایک کوڈ کی مثال ہے جہاں AppManager کا انحصار EventLogWriter پر ہوتا ہے، جو بدلے میں AppManager سے قریبی تعلق رکھتا ہے۔ اگر آپ کو اطلاع دکھانے کے لیے کسی دوسرے طریقے کی ضرورت ہے، چاہے وہ پش، SMS، یا ای میل ہو، آپ کو AppManager کلاس کو تبدیل کرنے کی ضرورت ہے۔
ڈی آئی پی سے مسئلہ حل کیا جا سکتا ہے۔ لہذا، AppManager کے بجائے، ہم ایک EventLogWriter کی درخواست کرتے ہیں، جسے فریم ورک کا استعمال کرتے ہوئے انجیکشن لگایا جائے گا۔
DIP انحصار ماڈیول کو تبدیل کرکے انفرادی ماڈیولز کو دوسروں کے ساتھ آسانی سے تبدیل کرنا ممکن بناتا ہے۔ یہ دوسرے کو متاثر کیے بغیر ایک ماڈیول کو تبدیل کرنا ممکن بناتا ہے۔
وراثت کے بجائے ترکیب
کوڈ کو دوبارہ استعمال کرنے کے دو اہم طریقے وراثت اور ساخت ہیں، ہر ایک کے اپنے فوائد اور نقصانات ہیں۔ دوسرا عام طور پر ترجیح دی جاتی ہے کیونکہ یہ زیادہ لچکدار ہے۔
کمپوزیشن آپ کو رن ٹائم کلاس کے رویے کو اس کی خصوصیات کو ترتیب دے کر تبدیل کرنے کی صلاحیت فراہم کرتی ہے۔ انٹرفیس کو لاگو کرتے وقت، پولیمورفزم استعمال کیا جاتا ہے، جو زیادہ لچکدار نفاذ فراہم کرتا ہے۔
یہاں تک کہ "مؤثر جاوا" جوشوا بلوچ وراثت سے زیادہ ساخت کے حق میں مشورہ دیتے ہیں۔
باربرا لیسکوف متبادل اصول (LSP)
SOLID ٹول کٹ کا ایک اور اصول۔ اس میں کہا گیا ہے کہ سپر ٹائپ کے لیے ذیلی قسموں کو تبدیل کیا جانا چاہیے۔ یعنی، سپر کلاس کے ساتھ کام کرنے والے طریقے اور فنکشنز کو اس کے ذیلی طبقات کے ساتھ مسائل کے بغیر کام کرنے کے قابل ہونا چاہیے۔
LSP کا تعلق واحد ذمہ داری کے اصول اور ذمہ داری کے اصول کی علیحدگی دونوں سے ہے۔ اگر کوئی کلاس ذیلی طبقے سے زیادہ فعالیت فراہم کرتی ہے، تو مؤخر الذکر اس اصول کی خلاف ورزی کرتے ہوئے کچھ فعالیت کی حمایت نہیں کرے گا۔
یہاں کوڈ کا ایک ٹکڑا ہے جو LSP سے متصادم ہے۔
رقبہ (ریکٹانگل r) طریقہ مستطیل کے رقبے کا حساب لگاتا ہے۔ پروگرام اسکوائر کو چلانے کے بعد کریش ہو جائے گا، کیونکہ اسکوائر یہاں مستطیل نہیں ہے۔ LSP اصول کے مطابق، فنکشنز جو بیس کلاسز کے حوالہ جات استعمال کرتے ہیں، بغیر کسی اضافی ہدایات کے اخذ شدہ کلاسز کی اشیاء کو استعمال کرنے کے قابل ہونا چاہیے۔
یہ اصول، جو کہ ذیلی قسم کی ایک مخصوص تعریف ہے، باربرا لیسکوف نے 1987 کی کانفرنس کے کلیدی نوٹ میں تجویز کیا تھا جسے "ڈیٹا خلاصہ اور درجہ بندی" کہا جاتا ہے - اس لیے اس کا نام ہے۔
انٹرفیس علیحدگی کا اصول (ISP)
ایک اور ٹھوس اصول۔ ان کے بقول، ایسا انٹرفیس جو استعمال نہ کیا گیا ہو اسے نافذ نہیں کیا جانا چاہیے۔ اس اصول پر عمل کرنے سے کام کی منطق میں تبدیلی کرتے وقت نظام کو لچکدار اور قابل عمل رہنے میں مدد ملتی ہے۔
اکثر، یہ صورت حال اس وقت ہوتی ہے جب انٹرفیس ایک ساتھ کئی افعال پر مشتمل ہوتا ہے، اور کلائنٹ کو ان میں سے صرف ایک کی ضرورت ہوتی ہے۔
چونکہ انٹرفیس لکھنا ایک پیچیدہ کام ہے، اس لیے کام مکمل ہونے کے بعد بغیر کسی چیز کو توڑے اسے تبدیل کرنا ایک مسئلہ ہوگا۔
جاوا میں ISP اصول کا فائدہ یہ ہے کہ تمام طریقوں کو پہلے لاگو کیا جانا چاہیے، اور اس کے بعد ہی وہ کلاسز کے ذریعے استعمال کیے جا سکتے ہیں۔ لہذا، اصول طریقوں کی تعداد کو کم کرنے کے لئے ممکن بناتا ہے.
ایک انٹرفیس کے لیے پروگرامنگ، عمل درآمد نہیں۔
یہاں نام سے سب کچھ واضح ہے۔ اس اصول کا اطلاق لچکدار کوڈ کی طرف جاتا ہے جو کسی بھی نئے انٹرفیس کے نفاذ کے ساتھ کام کر سکتا ہے۔
آپ کو متغیرات، واپسی کی اقسام، یا طریقہ دلیل کی قسم کے لیے انٹرفیس کی قسم استعمال کرنی چاہیے۔ ایک مثال SubClass کے بجائے SuperClass کا استعمال کرنا ہے۔
یعنی:
فہرست نمبر = getNumbers();
لیکن نہیں:
ArrayList نمبرز = getNumbers();
اوپر جو کہا گیا ہے اس کا عملی نفاذ یہاں ہے۔
وفد کا اصول
ایک عام مثال جاوا میں equals() اور hashCode() طریقے ہیں۔ جب دو اشیاء کا موازنہ کرنے کی ضرورت ہوتی ہے، تو اس عمل کو کلائنٹ کلاس کے بجائے مناسب کلاس کو سونپا جاتا ہے۔
اصول کا فائدہ یہ ہے کہ کوڈ کی کوئی نقل نہیں ہے اور طرز عمل کو تبدیل کرنا نسبتاً آسان ہے۔ اس کا اطلاق تقریب کے وفد پر بھی ہوتا ہے۔
یہ تمام اصول آپ کو اعلی ہم آہنگی اور کم جوڑے کے ساتھ زیادہ لچکدار، خوبصورت اور قابل اعتماد کوڈ لکھنے کی اجازت دیتے ہیں۔ بلاشبہ، تھیوری اچھی ہے، لیکن ایک ڈویلپر کے لیے حاصل کردہ علم کو واقعی استعمال کرنا شروع کرنے کے لیے، مشق کی ضرورت ہے۔ OOP کے اصولوں پر عبور حاصل کرنے کے بعد اگلا مرحلہ عام سافٹ ویئر ڈویلپمنٹ کے مسائل کو حل کرنے کے لیے ڈیزائن کے نمونوں کا مطالعہ ہو سکتا ہے۔
Skillbox تجویز کرتا ہے:
- پریکٹیکل کورس .
- آن لائن کورس اپلائی کیا۔ .
- دو سالہ پریکٹیکل کورس .
ماخذ: www.habr.com