اعتراض تي مبني پروگرامنگ (مضمون جو ترجمو)

مترجم کان: بدقسمتيءَ سان، مون کي انگريزيءَ مان ترجمي ڪرڻ جو ڪو خاص تجربو ڪونهي، جيتوڻيڪ مون انگريزيءَ ۾ گهڻو ڪجهه پڙهيو آهي. پر اهو ثابت ٿيو ته پڙهڻ ۽ ترجمو ڪرڻ ٻه الڳ شيون آهن. انهي سان گڏ، بدقسمتي سان، مون وٽ اهم پروگرامنگ تجربو نه آهي (مون تازو صرف هڪ سادي ويب ايپليڪيشن ٺاهي آهي اسپرنگ MVC ۽ Hibernate ۾). تنهن ڪري، ترجمو ان کان وڌيڪ خراب ٿي سگهي ٿو جيڪو ٿي سگهي ٿو. مون مضمون ۾ ڏنل ڪوڊ جي مثالن کي ٿورڙي درست ڪرڻ جي آزادي ورتي، ڇاڪاڻ ته اهي جاوا ۾ نالي جي ڪنوينشن جي تعميل نٿا ڪن. شايد ڪجهه نمونن جي نالن جو ترجمو ڪرڻ جي لائق نه هو (اهڙي ترجمي ۾ گهڻي سمجهه نه ايندي آهي)، پر مون سمجهيو ته اها گهٽ برائي هئي. اها ڳالهه الڳ الڳ ذڪر ڪرڻ جي لائق آهي ته ”High cohesion“ جو ترجمو ”High cohesion“ جي صورت ۾. مان متفق آهيان، بهترين ترجمو ناهي. پر ”مضبوط ڪنيڪشن“ آهي ”هاءِ ڪوپلنگ“ (هڪ ٻيو اهم تصور)، ۽ ”مضبوطي“ هتي مناسب هجڻ ممڪن ناهي. مان تنقيد لاءِ کليل آهيان ۽ شڪرگذاري سان ڪنهن به شڪل ۾ آرٽيڪل تي تبصرو قبول ڪندس. Object-oriented programming پروگرامنگ جو ھڪڙو انداز آھي جنھن ۾ ھڪڙو پروگرام اجزاء سان ٺھيل آھي جيڪي حقيقي دنيا جي شين سان ملن ٿا. ڪنھن به حقيقي شئي ۾ ڪجھ خاصيتون آھن (جيڪي وقت سان تبديل ٿي سگھن ٿيون يا نه ٿيون) ۽ رويي (جيڪا ٿي سگھي ٿي يا نه ٿي سگھي) تبديليءَ جو دارومدار ٻين تي). مثال طور، پنسل هڪ حقيقي دنيا جي شيء آهي جنهن ۾ هيٺيون خاصيتون آهن:

• اهو ڳاڙهو آهي (اهو وقت سان تبديل نٿو ٿئي).
• اهو هاڻي 10 سينٽي ميٽر ڊگهو آهي (جيڪڏهن پينسل کي تيز ڪيو وڃي ته اهو تبديل ٿي سگهي ٿو).

۽ اھو ھيٺ ڏنل رويي آھي:

• اهو هڪ نشان ڇڏي ٿو جيڪڏهن صحيح استعمال ڪيو وڃي.
• دٻاء جي لحاظ کان نشان مختلف ٿي سگھي ٿو (انحصار خارجي عنصر تي).
• ان جي ڊگھائي گھٽ ٿئي ٿي جيئن ان کي تيز ڪيو وڃي (مستقل رويو).

