آبجیکٹ پر مبنی پروگرامنگ (مضمون کا ترجمہ)

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

• یہ سرخ ہے (یہ وقت کے ساتھ تبدیل نہیں ہوتا ہے)۔
• یہ اب 10 سینٹی میٹر لمبا ہے (اگر پنسل کو تیز کیا جائے تو یہ بدل سکتا ہے)۔

اور اس کا مندرجہ ذیل رویہ ہے:

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

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

تجری

تجرید کی تعریف واقعات کے بجائے خیالات کے ساتھ تعامل کے معیار کے طور پر کی جاتی ہے یا دوسرے لفظوں میں نمائندگی کی خصوصیات سے آزادی ۔ یہ پروگرامرز کو اس بات پر توجہ مرکوز کرنے کی اجازت دیتا ہے کہ کس طرح پروگرام کرنے کے بجائے کیا پروگرام کرنا ہے ۔ تجرید کو ایک معاہدے کے طور پر سوچا جا سکتا ہے جس کے ذریعے ہم فعالیت فراہم کرتے ہیں۔ اس تصور کو استعمال کرتے وقت نفاذ کی تفصیلات پوشیدہ ہوسکتی ہیں۔ مثال کے طور پر، اگر ہمیں لکھنے والے طبقے کی ضرورت ہے، تو ہمیں اس بات کا یقین ہونا چاہیے کہ اس کے پاس "لکھنے" کا طریقہ ہے، abstract class writer { write (); } ہم نے کیا کیا ہے؟ ہم نے ایک اعلیٰ درجے کی کلاس ڈیزائن کی ہے جو خلاصہ ہے، دوسرے لفظوں میں، یہ جانتا ہے کہ ہمیں کس فنکشنلٹی کی ضرورت ہے، لیکن اسے کیسے نافذ کرنا ہے اس کلاس کے دائرہ کار سے باہر ہے۔ یہ بہت سے فوائد پیش کرتا ہے:

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

وراثت

عام انگریزی میں "وراثت" کا مطلب ہے "حاصل کرنا اور آگے بڑھنا۔" یہ لفظ ہماری ثقافت میں بہت عرصے سے موجود ہے۔ آباؤ اجداد نے محنت سے زمین حاصل کی اور اسے اپنے بچوں کو منتقل کیا، یہاں تک کہ فطرت وراثت کا حامی ہے۔ تمام جسمانی خصوصیات، جیسے قد، جلد/آنکھ/بالوں کا رنگ، وغیرہ۔ ان جینز پر انحصار کرتے ہیں جو ہم اپنے والدین سے وراثت میں حاصل کرتے ہیں۔ وراثت پہیے کو دوبارہ ایجاد کرنے سے روکتا ہے اور ترقی کو تیز کرتا ہے۔ OOP میں بھی ایسا ہی ہے۔ ہم چند بنیادی خصوصیات/رویے کے ساتھ پیرنٹ کلاس بناتے ہیں۔ اس والدین سے وراثت میں ملنے والی تمام کلاسوں میں وہی خصوصیات/رویے ہوں گے جو ان کے والدین ہیں۔ تاہم، وراثت میں ملنے والی کلاسیں زیادہ خصوصیات/رویے حاصل کر سکتی ہیں یا رویے کے نفاذ کو تبدیل کر سکتی ہیں۔ class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } مندرجہ بالا مثال میں، پیرنٹ کلاس (رائٹنگ انسٹرومنٹ) میں "رنگ" کی خاصیت اور "لکھنے" کا رویہ ہے۔ جب ڈیسنڈنٹ کلاس (ہینڈل) کا اعلان کیا جاتا ہے تو، "رنگ" کی خاصیت اور "لکھیں" کے رویے کو دوبارہ اعلان کرنے کی ضرورت نہیں ہوتی۔ وہ وراثت کی وجہ سے "ہینڈل" کلاس میں موجود ہیں۔ تاہم، ایک نسلی طبقہ اپنی اضافی خصوصیات/رویے کا اعلان کر سکتا ہے۔ ہم اسے عملی طور پر کیسے استعمال کر سکتے ہیں؟ ہم ڈویلپرز بہت سست ہیں۔ ہم بار بار کچھ پرنٹ نہیں کرنا چاہتے۔ مندرجہ ذیل تحفظات کی وجہ سے ایک ہی کوڈ کی متعدد کاپیوں کی موجودگی کی حوصلہ شکنی کی جاتی ہے:

