البرمجة الشيئية (ترجمة المقال)

من المترجم: للأسف، ليس لدي أي خبرة كبيرة في الترجمة من الإنجليزية، على الرغم من أنني أقرأ كثيرًا باللغة الإنجليزية. ولكن اتضح أن القراءة والترجمة شيئان مختلفان. ولسوء الحظ أيضًا، ليس لدي خبرة كبيرة في البرمجة (لقد قمت مؤخرًا بإنشاء تطبيق ويب بسيط في Spring MVC وHibernate). لذلك، كانت الترجمة أسوأ بكثير مما كان يمكن أن تكون عليه. لقد سمحت لنفسي بتصحيح أمثلة التعليمات البرمجية الواردة في المقالة قليلاً، نظرًا لأنها لا تتوافق مع اصطلاحات التسمية في Java. ربما لم يكن الأمر يستحق ترجمة أسماء بعض الأنماط (مثل هذه الترجمة لا توفر الكثير من الفهم)، لكنني اعتقدت أن هذا كان أهون الشرين. ومن الجدير بالذكر بشكل منفصل عن "التماسك العالي" كترجمة لـ "التماسك العالي". أتفق معك، ليست أفضل ترجمة. ولكن "الاتصال القوي" هو "الاقتران العالي" (مفهوم مهم آخر)، ومن غير المرجح أن يكون "التماسك" مناسبا هنا. أنا منفتح على النقد وسأقبل بامتنان التعليقات على المقال بأي شكل من الأشكال. البرمجة الموجهة للكائنات هي نمط من البرمجة يتكون فيها البرنامج من مكونات تتوافق مع كائنات العالم الحقيقي، أي كائن حقيقي له بعض الخصائص (التي قد تتغير أو لا تتغير مع مرور الوقت) والسلوك (الذي قد أو لا يتغير) يتغير حسب الآخرين).الظروف). على سبيل المثال، قلم الرصاص هو كائن حقيقي له الخصائص التالية:

• إنه أحمر (وهذا لا يتغير مع مرور الوقت).
• يبلغ طوله الآن 10 سنتيمترات (قد يتغير هذا إذا تم شحذ قلم الرصاص).

ولها السلوك التالي:

• يترك علامة إذا تم استخدامه بشكل صحيح.
• قد يختلف التتبع حسب الضغط (حسب العوامل الخارجية).
• يقصر طوله كلما شحذ (سلوك دائم).

كما في هذا المثال، يمكن أن تحتوي كائنات العالم الحقيقي على العديد من الخصائص، ولكن عند كتابة البرامج فإننا نأخذ في الاعتبار الخصائص الضرورية فقط. البرمجة الشيئية لها مزاياها. على سبيل المثال، فإنه يسهل إنشاء اتصال بين كائن في العالم الحقيقي وبرنامج بالطريقة المتوقعة. يساعد هذا حقًا مع نمو التطبيق وتفاعل العديد من الكائنات مع بعضها البعض. ويساعد ذلك في توزيع المسؤوليات داخل العالم الموضوعي، مما يسمح لك بالتركيز على التفكير من خلال التطبيق. ميزة أخرى مهمة مرتبطة بـ OOP (البرمجة الشيئية) هي تصنيف الكائنات. بما أن العالم (الحقيقي/الافتراضي) مليء بالأشياء، فمن الصعب التحكم فيها بشكل فردي. نحن بحاجة إلى طريقة لتصنيف هذه الكائنات من شأنها أن تساعدنا على ربط الأشياء المختلفة وخصائصها، مثل قلم الرصاص الأسود. سيكون من الصعب تمييزه (نفسه؟) إذا تم استخدامه في المثال السابق، ولكنه كائن مختلف. ولكن بما أنهما قلمان رصاص، فإنهما ينتميان إلى نفس فئة "قلم الرصاص". في حين أن القلم، الذي يشبه إلى حد كبير قلم الرصاص، ينتمي إلى فئة مختلفة. ومع ذلك، فإن القلم والقلم الرصاص كلاهما "أدوات للكتابة". تعتمد البرمجة الشيئية على المبادئ التالية:

التجريد