جيئن ته هن مثال ۾، حقيقي دنيا جون شيون ڪيتريون ئي ملڪيتون ٿي سگهن ٿيون، پر جڏهن پروگرام لکندا آهيون ته اسان صرف ضروري ملڪيتن کي حساب ۾ رکون ٿا. اعتراض تي مبني پروگرامنگ جا فائدا آهن. مثال طور، اهو آسان بڻائي ٿو هڪ حقيقي دنيا جي اعتراض جي وچ ۾ ڪنيڪشن قائم ڪرڻ ۽ متوقع طريقي سان هڪ پروگرام. اهو حقيقت ۾ مدد ڪري ٿو جيئن ايپليڪيشن وڌندي آهي ۽ ڪيتريون ئي شيون هڪ ٻئي سان لهه وچڙ ۾ اچن ٿيون. هي مقصد جي دنيا ۾ ذميواريون ورهائڻ ۾ مدد ڪري ٿي، توهان کي ايپليڪيشن ذريعي سوچڻ تي ڌيان ڏيڻ جي اجازت ڏئي ٿي. OOP (Object Oriented Programming) سان جڙيل هڪ ٻي اهم خاصيت شين جي درجه بندي آهي. جيئن ته دنيا (حقيقي / مجازي) شين سان ڀريل آهي، ان کي انفرادي طور تي ڪنٽرول ڪرڻ ڏکيو آهي. اسان کي انهن شين جي درجه بندي ڪرڻ لاءِ هڪ طريقو گهرجي جيڪو اسان کي مختلف شين ۽ انهن جي ملڪيتن کي ڳنڍڻ ۾ مدد ڏيندو، جهڙوڪ ڪارو پنسل. جيڪڏهن پوئين مثال ۾ استعمال ڪيو ويو ته اهو الڳ الڳ (ساڳي؟) هوندو، پر اهو هڪ مختلف اعتراض آهي. پر جيئن ته اهي ٻئي پينسل آهن، انهن جو تعلق هڪ ئي طبقي ”پينسل“ سان آهي. جڏهن ته قلم، جيڪو پينسل سان بلڪل ملندڙ جلندڙ هوندو آهي، ان جو تعلق مختلف طبقي سان هوندو آهي. بهرحال، قلم ۽ پينسل ٻئي ”لکڻ جا اوزار“ آهن. اعتراض تي مبني پروگرامنگ جا هيٺيان اصول آهن:

خلاصو

تجريد جي تعريف ڪئي وئي آهي خيالن سان رابطي جي معيار جي بجاءِ واقعن جي ، يا ٻين لفظن ۾، نمائندگي جي خاصيتن کان آزادي . هي پروگرامرز کي اجازت ڏئي ٿو ته پروگرام ڪيئن ڪجي بجاءِ ته پروگرام ڪيئن ڪجي . خلاصو سمجهي سگهجي ٿو هڪ معاهدي جي طور تي جنهن جي ذريعي اسان ڪارڪردگي مهيا ڪندا آهيون. هن تصور کي استعمال ڪندي لاڳو ڪرڻ جا تفصيل لڪيل هوندا. مثال طور، جيڪڏهن اسان کي هڪ طبقي جي ضرورت آهي جيڪو لکي ٿو، پوء اسان کي پڪ ڪرڻ گهرجي ته ان ۾ "لکڻ" جو طريقو آهي، abstract class writer { write (); } اسان ڇا ڪيو آهي؟ اسان هڪ اعليٰ سطحي طبقو ٺاهيو آهي جيڪو خلاصو آهي، ٻين لفظن ۾، اهو ڄاڻي ٿو ته اسان کي ڪهڙي ڪارڪردگي جي ضرورت آهي، پر ان کي ڪيئن لاڳو ڪرڻ هن طبقي جي دائري کان ٻاهر آهي. هي ڪيترائي فائدا پيش ڪري ٿو:

• اسان خارجي ادارن لاءِ گهربل گهٽ ۾ گهٽ معلومات ظاهر ڪريون ٿا، هي اسان کي پروگرام ذريعي سوچڻ تي ڌيان ڏيڻ جي اجازت ڏئي ٿو (هي توجهه واري سوچ کي چالو ڪري ٿو)، مونجهاري کان بچڻ ۽ غير ارادي واعدو ڪرڻ کان پاسو ڪري ٿو.
• اسان مستقبل جي سڌارن لاءِ گنجائش ڇڏي ڏيون ٿا جيڪي ممڪن نه هوندا جيڪڏهن عمل درآمد جا تفصيل ظاهر ڪيا ويندا.