• کوڈ کی جتنی کم کاپیاں ہوں گی، اسے برقرار رکھنا اتنا ہی آسان ہوگا۔
• اگر کوڈ کی بہت سی کاپیاں نہیں ہیں، تو ایک جگہ کی تبدیلی ہر جگہ نظر آتی ہے۔
• کم کوڈ، کم غلطیاں.
• اگر ایک کوڈ کو کئی جگہوں پر استعمال کیا جاتا ہے، تو عامی حاصل ہو جاتی ہے۔
• ہم کوڈ لکھنے پر توجہ دیتے ہیں۔
• ہم ٹیسٹ پر توجہ دیتے ہیں۔

جاوا میں وراثت کلیدی الفاظ "ایکسٹینڈس" اور "عملیات" کا استعمال کرتے ہوئے حاصل کی جاتی ہے۔ class WritingInstrument { } class Pen extends WritingInstrument { }

پولیمورفزم

لفظ "پولیمورفزم" دو الفاظ سے آیا ہے: "پولی" ، یعنی "بہت سے" / "ایک سے زیادہ" "مورف" ، یعنی "فارم" لفظی طور پر، لفظ "پولیمورفزم" سے مراد اشیاء کی حالات کے لحاظ سے مختلف طریقوں سے برتاؤ کرنے کی صلاحیت ہے۔ پروگرامنگ میں، پولیمورفزم کو کئی جگہوں پر لاگو کیا جا سکتا ہے:

• کلاسز
• طریقے
• آپریٹرز

مندرجہ بالا سبھی حالات کے لحاظ سے مختلف طریقے سے برتاؤ کر سکتے ہیں، شاید سیاق و سباق، جس میں وہ استعمال ہوتے ہیں۔ یہ مفید ہے کیونکہ کلائنٹ (آپ کی لائبریریوں کا استعمال کرنے والا پروگرامر) کو بہت ساری باریکیوں کو جاننے کی ضرورت نہیں ہے، اور مطلوبہ فعالیت کو سیاق و سباق سے ضروری معلومات کو منتخب کرکے لاگو کیا جاتا ہے۔ Class WritingObject { wrire() { // пишем, используя стандартные (по дефолту) цвета } } class Pencil extends WritingObject { write() { // пишем, используя серый цвет, написанный текст можно стереть } } class Pen extends WritingObject { write() { // пишем, используя голубой цвет, написанный текст нельзя стереть } } class Main { main() { WritingObject wr = new WritingObject(); wr.write(); // первый вызов WritingObject wr = new Pen(); wr.write(); // второй вызов WritingObject wr2 = new Pencil(); wr2.write(); // третий вызов } } اوپر دی گئی مثال WritingObject میں پہلے سے طے شدہ عمل درآمد کرتی ہے، جسے نسلی طبقوں کے قلم اور قلم کے ذریعے بڑھایا/اوور رائیڈ کیا جاتا ہے۔ رائٹ() طریقہ مین کلاس میں تین بار کہا جاتا ہے۔ ہر بار ایک مختلف نفاذ کو بلایا جاتا ہے اس پر منحصر ہے کہ طریقہ کس چیز پر بلایا جاتا ہے۔ اس صورت میں، write() طریقہ کار میں کئی قسم کے رویے ہوتے ہیں کیونکہ یہ پولیمورفک ہے۔

انکیپسولیشن

Encapsulation کی تعریف ایک یونٹ میں متعلقہ ڈیٹا/فعالیت کو جمع کرنے کے طور پر کی گئی ہے۔ اس سے ڈیٹا تک رسائی/ترمیم کرنے میں مدد ملتی ہے۔ مثال کے طور پر، اگر ہمیں کسی صارف کے پاس موجود تمام خصوصیات کو پرنٹ کرنے کی ضرورت ہے، تو ہمارے پاس درج ذیل اختیارات ہیں: ہم نے printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) ایک طریقہ بنایا ہے جو تمام خصوصیات کو لے کر ایک کے بعد ایک پرنٹ کرتا ہے۔ جیسے جیسے فہرست میں عناصر کی تعداد بڑھتی جائے گی، درست فیلڈز کی شناخت کرنا اب ممکن نہیں رہے گا، اور ایک فیلڈ کو شامل کرنے/ہٹانے سے طریقہ کار کے دستخط بدل جائیں گے۔ لہذا، ہمیں اس طریقہ کار کے تمام صارفین کو تبدیل کرنے کی ضرورت ہے، چاہے انہیں حال ہی میں شامل کردہ فیلڈز کی ضرورت نہ ہو۔ کوڈ کو مزید پڑھنے کے قابل بنانے اور مستقبل میں ہونے والی ترمیمات کو آسان بنانے کے لیے، ہم پراپرٹیز کو کلاس میں سمیٹتے ہیں اور اسے ایک اجتماعی آبجیکٹ میں تبدیل کرتے ہیں۔ class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} ایک آبجیکٹ متغیرات اور متعلقہ طریقوں کا ایک سافٹ ویئر بنڈل ہوتا ہے۔ آپ پروگرام آبجیکٹ کا استعمال کرتے ہوئے حقیقی دنیا کی اشیاء کی نمائندگی کر سکتے ہیں۔ آپ کسی حرکت پذیری پروگرام میں اصلی کتوں کا تصور کر سکتے ہیں، یا ایک حقیقی بائیسکل کو ایک سوفٹ ویئر آبجیکٹ کے طور پر ایک ورزش بائیک کے اندر تصور کر سکتے ہیں۔ OOP میں، ایک کلاس ایک قابل توسیع ٹیمپلیٹ (پروگرام-کوڈ-ٹیمپلیٹ) ہے جو اشیاء کو تخلیق کرنے، انہیں ابتدائی حالت (متغیرات) فراہم کرنے اور رویے (فنکشنز، طریقے) کو نافذ کرنے کے لیے ہے۔ SOLID کا مخفف مائیکل فیدر نے 2000 کی دہائی کے اوائل میں رابرٹ سی مارٹن کے نام سے منسوب "پہلے پانچ اصولوں" کے لیے تیار کیا تھا۔ اصولوں کا مقصد، جب ایک ساتھ لاگو کیا جاتا ہے، اس امکان کو بڑھانا ہے کہ پروگرامر ایک ایسا نظام بنائے گا جسے برقرار رکھنا اور بڑھانا آسان ہے۔ ٹھوس اصول پروگرام کی ترقی میں رہنما اصول ہیں جو ریفیکٹرنگ کے ذریعے "سڑے ہوئے" کوڈ کو ہٹانے کے لیے ضروری ہیں، جس کے نتیجے میں کوڈ کو آسانی سے پڑھنے کے قابل اور قابل توسیع ہونا چاہیے۔ یہ فرتیلی اور انکولی پروگرامنگ حکمت عملی کا حصہ ہے۔