يتم تعريف التجريد على أنه نوعية التفاعل مع الأفكار وليس الأحداث ، أو بمعنى آخر، التحرر من الصفات التمثيلية . وهذا يسمح للمبرمجين بالتركيز على ما يجب برمجته بدلاً من التركيز على كيفية البرمجة . يمكن اعتبار التجريد بمثابة عقد نقدم من خلاله الوظيفة. قد تكون تفاصيل التنفيذ مخفية عند استخدام هذا المفهوم. على سبيل المثال، إذا كنا بحاجة إلى فصل دراسي يكتب، فيجب علينا التأكد من أن لديه طريقة "كتابة". abstract class writer { write (); } ماذا فعلنا؟ لقد قمنا بتصميم فئة عالية المستوى تكون مجردة، وبعبارة أخرى، فهي تعرف الوظائف التي نحتاجها، ولكن كيفية تنفيذها خارج نطاق هذه الفئة. وهذا يوفر العديد من الفوائد:

• نحن نكشف عن الحد الأدنى من المعلومات اللازمة للجهات الخارجية، وهذا يسمح لنا بالتركيز على التفكير من خلال البرنامج (وهذا يتيح التفكير المركّز)، وتجنب الارتباك وتجنب تقديم وعود غير مقصودة.
• نترك مجالًا للتحسينات المستقبلية التي لن تكون ممكنة إذا تم الكشف عن تفاصيل التنفيذ.

ميراث

تعني كلمة "الميراث" في اللغة الإنجليزية الشائعة "الاكتساب والتوريث". هذه الكلمة موجودة في ثقافتنا لفترة طويلة جدًا. لقد حصل الأجداد على الأرض بالعمل الجاد ونقلوها إلى أبنائهم، حتى الطبيعة تفضل الميراث. جميع خصائص الجسم، مثل الطول ولون البشرة/العين/الشعر، إلخ. تعتمد على الجينات التي ورثناها من آبائنا. الميراث يمنع إعادة اختراع العجلة ويسرع التقدم. إنه نفس الشيء في OOP. نقوم بإنشاء فئة رئيسية تحتوي على بعض الخصائص/السلوكيات الأساسية. ستحتوي جميع الفئات الموروثة من هذا الوالد على نفس الخصائص/السلوك الذي يتمتع به الوالد. ومع ذلك، قد تكتسب الفئات الموروثة المزيد من الخصائص/السلوك أو تغير تنفيذ السلوك. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } في المثال أعلاه، تحتوي الفئة الأصلية (WritingInstrument) على خاصية "اللون" وسلوك "الكتابة". عندما يتم الإعلان عن الفئة التابعة (المقبض)، لا يلزم الإعلان عن خاصية "اللون" وسلوك "الكتابة" مرة أخرى. إنهم موجودون في فئة "المقبض" بسبب الميراث. ومع ذلك، يمكن للفئة التابعة أن تعلن عن خصائصها/سلوكها الإضافي. كيف يمكننا استخدام هذا في الممارسة العملية؟ نحن المطورين كسالى للغاية. لا نريد طباعة شيء ما مرارًا وتكرارًا. لا يُنصح بوجود نسخ متعددة من نفس الكود نظرًا للاعتبارات التالية:

• كلما قل عدد نسخ التعليمات البرمجية، أصبح من الأسهل صيانتها.
• إذا لم يكن هناك العديد من نسخ التعليمات البرمجية، يصبح التغيير في مكان واحد مرئيا في كل مكان.
• كلما قل الرمز، قلت الأخطاء.
• إذا تم استخدام رمز واحد في العديد من الأماكن، يتم تحقيق التعميم.
• نحن نركز على كتابة التعليمات البرمجية.
• نحن نركز على الاختبارات.

يتم تحقيق الوراثة في Java باستخدام الكلمتين الأساسيتين "يمتد" و"ينفذ". 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، والذي يتم توسيعه/تجاوزه بواسطة الفئتين التابعتين pen وpen. يتم استدعاء طريقة الكتابة () ثلاث مرات في الفئة الرئيسية. في كل مرة يتم استدعاء تنفيذ مختلف اعتمادًا على الكائن الذي يتم استدعاء الطريقة عليه. في هذه الحالة، يكون للأسلوب write() العديد من أنواع السلوك لأنه متعدد الأشكال.

التغليف