وراثت

عام انگريزي ۾ "وراثت" جو مطلب آهي "حاصل ڪرڻ ۽ منتقل ڪرڻ." اهو لفظ اسان جي ثقافت ۾ ڪافي عرصي کان موجود آهي. ابن ڏاڏن سخت محنت سان زمين حاصل ڪئي ۽ اها پنهنجي اولاد کي منتقل ڪئي، ايستائين جو فطرت وراثت جي حق ۾ آهي. سڀ جسماني ملڪيت، جهڙوڪ اونچائي، چمڙي / اک / وارن جو رنگ، وغيره. جين تي دارومدار رکون ٿا جيڪي اسان کي پنهنجي والدين کان ورثي ۾ مليا آهن. وراثت ڦيٿي کي بحال ڪرڻ کان روڪي ٿي ۽ ترقي کي تيز ڪري ٿي. اهو ساڳيو آهي OOP ۾. اسان ڪجھ بنيادي ملڪيتن / رويي سان ھڪڙو والدين ڪلاس ٺاھيون ٿا. ھن والدين کان ورثي ۾ ملندڙ سڀ طبقن ۾ انھن جي والدين وانگر ساڳيون ملڪيتون/رويو ھوندو. بهرحال، وراثت وارا طبقا وڌيڪ ملڪيت/رويي حاصل ڪري سگھن ٿا يا رويي جي عمل کي تبديل ڪري سگھن ٿا. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } مٿين مثال ۾، والدين طبقي (WritingInstrument) وٽ ”رنگ“ ملڪيت ۽ ”لکڻ“ جو رويو آهي. جڏهن نسلي طبقي (هينڊل) جو اعلان ڪيو ويو آهي، "رنگ" ملڪيت ۽ "لکڻ" جي رويي کي ٻيهر اعلان ڪرڻ جي ضرورت ناهي. اهي وراثت جي ڪري "هٿ" طبقي ۾ موجود آهن. بهرحال، هڪ نسلي طبقو پنهنجي اضافي ملڪيت/رويي جو اعلان ڪري سگهي ٿو. اسان هن کي عملي طور تي ڪيئن استعمال ڪري سگهون ٿا؟ اسان ڊولپر ڏاڍا سست آهيون. اسان نه ٿا چاهيون ته ڪا شيءِ بار بار ڇپجي. ساڳئي ڪوڊ جي ڪيترن ئي نقلن جي موجودگي کي هيٺ ڏنل خيالن جي ڪري حوصلا افزائي ڪئي وئي آهي:

• ڪوڊ جون گهٽ ڪاپيون، برقرار رکڻ آسان آهي.
• جيڪڏهن ڪوڊ جون ڪيتريون ئي ڪاپيون نه آهن، ته پوء هڪ جاء تي تبديلي هر جڳهه تي نظر اچي ٿي.
• گهٽ ڪوڊ، گهٽ غلطيون.
• جيڪڏهن هڪ ڪوڊ ڪيترن ئي هنڌن تي استعمال ڪيو ويندو آهي، پوء عام ڪرڻ حاصل ڪيو ويندو آهي.
• اسان ڪوڊ لکڻ تي ڌيان ڏيون ٿا.
• اسان ٽيسٽ تي ڌيان ڏيون ٿا.

جاوا ۾ وراثت حاصل ڪئي وئي لفظ استعمال ڪندي "extensions" ۽ "عمل درآمد". 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 ۾ هڪ ڊفالٽ عمل درآمد آهي، جنهن کي ڊاريونگ ڪلاسز قلم ۽ قلم ذريعي وڌايو/اوور رائڊ ڪيو ويو آهي. لکڻ () طريقو مين ڪلاس ۾ ٽي دفعا سڏيو ويندو آهي. هر دفعي هڪ مختلف عمل کي سڏيو ويندو آهي ان تي منحصر آهي ته ڪهڙي شئي تي طريقو سڏيو وڃي ٿو. انهي صورت ۾، لکڻ () طريقو ڪيترن ئي قسمن جي رويي جو سبب آهي ڇو ته اهو پوليمورفڪ آهي.