واحد ذمہ داری کا اصول

OOP میں، واحد ذمہ داری کا اصول یہ بتاتا ہے کہ ہر طبقے کو پروگرام کے ذریعے فراہم کردہ فعالیت کے ایک حصے کے لیے ذمہ دار ہونا چاہیے، اور اس ذمہ داری کو اس طبقے کے ذریعے مکمل طور پر سمیٹنا چاہیے۔ اس کی تمام فعالیت کا اس ذمہ داری سے گہرا تعلق ہونا چاہیے۔

کھلا/بند اصول

OOP میں، کھلا/بند اصول بتاتا ہے کہ "سافٹ ویئر اداروں (کلاسز، ماڈیولز، طریقے، وغیرہ) کو توسیع کے لیے کھلا ہونا چاہیے لیکن تبدیلی کے لیے بند ہونا چاہیے۔" دوسرے لفظوں میں، ادارے کو ماخذ کوڈ کو تبدیل کیے بغیر اپنے رویے کو بڑھانے کی اجازت دینی چاہیے۔

Liskov متبادل اصول

OOP میں متبادل ایک اصول ہے۔ اس میں کہا گیا ہے کہ اگر کمپیوٹر پروگرام میں S T کا ذیلی قسم ہے تو T قسم کی اشیاء ایسی ہونی چاہئیں کہ انہیں S قسم کی اشیاء سے تبدیل کیا جا سکے (یعنی قسم S کی اشیاء کو T قسم کی اشیاء سے تبدیل کیا جا سکتا ہے)۔ کسی بھی مطلوبہ خصوصیات کے پروگرام (درستگی، کام کی تکمیل، وغیرہ)۔

انٹرفیس علیحدگی کا اصول

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

انحصار الٹا اصول

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

