آبجیکٹ پر مبنی پروگرامنگ کے 5 اصول کیا ہیں؟

ٹھوس ٹھوس ہندسی اعداد و شمار
ٹریننگ
1

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

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

اپنے پیشہ ورانہ کیریئر کے دوران ، میں نے بہت سارے ڈویلپرز کو جانا ہے ، اور میں نے ہزاروں کوڈ لائنز دیکھے ہیں اور جب مجھے کسی ڈویلپر کی مہارت کا اندازہ لگانے کی ضرورت ہوتی ہے تو میں بنیادی طور پر دو عوامل پر غور کرتا ہوں:

  • کوڈ کو پڑھنے میں سادگی؛
  • وقت کے ساتھ ساتھ ان کے کوڈ کے کام کرنے اور تیار ہونے کا کتنا امکان ہے۔

خوش قسمتی سے ، کچھ بنیادی اصول یا اصول ہیں جن کو کوڈنگ میں بہتر بنانا آسان بنا دیتا ہے۔

مخفف 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 ()؛

        فائل_پٹ_کونٹس ($ فائل نام ، سیریلائز ($ کتاب))؛

    }

}

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

دوسرا اصول اوپن / بند -> پڑھ کر جاری رکھیں

1 تفسیر

ایک تبصرہ چھوڑ دو

ال سے tuo indirizzo ای میل غیر سارہ pubblicato. مجھے campi سونو obbligatori contrassegnati *

لسکوف کا اصول
ٹریننگ
لِسکوف سبسٹیشن کا اصول ، تیسرا سولیڈ اصول

چائلڈ کلاسوں کو والدین کی کلاس کی قسم کی تعریف کو کبھی بھی اثر انداز یا تبدیل نہیں کرنا چاہئے۔ اس اصول کا تصور باربرا لسکوف نے 1987 میں منعقدہ کانفرنس کے ایک اہم بیان میں پیش کیا تھا اور اس کے بعد 1994 میں جینیٹ ونگ کے ساتھ مل کر ایک مضمون میں شائع ہوا تھا۔ ان کی اصل تعریف…

گوگل مارکیٹنگ کے رجحانات
ٹریننگ
ریئل ٹائم مارکیٹنگ کے لئے گوگل ٹرینڈس کا استعمال کیسے کریں

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

بزنس انٹیلی جنس حکمت عملی
طریقوں
کاروباری انٹلیجنس کی کامیاب حکمت عملی

اپنے کاروباری ذہانت کے لئے ایک کامیاب حکمت عملی تیار کرنا مقاصد کے صحیح وژن سے شروع ہوتا ہے۔ ہم ذیل میں کچھ بنیادی نکات دیکھتے ہیں۔ موجودہ صورتحال کا جائزہ لینا اس پہلو کو کم سمجھنا سنگین غلطی ہوگی۔ موجودہ صورتحال کا جائزہ لینے کا مطلب ہے عمل ، ڈھانچے کا تجزیہ ...