انڪپسوليشن

Encapsulation هڪ يونٽ ۾ لاڳاپيل ڊيٽا / ڪارڪردگي کي گڏ ڪرڻ جي طور تي بيان ڪيو ويو آهي. هي ڊيٽا تائين رسائي/تبديل ڪرڻ ۾ مدد ڪري ٿو. مثال طور، جيڪڏهن اسان کي ضرورت آهي ته اهي سڀئي خاصيتون پرنٽ ڪيون جيڪي هڪ ڏنل صارف وٽ آهن، اسان وٽ هيٺيان آپشن آهن: اسان printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) هڪ طريقو ٺاهيو آهي جيڪو سڀني ملڪيتن کي وٺي ٿو ۽ انهن کي هڪ ٻئي پٺيان ڇپائي ٿو. جيئن لسٽ ۾ عنصرن جو تعداد وڌندو، تيئن صحيح فيلڊن کي سڃاڻڻ ممڪن نه ٿيندو، ۽ ھڪڙي فيلڊ کي شامل ڪرڻ/هٽائڻ سان طريقو دستخط تبديل ٿيندو. تنهن ڪري، اسان کي هن طريقي جي سڀني صارفين کي تبديل ڪرڻ جي ضرورت آهي، جيتوڻيڪ انهن کي نئين شامل ڪيل فيلڊ جي ضرورت ناهي. ڪوڊ کي وڌيڪ پڙهڻ لائق بنائڻ ۽ مستقبل جي تبديلين کي آسان بنائڻ لاءِ، اسان پراپرٽيز کي ڪلاس ۾ شامل ڪري ان کي مجموعي شئي ۾ تبديل ڪريون ٿا. class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} هڪ اعتراض متغيرن ۽ لاڳاپيل طريقن جو هڪ سافٽ ويئر بنڊل آهي. توهان پروگرام جي شين کي استعمال ڪندي حقيقي دنيا جي شين جي نمائندگي ڪري سگهو ٿا. توهان تصور ڪري سگهو ٿا حقيقي ڪتن کي هڪ اينيميشن پروگرام ۾، يا هڪ حقيقي سائيڪل کي هڪ سافٽ ويئر اعتراض جي طور تي هڪ مشق سائيڪل اندر. او او پي ۾، هڪ ڪلاس هڪ وسعت وارو ٽيمپليٽ آهي (پروگرام-ڪوڊ-ٽيمپليٽ) شيون ٺاهڻ لاءِ، انهن کي هڪ ابتدائي حالت (متغير) مهيا ڪرڻ ۽ عمل ڪرڻ واري عمل (فڪشن، طريقا). SOLID جو مخفف مائيڪل فيدر 2000ع جي شروعات ۾ رابرٽ سي مارٽن جي نالي ”پهرين پنج اصولن“ لاءِ جوڙيو هو. اصولن جو مقصد، جڏهن گڏجي لاڳو ڪيو وڃي، اهو امڪان وڌائڻ آهي ته پروگرامر هڪ سسٽم ٺاهيندو جيڪو برقرار رکڻ ۽ وڌائڻ ۾ آسان آهي. SOLID اصول پروگرام ڊولپمينٽ ۾ ھدايتون آھن جيڪي ضروري آھن ته ”سڙھيل“ ڪوڊ کي ريفيڪٽرنگ ذريعي ختم ڪيو وڃي، جنھن جي نتيجي ۾ ڪوڊ کي آسانيءَ سان پڙھڻ لائق ۽ وسعت ڏيڻ گھرجي. هي حصو آهي چست ۽ موافق پروگرامنگ حڪمت عملي.

اڪيلو ذميواري اصول