يتم تعريف التغليف على أنه جمع البيانات/الوظائف ذات الصلة في وحدة واحدة. وهذا يساعد في تسهيل الوصول إلى البيانات/تعديلها. على سبيل المثال، إذا كنا بحاجة إلى طباعة جميع الخصائص التي يمتلكها مستخدم معين، فلدينا الخيارات التالية: لقد printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) أنشأنا طريقة تأخذ جميع الخصائص وتطبعها واحدة تلو الأخرى. مع زيادة عدد العناصر في القائمة، لن يكون من الممكن تحديد الحقول الصحيحة، وستؤدي إضافة/إزالة حقل واحد إلى تغيير توقيع الطريقة. لذلك، نحتاج إلى استبدال جميع مستخدمي هذه الطريقة، حتى لو لم يكونوا بحاجة إلى الحقول المضافة مؤخرًا. لجعل التعليمات البرمجية أكثر قابلية للقراءة وتسهيل التعديلات المستقبلية، نقوم بتغليف الخصائص في فئة وتحويلها إلى كائن جماعي.الكائن class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} عبارة عن حزمة برامج من المتغيرات والأساليب المرتبطة بها. يمكنك تمثيل كائنات العالم الحقيقي باستخدام كائنات البرنامج. يمكنك أن تتخيل كلابًا حقيقية في برنامج رسوم متحركة، أو دراجة حقيقية ككائن برمجي داخل دراجة تمرين. في OOP، الفصل عبارة عن قالب قابل للتوسيع (قالب كود البرنامج) لإنشاء الكائنات وتزويدها بالحالة الأولية (المتغيرات) وتنفيذ السلوك (الوظائف والأساليب). لقد صاغ مايكل فيذر الاختصار SOLID لـ "المبادئ الخمسة الأولى" التي أطلق عليها روبرت سي مارتن في أوائل العقد الأول من القرن الحادي والعشرين. الهدف من هذه المبادئ، عند تنفيذها معًا، هو زيادة احتمال قيام المبرمج بإنشاء نظام يسهل صيانته وتوسيعه. مبادئ SOLID هي مبادئ توجيهية في تطوير البرامج ضرورية لإزالة التعليمات البرمجية "الفاسدة" من خلال إعادة البناء، ونتيجة لذلك يجب أن تصبح التعليمات البرمجية قابلة للقراءة بسهولة وقابلة للتوسيع. وهذا جزء من استراتيجية البرمجة الرشيقة والقابلة للتكيف.

مبدأ المسؤولية الفردية

في OOP، ينص مبدأ المسؤولية الفردية على أن كل فئة يجب أن تكون مسؤولة عن جزء واحد من الوظيفة التي يوفرها البرنامج، ويجب أن تكون هذه المسؤولية مغلفة بالكامل بواسطة تلك الفئة. يجب أن تكون جميع وظائفها مرتبطة ارتباطًا وثيقًا بهذه المسؤولية.

مبدأ مفتوح/مغلق

في OOP، ينص مبدأ مفتوح/مغلق على أن "الكيانات البرمجية (الفئات، الوحدات، الأساليب، وما إلى ذلك) يجب أن تكون مفتوحة للامتداد ولكنها مغلقة أمام التغيير". بمعنى آخر، يجب على الكيان أن يسمح بتوسيع سلوكه دون تغيير كود المصدر.

مبدأ استبدال ليسكوف

الاستبدال هو مبدأ في OOP. تنص على أنه إذا كان S في برنامج كمبيوتر هو نوع فرعي من T، فيجب أن تكون الكائنات من النوع T بحيث يمكن استبدالها بكائنات من النوع S (أي يمكن استبدال كائنات من النوع S بكائنات من النوع T) دون تغيير أي خصائص مطلوبة للبرامج (الدقة، إنجاز المهام، إلخ).

مبدأ فصل الواجهة

ينص مبدأ فصل الواجهة على أنه لا ينبغي إجبار مبرمج العميل على الاعتماد على أساليب لا يستخدمها. وفقًا لهذا المبدأ، من الضروري تقسيم الواجهات الكبيرة إلى واجهات أصغر وأكثر تحديدًا حتى يعرف مبرمج العميل فقط الطرق التي تهمه. الغرض من مبدأ فصل الواجهة هو الحفاظ على فصل النظام، مما يسهل إعادة البناء وإجراء التغييرات وإعادة النشر.

مبدأ انعكاس التبعية

في OOP، يعني مبدأ انعكاس التبعية شكلاً محددًا من الانفصال بين وحدات البرنامج. باتباع هذا المبدأ، يتم عكس (عكس) علاقات التبعية القياسية التي تم إنشاؤها من الوحدات عالية المستوى التي تشكل بنية التطبيق (وضع السياسة) إلى الوحدات منخفضة المستوى التابعة، بحيث تصبح الوحدات عالية المستوى المعدلة مستقلة عن تفاصيل تنفيذ وحدات منخفضة المستوى. ينص هذا المبدأ على:

• لا ينبغي أن تعتمد الوحدات عالية المستوى على الوحدات ذات المستوى المنخفض. يجب أن يعتمد كلا النوعين من الوحدات على التجريدات.
• لا ينبغي أن تعتمد التجريدات على تفاصيل التنفيذ. التفاصيل يجب أن تعتمد على التجريدات.

يعكس هذا المبدأ الطريقة التي يمكن للناس أن يفكروا بها في التصميم الموجه للكائنات من خلال الإشارة إلى أن الكائنات ذات المستوى العالي والمنخفض يجب أن تعتمد على نفس التجريدات.

فهم المبادئ

توفر أنماط برامج تعيين المسؤولية العامة (GRASP) إرشادات لتعيين المسؤوليات للفئات والكائنات في التصميم الموجه للكائنات.

مراقب

يقوم نمط وحدة التحكم بتعيين مسؤولية التفاعل مع أحداث النظام إلى فئات غير واجهة المستخدم الرسومية التي تمثل النظام بأكمله أو سيناريو حالة الاستخدام. مراقب:

• هذا كائن لا يتفاعل مباشرة مع المستخدم وهو مسؤول عن تلقي أحداث النظام والاستجابة لها.
• يجب استخدامه للتعامل مع كافة أحداث النظام لحالة استخدام واحدة (أو عدة حالات مترابطة).
• إنه الكائن الأول خلف واجهة المستخدم الرسومية الذي يتحكم في عمليات النظام.
• ليس عليه أن يقوم بالعمل بنفسه، فمهمته هي التحكم في تدفق الأحداث.

المنشئ

تتمثل مهمة فئة المنشئ في إنشاء الكائنات وبدء تشغيلها لاستخدامها لاحقًا. فهو يعرف معلمات التهيئة، بالإضافة إلى الكائن الذي سيتم إنشاؤه. في بعض الأحيان، تقوم فئة المنشئ بإنشاء كائنات بشكل نشط ووضعها في ذاكرة التخزين المؤقت، وتوفر مثيلًا واحدًا عند الحاجة إليها.

تماسك عالي

التماسك العالي هو نمط تقييمي، والغرض منه هو الحفاظ على الأشياء في مثل هذه الحالة التي تهدف إلى أداء مهمة واحدة واضحة، ويمكن التحكم فيها وفهمها بسهولة. عادةً ما يتم استخدام الاقتران العالي لدعم الاقتران المنخفض. ويعني التماسك العالي أن مسؤوليات عنصر معين محددة بوضوح (مرتبطة بقوة ومركزة للغاية). يعد تقسيم البرنامج إلى فئات وأنظمة فرعية مثالاً على الإجراءات التي تزيد من تماسك خصائص النظام. ومن ناحية أخرى، فإن الاقتران السائب هو الموقف الذي يكون فيه للعنصر الكثير من المهام غير ذات الصلة. تميل العناصر المترابطة بشكل فضفاض إلى أن تكون صعبة الفهم، وقابلة لإعادة الاستخدام، وصعبة الصيانة، ويصعب تغييرها.

المراوغة

يحافظ نمط الدوار على اقتران فضفاض (وقابلية إعادة الاستخدام) بين عنصرين من خلال إسناد مسؤولية التفاعل بينهما إلى كائن وسيط. ومن الأمثلة على ذلك إدخال وحدة تحكم للتوسط بين البيانات (النموذج) وعرضها (العرض) في نمط Model-View-Controller (MVC).

خبير المعلومات

خبير المعلومات (أيضًا خبير أو مبدأ الخبراء) هو مبدأ يستخدم لتحديد من يجب تفويض المسؤولية إليه. تشمل المسؤوليات الأساليب والحقول المحسوبة وما إلى ذلك. عند استخدام هذا المبدأ عند إسناد المسؤولية، فإن النهج الرئيسي هو التسلسل التالي من الإجراءات: تحليل المسؤولية، وتحديد المعلومات اللازمة للوفاء بها، وأخيرًا تحديد مكان وجود هذه المعلومات. يؤدي استخدام مبدأ خبير المعلومات إلى إسناد المسؤولية إلى الفصل الذي لديه أكبر قدر من المعلومات لتنفيذه.

اقتران منخفض

الاقتران غير المحكم هو نمط تقييم يحدد كيفية تعيين المسؤوليات: الاقتران غير المحكم بين الفئات، وتغيير أحدهما يجب أن يكون له تأثير ضئيل على الآخر، مما يزيد من إمكانية إعادة الاستخدام.