• اعلی سطح کے ماڈیولز کو کم سطح کے ماڈیولز پر انحصار نہیں کرنا چاہیے۔ دونوں قسم کے ماڈیولز کا انحصار تجرید پر ہونا چاہیے۔
• خلاصہ عمل درآمد کی تفصیلات پر منحصر نہیں ہونا چاہئے۔ تفصیلات کا انحصار تجرید پر ہونا چاہیے۔

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

گرفت کے اصول

جنرل ریسپانسیبلٹی اسائنمنٹ سافٹ ویئر پیٹرنز (GRASP) آبجیکٹ پر مبنی ڈیزائن میں کلاسوں اور اشیاء کو ذمہ داریاں تفویض کرنے کے لیے رہنما خطوط فراہم کرتے ہیں۔

کنٹرولر

کنٹرولر پیٹرن سسٹم کے واقعات کے ساتھ بات چیت کرنے کی ذمہ داری غیر GUI کلاسز کو تفویض کرتا ہے جو پورے سسٹم کی نمائندگی کرتے ہیں یا کیس کے منظر نامے کو استعمال کرتے ہیں۔ کنٹرولر:

• یہ ایک ایسی چیز ہے جو صارف کے ساتھ براہ راست تعامل نہیں کرتی ہے اور سسٹم کے واقعات کو وصول کرنے اور جواب دینے کے لیے ذمہ دار ہے۔
• ایک (یا بہت سے باہم منسلک) استعمال کے معاملات کے تمام سسٹم ایونٹس سے نمٹنے کے لیے استعمال کیا جانا چاہیے۔
• یہ GUI کے پیچھے پہلی چیز ہے جو سسٹم کی کارروائیوں کو کنٹرول کرتی ہے۔
• اسے کام خود کرنے کی ضرورت نہیں ہے؛ اس کا کام واقعات کے بہاؤ کو کنٹرول کرنا ہے۔

خالق

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

اعلی ہم آہنگی

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

بالواسطہ

راؤنڈ اباؤٹ پیٹرن ایک انٹرمیڈیٹ آبجیکٹ کو ان کے درمیان تعامل کی ذمہ داری تفویض کرکے دو عناصر کے درمیان ڈھیلے جوڑے (اور دوبارہ استعمال کے قابل) کو برقرار رکھتا ہے۔ ایک مثال ماڈل-ویو-کنٹرولر (MVC) پیٹرن میں ڈیٹا (ماڈل) اور اس کے ڈسپلے (ویو) کے درمیان ثالثی کرنے کے لیے کنٹرولر کا تعارف ہے۔

ماہر معلومات

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

کم کپلنگ

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

پولیمورفزم

پولیمورفزم کے مطابق، قسم کی بنیاد پر رویے کا تغیر ان اقسام کو تفویض کیا جاتا ہے جن کے لیے یہ تغیر ہوتا ہے۔ یہ پولیمورفک آپریشنز کا استعمال کرکے حاصل کیا جاتا ہے۔

محفوظ تغیرات

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

خالص فیبریکیشن

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

تنقید

Potok et al. کی تحقیق نے OOP اور طریقہ کار کے درمیان کوئی خاص فرق نہیں دکھایا۔

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

دوسری زبانوں کے مقابلے (LISP بولیاں، فنکشنل زبانیں، وغیرہ)، OOP زبانوں کا کوئی منفرد فائدہ نہیں ہوتا اور وہ غیر ضروری پیچیدگیاں مسلط کرتی ہیں۔ (لارنس کروبنر)

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

بڑی کمپنیوں میں OOP کی مقبولیت "معمولی پروگرامرز کے بڑے (اور اکثر بدلتے ہوئے) گروپوں" کی وجہ سے ہے۔ OOP کی طرف سے نافذ کردہ نظم و ضبط پروگرامر کو "بہت زیادہ نقصان" کرنے سے روکتا ہے۔ (پال گراہم)

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

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

لنکس

بذریعہ مارگریٹ راؤس @ WhatIs.com ویکیپیڈیا! ( روسی ورژن ) وراثت پولیمورفزم ہے SOLID (آبجیکٹ اورینٹڈ ڈیزائن) ( روسی ورژن ) واحد ذمہ داری کے اصول OOPS کے خلاف دلائل ( روسی ورژن ) OOPS کیا ہے (ہائپ کے بغیر) ترجمہ: Varygin D.V.