OOP ۾، واحد ذميواري اصول بيان ڪري ٿو ته هر طبقي کي پروگرام پاران مهيا ڪيل ڪارڪردگي جي هڪ حصي لاء ذميوار هجڻ گهرجي، ۽ اها ذميواري مڪمل طور تي انهي طبقي طرفان شامل ٿيڻ گهرجي. ان جي سڀني ڪارڪردگي کي هن ذميواري سان ويجهي سان لاڳاپيل هجڻ گهرجي.

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

OOP ۾، کليل/بند ٿيل اصول ٻڌائي ٿو ته "سافٽ ويئر ادارن (ڪلاس، ماڊل، طريقا، وغيره) کي وڌائڻ لاء کليل هجڻ گهرجي پر تبديل ڪرڻ لاء بند ڪيو وڃي." ٻين لفظن ۾، اداري کي اجازت ڏيڻ گهرجي ته ان جي رويي کي وڌايو وڃي بغير سورس ڪوڊ کي تبديل ڪرڻ جي.

Liskov متبادل اصول

OOP ۾ متبادل هڪ اصول آهي. اهو ٻڌائي ٿو ته جيڪڏهن ڪمپيوٽر جي پروگرام ۾ S، T جو ذيلي قسم آهي، ته پوءِ T قسم جون شيون اهڙيون هجڻ گهرجن ته انهن کي تبديل ڪرڻ کان سواءِ S قسم جي شين سان تبديل ڪري سگهجي (يعني قسم S جون شيون T قسم جي شين سان تبديل ڪري سگهجن ٿيون) ڪنهن به گهربل ملڪيت جا پروگرام (درستگي، ڪم مڪمل ڪرڻ، وغيره).

انٽرفيس الڳ ڪرڻ جو اصول

انٽرفيس جي علحدگيءَ جو اصول ٻڌائي ٿو ته ڪلائنٽ پروگرامر کي مجبور نه ڪيو وڃي ته هو انهن طريقن تي ڀاڙين جيڪي اهو استعمال نه ڪن. هن اصول جي مطابق، اهو ضروري آهي ته وڏن انٽرنيٽ کي ننڍن ۽ وڌيڪ مخصوص ۾ ورهايو وڃي ته جيئن ڪلائنٽ پروگرامر صرف انهن طريقن جي باري ۾ ڄاڻي ٿو جيڪي هن لاء دلچسپ آهن. انٽرفيس ڊيڪپلنگ اصول جو مقصد سسٽم کي ڊيڪپل ٿيل رکڻ آهي، جيڪو ان کي ريفيڪٽر ڪرڻ، تبديليون ڪرڻ ۽ ٻيهر ترتيب ڏيڻ آسان بڻائيندو.

انحصار جي ڦيرڦار جو اصول

OOP ۾، انحصار جي ڦيرڦار جي اصول جو مطلب آهي پروگرام ماڊلز جي وچ ۾ ڪنيڪشن جو هڪ مخصوص روپ. هن اصول تي عمل ڪندي، اعليٰ سطحي ماڊلز کان قائم ٿيل معياري انحصار رشتا ايپليڪيشن آرڪيٽيڪچر (پاليسي سيٽنگ) کان وٺي انحصار ڪندڙ گهٽ-سطح ماڊلز کي الٽي (ريورس) ڪيو ويو آهي، انهي ڪري ته تبديل ٿيل اعلي سطحي ماڊلز جي عمل درآمد جي تفصيلن کان آزاد ٿي وڃن. گھٽ-سطح ماڊلز. هي اصول چوي ٿو:

• اعلي سطحي ماڊلز کي هيٺين سطح جي ماڊلز تي منحصر نه هجڻ گهرجي. ٻنهي قسمن جا ماڊل لازمي طور تي ڀاڙين ٿا.
• خلاصو عمل درآمد جي تفصيل تي منحصر نه هجڻ گهرجي. تفصيلات لازمي طور تي خلاصن تي منحصر آهن.

