هل يؤدي النموذج الفردي OOP إلى انعكاس التجريد؟

Question

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

في رأيك، هل البرمجة في لغة OOP ذات نموذج واحد حيث يجب أن يكون كل شيء جزءًا من فئة ولا يتم الكشف عن أشياء مثل المؤشرات، مثل Java أو C#، تؤدي حتمًا إلى انعكاس التجريد؟إذا كان الأمر كذلك، في أي الحالات؟

Answer 1

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

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

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

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

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

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

Answer 2

والمبرمجين الحقيقي يمكن أن يكتب FORTRAN في أي لغة

وبعبارة أخرى، فإنه ليس من اللغة، هو مبرمج

Answer 3

وجافا وC # لديهم أساليب ثابتة التي تعادل الوظائف، وبالتالي فإن اللغة لا يجبر أي شيء عليك.

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

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

Answer 4

لا أعتقد أ لغة مثل Java أو C# تعاني من هذا بأي طريقة ملموسة، وذلك ببساطة لأن المكتبات المصاحبة لإطار العمل غنية جدًا لدرجة أن الحاجة إلى اقتحام نموذج آخر ليست مطلوبة حقًا للبرمجة العامة.

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

وأيضًا نظرًا لأن .Net Framework / Java Runtime يسمحان بالتفاعل مع اللغات الأخرى الموجودة فوق وقت التشغيل المشترك، فإن القدرة على استهداف نماذج أخرى (مثل البرمجة الوظيفية واللغات الديناميكية وما إلى ذلك) يمكن أن توفر أيضًا طريقًا آخر للابتعاد عن النموذج الفردي قيود.