تعدد الأشكال

وفقًا لتعدد الأشكال، يتم تعيين تنوع السلوك بناءً على النوع إلى الأنواع التي يحدث لها هذا الاختلاف. يتم تحقيق ذلك باستخدام عمليات متعددة الأشكال.

الاختلافات المحمية

يحمي نمط التغييرات المحمية العناصر من التغييرات التي تطرأ على العناصر الأخرى (الكائنات والأنظمة والأنظمة الفرعية) عن طريق تغليف تركيز عدم الاستقرار في الواجهة واستخدام تعدد الأشكال لإنشاء تطبيقات مختلفة لتلك الواجهة.

تصنيع نقي

يتضمن البناء الخالص فئة لا تمثل مفهومًا في مجال المشكلة، وهي مصممة خصيصًا لتحقيق اقتران فضفاض، واقتران عالي، وبالتالي أقصى إمكانية لإعادة الاستخدام (الحل الذي يقدمه نمط خبير المعلومات لا يحقق ذلك). يُطلق على هذه الفئة عادةً اسم "الخدمة" في التصميم المستند إلى المجال.

نقد

أظهرت الأبحاث التي أجراها بوتوك وآخرون عدم وجود فروق ذات دلالة إحصائية بين OOP والنهج الإجرائي.

من الصعب إجراء مقارنة نقدية لـ OOP مع التقنيات الأخرى، وخاصة التقنيات العلائقية، بسبب عدم وجود تعريف صارم ومقبول على نطاق واسع لـ OOP (كريستوفر ج. ديت)

بالمقارنة مع اللغات الأخرى (لهجات LISP، اللغات الوظيفية، وما إلى ذلك)، لا تتمتع لغات OOP بميزة فريدة وتفرض تعقيدًا غير ضروري. (لورنس كروبنر)

أجد البرمجة الشيئية واهية من الناحية الفنية. يحاول تفكيك العالم إلى أجزاء من حيث الواجهات التي تختلف ضمن النوع الواحد. للتعامل مع المشاكل الحقيقية، تحتاج إلى جبر متعدد الفرز - عائلات من الواجهات التي تمتد عبر العديد من الأنواع. أجد البرمجة الموجهة للكائنات غير صحية فلسفيا. تنص على أن كل شيء هو كائن. حتى لو كان هذا صحيحًا، فهو ليس مثيرًا للاهتمام: فالقول بأن كل شيء هو شيء يعني عدم قول أي شيء على الإطلاق. (الكسندر ستيبانوف)

ترجع شعبية OOP بين الشركات الكبيرة إلى "مجموعات كبيرة (ومتغيرة بشكل متكرر) من المبرمجين المتوسطين." الانضباط الذي يفرضه OOP يمنع المبرمج من إلحاق "الكثير من الضرر". (بول جراهام)

البرمجة الشيئية تضع الأسماء في المقام الأول. لماذا نذهب إلى مثل هذه التدابير المتطرفة ونضع جزءًا واحدًا من الكلام على قاعدة التمثال؟ لماذا يكون لمفهوم ما الأسبقية على الآخر؟ من المستحيل على OOP أن يجعل الأفعال فجأة أقل أهمية لتفكيرنا. وهذا منظور منحرف بشكل غريب. (ستيف ييج)

وصف ريك هيكي، مبتكر Clojure، أنظمة الكائنات بأنها نماذج مبسطة للغاية للعالم الحقيقي. وشدد على عدم قدرة OOP على نمذجة الوقت بشكل صحيح، مما يخلق مشاكل كبيرة عندما يصبح تعدد الخيوط شائعًا في البرامج. إريك س. ريموند، مبرمج يونكس ومناصر للبرمجيات مفتوحة المصدر، انتقد الادعاء بأن OOP هو "الحل الوحيد" وكتب أن OOP يشجع البرامج متعددة الطبقات، مما يعيق الشفافية. وفي الاتجاه المعاكس، أعطى ريموند مثال Unix وC.

روابط

بقلم مارجريت روس @ WhatIs.com ويكيبيديا! ( النسخة الروسية ) الميراث هو تعدد الأشكال SOLID (التصميم الموجه للكائنات) ( النسخة الروسية ) مبدأ المسؤولية الفردية الحجج ضد OOPS ( النسخة الروسية ) ما هو OOPS (بدون الضجيج) الترجمة: Varygin D.V.