اصول ان طريقي کي تبديل ڪري ٿو جيڪو ماڻهو اعتراض تي مبني ڊيزائن جي باري ۾ سوچي سگهي ٿو اهو بيان ڪندي ته اعلي ۽ گهٽ-سطح واري شين کي ساڳئي تجريد تي منحصر هجڻ گهرجي.

GRASP اصول

The General Responsibility Assignment Software Patterns (GRASP) ذميدارين کي تفويض ڪرڻ لاءِ هدايتون مهيا ڪن ٿيون ڪلاسز ۽ اعتراضن تي مبني ڊيزائن ۾.

ڪنٽرولر

ڪنٽرولر نمونو غير GUI طبقن کي سسٽم جي واقعن سان لهه وچڙ جي ذميواري تفويض ڪري ٿو جيڪي پوري سسٽم جي نمائندگي ڪن ٿا يا ڪيس جي منظر نامي کي استعمال ڪن ٿا. ڪنٽرولر:

• هي هڪ اعتراض آهي جيڪو صارف سان سڌو رابطو نٿو ڪري ۽ سسٽم جي واقعن کي وصول ڪرڻ ۽ جواب ڏيڻ جو ذميوار آهي.
• لازمي طور تي استعمال ڪيو وڃي سسٽم جي سڀني واقعن سان معاملو ڪرڻ لاءِ هڪ (يا ڪيترائي باضابطه) استعمال ڪيس.
• اهو GUI جي پويان پهريون اعتراض آهي جيڪو سسٽم جي عملن کي سنڀاليندو آهي.
• هن کي پنهنجو ڪم نه ڪرڻو آهي؛ هن جو ڪم واقعن جي وهڪري کي ڪنٽرول ڪرڻ آهي.

پيدا ڪندڙ

تخليق ڪندڙ طبقي جو ڪم ايندڙ استعمال لاءِ شيون ٺاهڻ ۽ شروع ڪرڻ آهي. اهو ڄاڻي ٿو شروعاتي پيٽرولر، انهي سان گڏ ڪهڙي شئي ٺاهي ويندي. ڪڏهن ڪڏهن تخليق ڪندڙ طبقو فعال طور تي شيون ٺاهي ٿو ۽ انهن کي ڪيش ۾ رکي ٿو، ۽ هڪ مثال مهيا ڪري ٿو جڏهن اها ضرورت هجي.

اعليٰ هم آهنگي

اعلي هم آهنگي هڪ تشخيصي نمونو آهي، جنهن جو مقصد شين کي اهڙي حالت ۾ محفوظ ڪرڻ آهي ته اهي هڪ واضح ڪم کي انجام ڏيڻ جو مقصد آهن، آساني سان ڪنٽرول ۽ سمجهي رهيا آهن. هاء ملائڻ عام طور تي استعمال ڪيو ويندو آهي گهٽ ملائڻ جي حمايت ڪرڻ لاء. اعلي هم آهنگي جو مطلب آهي ته ڏنل عنصر جون ذميواريون واضح طور تي بيان ڪيون ويون آهن (مضبوط طور تي لاڳاپيل ۽ انتهائي مرکوز). هڪ پروگرام کي طبقن ۽ سبسسٽمن ۾ ورهائڻ عملن جو هڪ مثال آهي جيڪو سسٽم جي ملڪيتن جي هڪجهڙائي کي وڌائي ٿو. ٻئي طرف، لوز جوڙڻ، هڪ اهڙي صورتحال آهي جنهن ۾ هڪ عنصر تمام گهڻا غير لاڳاپيل ڪم آهن. لوز سان ملندڙ عناصر کي سمجھڻ ڏکيو، ٻيهر استعمال ڪرڻ، برقرار رکڻ ڏکيو، ۽ تبديل ڪرڻ ڏکيو آھي.

هدايت

