الاستخدامات العملية لـ OOP

Question

لقد أجريت مؤخرًا نقاشًا مع زميل ليس من المعجبين به OOP. ما لفت انتباهي هو ما قاله:

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

نحن في شركة صغيرة تقوم بتطوير مشاريع صغيرة لمواقع التجارة الإلكترونية والعقارات.

كيف يمكنني الاستفادة من OOP في الإعداد "اليومي ، العالم الحقيقي"؟ أم أن OOP كان من المفترض حقًا حل المشكلات المعقدة وليس المقصود للتطور "اليومي"؟

Answer 1

الأشياء الجيدة حول OOP تأتي من ربط مجموعة من البيانات إلى مجموعة من السلوكيات.

لذلك ، إذا كنت بحاجة إلى القيام بالعديد من العمليات ذات الصلة على مجموعة من البيانات ذات الصلة ، فيمكنك كتابة العديد من الوظائف التي تعمل على البنية ، أو يمكنك استخدام كائن.

تعطيك الكائنات بعض مساعدة إعادة استخدام التعليمات البرمجية في شكل الميراث.

IME ، من الأسهل العمل مع كائن مع مجموعة معروفة من السمات والأساليب التي تتمثل في الحفاظ على مجموعة من الهياكل المعقدة والوظائف التي تعمل عليها.

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

هل يجب أن تستخدم OOP في مشاريعك؟ هذا يعتمد على مدى دعم لغتك OOP. هذا يعتمد على أنواع المشاكل التي تحتاج إلى حلها.

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

Answer 2

رأيي شخصيا: السياق

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

Answer 3

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

Answer 4

حسنًا ، أنا متأكد من أن الكثير من الناس سوف يقدمون الكثير من الإجابات الأكاديمية بشكل صحيح ، ولكن إليك ما يقلني في بعض المزايا الأكثر قيمة:

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

Answer 5

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

أمثلة قليلة:

• من الصعب تنفيذ دفق (نمط الديكور) بدون أشياء

• يمكن أن تكون إضافة عملية جديدة إلى نظام حالي مثل نوع التشفير الجديد (نمط الإستراتيجية) أمرًا صعبًا بدون كائنات.

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

والقائمة تطول.

Answer 6

قوة معظم لغات البرمجة هي في التجريدات التي توفرها. توفر البرمجة الموجهة للكائنات نظامًا قويًا للغاية من التجريد بالطريقة التي تتيح لك إدارة العلاقات بين الأفكار أو الإجراءات ذات الصلة.

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

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

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

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

Answer 7

جميع نماذج البرمجة لها نفس الهدف: إخفاء التعقيد غير الضروري.

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

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

يبدو أن زميلك عالق في نموذج واحد. حظا طيبا وفقك الله.

Answer 8

حوالي عام 1994 كنت أحاول فهم OOP و C ++ في نفس الوقت ، ووجدت نفسي محبطًا ، على الرغم من أنني أستطيع أن أفهم من حيث المبدأ ما هي قيمة OOP. كنت معتادًا على أن أتمكن من العبث مع حالة أي جزء من التطبيق من اللغات الأخرى (معظمها أساسية ، ولغات الأسرة ، والباسكال) لدرجة أني بدا وكأنني كنت أتخلى عن الإنتاجية لصالح بعض التجريد الأكاديمي. لسوء الحظ ، فإن مواجهاتي القليلة الأولى مع أطر عمل OO مثل MFC جعلت من السهل اختراقها ، ولكنها لم توفر بالضرورة الكثير في طريق التنوير.

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

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

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

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

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

Answer 9

بالنسبة لي ، فإن قوة OOP لا تظهر نفسها حتى تبدأ في الحديث عن الميراث وتعدد الأشكال.

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

ومع ذلك ، فإن الميزة الحقيقية تأتي عندما كتبت رمزًا في التسلسل الهرمي العام بحيث يمكن إعادة استخدامه لاحقًا بحيث يتم استخدام نفس واجهات الكود الدقيق لوظائف مختلفة لتحقيق نفس النتيجة.

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

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

Answer 10

اطلب من صديقك أن يتصور أي الكائن في غرفته أو منزله أو مدينته ... وإذا كان بإمكانه إخبار كائن واحد من هذا القبيل نظام في حد ذاته وقادر على القيام ببعض الأعمال ذات المغزى.

أشياء مثل الزر لا تفعل شيئًا بمفرده - يتطلب الأمر الكثير من الكائنات لإجراء مكالمة هاتفية.
وبالمثل ، يتكون محرك السيارة من رمح الكرنك ، المكابس ، شمعات الإشعال. تطورت مفاهيم عفوا من تصورنا في العمليات الطبيعية أو الأشياء في حياتنا.

يروي كتاب "Inside Com" الغرض من COM من خلال أخذ القياس من لعبة الطفولة لتحديد الحيوانات عن طريق طرح الأسئلة.

Answer 11

التصميم يتفوق على التكنولوجيا والمنهجية. تميل التصميمات الجيدة إلى دمج مديري إدارة التعقيد العالمي مثل قانون ديميتر الذي يقع في صميم ما تعرضه لغة OO التي تسعى إلى تدوينها.

لا يعتمد التصميم الجيد على استخدام ميزات اللغة المحددة لـ OO على الرغم من أنه عادة ما يكون من المصالح الفضلى استخدامها.

Answer 12

لا يصنع فقط

• البرمجة أسهل / أكثر قابلية للصيانة في الوضع الحالي للأشخاص الآخرين (ونفسك)
• إنه يسمح بالفعل بسهولة عمليات قاعدة البيانات (إنشاء ، تحديث ، حذف).

يمكنك العثور على مزيد من المعلومات حول البحث عن: - Java: Hibernate - Dot Net: Entity Framework

انظر حتى كيف يمكن لـ LINQ (Visual Studio) أن يجعل حياة البرمجة أسهل بكثير.

• أيضًا ، يمكنك البدء في استخدام أنماط التصميم لحل مشاكل الحياة الحقيقية (أنماط التصميم تدور حول OO)

ربما يكون من الممتع التظاهر مع القليل من العرض التوضيحي:

• لنفترض أنك بحاجة إلى تخزين الموظفين والحسابات والأعضاء والكتب في ملف نصي بطريقة مماثلة.

.ملاحظة. حاولت كتابتها بطريقة زائفة :)

طريقة OO

الكود الذي تتصل به: io.file.save (ObjectScollection.ourfunctionForsaving ())

كائن فئة

تعمل

سلسلة _objects

   for each _Object in objectsCollection
         Objects &= _Object & "-"
   end for

إرجاع _Objects طريقة النهاية

طريقة غيرو

لا أعتقد أنني سأكتب رمزًا غير UO. لكن فكر في الأمر :)

الآن دعنا نقول

بطريقة oo. الفئة أعلاه هي فئة الوالدين لجميع الطرق لإنقاذ الكتب ، الموظفين ، الأعضاء ، الحسابات ، ... ماذا يحدث إذا أردنا تغيير طريقة الادخار إلى Textfile؟ على سبيل المثال ، لجعلها قابلة للضغط مع المعيار الحالي (.cvs).

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

دع زميلك يفكر في ذلك :)

Answer 13

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

هذا لأن ال جوهر يعتمد التوجه الكائن على حقيقة أنه ، من الناحية التنظيمية ، لا يبرز بين الحالة والسلوك على الإطلاق ، ويتعامل بشكل موحد على أنه "ميزات". الكائنات هي مجرد مجموعات من الميزات التي تم تفكيكها لتقليلها إجمالي الاعتماد.

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