راؤنڊاباؤٽ نمونو ٻن عنصرن جي وچ ۾ لوز ڪپلنگ (۽ ٻيهر استعمال جي قابليت) کي برقرار رکي ٿو انهن جي وچ ۾ رابطي جي ذميواري تفويض ڪندي هڪ وچولي شئي ڏانهن. ھڪڙو مثال ھڪڙو ڪنٽرولر جو تعارف آھي ڊيٽا (ماڊل) ۽ ان جي ڊسپلي (ڏس) جي وچ ۾ ماڊل-ويو-ڪنٽرولر (MVC) نموني ۾ وچولي ڪرڻ لاء.

ڄاڻ جو ماهر

معلومات جو ماهر (پڻ ماهر يا ماهر اصول) هڪ اصول آهي جيڪو اهو طئي ڪرڻ لاءِ استعمال ڪيو ويندو آهي ته ڪنهن کي ذميواري سونپي وڃي. ذميدارين ۾ طريقا شامل آهن، حساب ڪيل فيلڊ، وغيره. جڏهن هن اصول کي استعمال ڪندي جڏهن ذميواري کي تفويض ڪيو وڃي، بنيادي نقطو عملن جي هيٺيان ترتيب آهي: ذميواري جو تجزيو ڪرڻ، معلومات کي سڃاڻڻ جيڪا ان کي پورو ڪرڻ جي ضرورت آهي، ۽ آخرڪار اهو قائم ڪرڻ جتي هي معلومات واقع آهي. انفارميشن ماهر اصول کي استعمال ڪرڻ جي نتيجي ۾ ان طبقي کي ذميواري تفويض ڪري ٿي جنهن کي ان تي عمل ڪرڻ لاءِ سڀ کان وڌيڪ معلومات آهي.

گھٽ ملائڻ

لوز ڪپلنگ هڪ تشخيصي نمونو آهي جيڪو وضاحت ڪري ٿو ته ڪيئن ذميواريون تفويض ڪيون وڃن: ڪلاسن جي وچ ۾ لوز ڪپلنگ، هڪ کي تبديل ڪرڻ سان ٻئي تي گهٽ ۾ گهٽ اثر پوڻ گهرجي، وڌ کان وڌ استعمال جي قابليت.

پوليمورفيزم

پوليمورفيزم (Polymorphism) جي مطابق، قسم جي بنياد تي رويي جي مختلف قسمن کي مقرر ڪيو ويو آهي جن جي لاء هي تبديلي ٿئي ٿي. اهو پوليمورفڪ آپريشن استعمال ڪندي حاصل ڪيو ويندو آهي.

محفوظ ٿيل تبديليون

حفاظتي تبديلين جو نمونو عناصرن کي ٻين عنصرن (آبجڪس، سسٽم، سب سسٽم) ۾ تبديلين کان بچائيندو آهي هڪ انٽرفيس ۾ عدم استحڪام جي توجه کي لپائڻ ۽ ان انٽرفيس جي مختلف عملن کي ٺاهڻ لاءِ پوليمورفيزم استعمال ڪندي.

خالص ٺاھڻ

خالص تعمير ۾ ھڪڙو طبقو شامل آھي جيڪو مسئلي جي ڊومين ۾ ھڪڙي تصور جي نمائندگي نٿو ڪري ۽ خاص طور تي ٺھيل آھي حاصل ڪرڻ لاء لوز ڪولنگ، اعلي ھم آہنگي، ۽ ان ڪري وڌ ۾ وڌ استعمال جي صلاحيت (انفارميشن ماهر نموني پاران پيش ڪيل حل اھو حاصل نٿو ڪري). اهڙي طبقي کي عام طور تي "سروس" سڏيو ويندو آهي ڊومين تي هلندڙ ڊيزائن ۾.

تنقيد

Potok et al. پاران تحقيق OOP ۽ طريقيڪار جي وچ ۾ ڪو خاص فرق نه ڏيکاريو.

او او پي جو ٻين ٽيڪنالاجين سان، خاص طور تي تعلقي ٽيڪنالاجيز سان، او او پي جي تعريف جي کوٽ جي ڪري مشڪل آهي، جيڪا سخت ۽ وڏي پيماني تي قبول ٿيل آهي (ڪرسٽوفر جي. تاريخ)

ٻين ٻولين جي مقابلي ۾ (LISP ٻوليون، فعلي ٻوليون، وغيره)، OOP ٻولين جو ڪو منفرد فائدو نه آھي ۽ غير ضروري پيچيدگي کي لاڳو ڪن ٿا. (لارنس ڪربنر)

مون کي نظر اچي ٿو اعتراض تي مبني پروگرامنگ ٽيڪنيڪل طور تي ڪمزور. اهو دنيا کي انٽرفيس جي لحاظ کان حصن ۾ ورهائڻ جي ڪوشش ڪري ٿو جيڪي هڪ ئي قسم جي اندر مختلف آهن. حقيقي مسئلن کي منهن ڏيڻ لاءِ، توهان کي ضرورت آهي گھڻائي ترتيب ڏنل الجبرا - انٽرفيس جا خاندان جيڪي ڪيترن ئي قسمن ۾ پکڙيل آهن. مان سمجهان ٿو اعتراض تي مبني پروگرامنگ فلسفيانه طور تي غير صحتمند. اهو ٻڌائي ٿو ته هر شيء هڪ اعتراض آهي. جيتوڻيڪ اهو سچ آهي، اهو تمام دلچسپ ناهي: اهو چوڻ آهي ته هر شيء هڪ اعتراض آهي، ڪجهه به نه چوڻ آهي. (اليگزينڊر اسٽيپانوف)

وڏين ڪمپنين جي وچ ۾ OOP جي مقبوليت "وڏي (۽ اڪثر تبديل ٿيندڙ) وچولي پروگرامرن جي گروپن جي ڪري آهي." او او پي پاران لاڳو ڪيل نظم پروگرامر کي ”تمام گهڻو نقصان“ ڪرڻ کان روڪي ٿو. (پال گراهم)

آبجیکٹ تي مبني پروگرامنگ اسم کي پهرين ۽ سڀ کان اول رکي ٿو. اهڙن انتهائي قدمن تي وڃي تقرير جو هڪ حصو پيادل تي ڇو رکجي؟ ڇو هڪ تصور ٻئي تي ترجيح وٺندي آهي؟ اهو ناممڪن آهي OOP لاءِ اوچتو فعل کي اسان جي سوچ لاءِ گهٽ اهميت ڏيڻ. هي هڪ عجيب و غريب نقطه نظر آهي. (اسٽيو يگ)

رِڪ هِڪي، ڪلوجور جو خالق، آبجیکٹ سسٽم کي حقيقي دنيا جا انتهائي آسان ماڊل قرار ڏنو. هن زور ڏنو ته او او پي جي نااهليءَ تي وقت کي صحيح نموني سان ترتيب ڏئي سگهجي ٿو، جيڪو پروگرامن ۾ ملٽي ٿريڊنگ عام ٿيڻ تي تمام وڏا مسئلا پيدا ڪري ٿو. ايريڪ ايس ريمنڊ، هڪ يونڪس پروگرامر ۽ اوپن سورس سافٽ ويئر وڪيل، دعويٰ تي تنقيد ڪئي آهي ته او او پي ”دي ون حل“ آهي ۽ لکيو آهي ته او او پي ملٽي ليئر پروگرامن جي حوصلا افزائي ڪري ٿي، جيڪي شفافيت کي روڪين ٿيون. هڪ مخالف نقطه نظر جي طور تي، ريمنڊ يونڪس ۽ سي جو مثال ڏنو.

لنڪس

Margaret Rouse @ WhatIs.com پاران وڪيپيڊيا! ( روسي ورزن ) وراثت پوليمورفيزم آهي SOLID (Object Oriented Design) ( Russian version ) Single Responsibility PrincipleArguments against OOPS ( Russian version ) OOPS ڇا آهي (بغير هائپ) ترجمو: Varygin D.V.