حان الوقت للابتعاد عن OOP
يعتبر OOP أكبر ماسة في تاج علوم الكمبيوتر. أفضل طريقة لتنظيم التعليمات البرمجية الخاصة بك. الحل لجميع المشاكل. الطريقة الوحيدة المؤكدة لكتابة برامجنا. أرسلنا إله البرمجة من أعلى ... الآن فقط يضطر مبرمج OOP إلى جمع مجموعة من جميع أنواع التجريد ، وتتبع جميع الكائنات المشتركة ، وتذكر الكثير من "أنماط البرمجة" - وقضاء وقتهم وطاقتهم في كل هذا بدلاً من حل المشكلة نفسها.
لقد انتقد العديد منذ فترة طويلة OOP ، وهناك العديد من المبرمجين المحترمين بين هؤلاء النقاد. وحتى آلان كاي - مخترع OOP في صفوفهم!
الهدف الرئيسي لأي مطور هو كتابة كود موثوق. إذا كان الرمز يحتوي على أخطاء برمجية ولا يعمل بالشكل المطلوب ، فلا شيء آخر مهم. ما هي أفضل طريقة لكتابة كود موثوق؟ حافظ على بساطة الكود. البساطة هي عكس التعقيد . ويترتب على ذلك أن الهدف الأساسي للمطور هو تقليل تعقيد الكود.
إخلاء المسؤولية:
لست من محبي OOP ، لذلك ليس من المستغرب أن يبدو هذا المقال متحيزًا للكثيرين. ومع ذلك ، سأقدم الحجج للدفاع عن موقفي.
أفهم جيدًا أيضًا أن انتقاد OOP مؤلم جدًا للكثيرين. الكثير من القراء سيشعرون بالإهانة شخصيًا. ومع ذلك ، أعتزم أن أصرح بما أعتقد أنه صحيح. لأن هدفي ليس الإساءة ، ولكن للإشارة إلى المشاكل التي يعاني منها OOP. أنا لا أنتقد آلان كاي
الصورة OOP . إنه عبقري بشكل عام. أنا شخصياً أتمنى أن يكون OOP هو بالضبط ما قصده آلان كاي. ما أنتقده هو OOP في تطبيق C # أو Java.
تكمن المشكلة في أن OOP لطالما اعتبرت المعيار لتنظيم كود البرنامج. ويعتقد الكثير من الناس ، بما في ذلك أولئك الذين يشغلون مناصب جادة في صناعة البرمجيات ، وهذا هو السبب في عدم مراعاة الأساليب الأخرى للبرمجة في معظم الشركات.
اضطررت للتغلب على الكثير من الصعوبات عندما كتبت بلغات OOP. وقد تساءلت دائمًا عن سبب ظهور هذه الصعوبات. ربما لم أكن جيدًا جدًا؟ ربما كنت بحاجة إلى تعلم بضع عشرات من "أنماط البرمجة"؟ في النهاية ، لم يكن لدي القوة المتبقية لكل هذا.
ستخبرك هذه المقالة برحلة العقد الطويلة التي قطعتها من OOP إلى البرمجة الوظيفية. منذ ذلك الحين ، لا أتذكر حالة صادفت فيها مشروعًا سيكون OOP الأنسب له. علاوة على ذلك ، فإن المشاريع التي تم فيها استخدام OOP سقطت تحت وطأة تعقيد الكود - من نقطة ما كان من المستحيل الحفاظ عليها وتطويرها.
TLDR
"البرامج الموجهة للكائنات هي البديل عن البرامج الصحيحة."
Edsger W. Dijkstra ، رائد علوم الكمبيوتر
كان الغرض من OOP واحدًا - للتعامل مع تعقيد التعليمات البرمجية الإجرائية. بمعنى آخر ، تم تصميم OOP لتحسين تنظيم الكود. ولكن منذ ذلك الحين لم يكن هناك دليل على أن OOP أفضل من البرمجة الإجرائية القديمة.
الحقيقة القاسية هي أن OOP لم تفعل الشيء الوحيد الذي صممت من أجله. كل شيء بدا رائعًا على الورق - كان لدينا تسلسل هرمي صارم للحيوانات والكلاب والناس ... (وبالطبع ، الأشكال: المستطيلات والمربعات والدوائر - أين يمكننا الذهاب بدونها!) ولكن مع زيادة تعقيد كود التطبيق ، لم يساعد OOP في تقليله ، ولكن على العكس من ذلك ، زادت - مع وجود الكثير من "أنماط البرمجة" الضرورية مما يجعل من الصعب على المبرمج تتبع مكان وكيفية تغير قيم المتغيرات. قام OOP بالعديد من الإجراءات الشائعة الاستخدام ، مثل إعادة البناء والاختبار ، معقدة بشكل غير ضروري.
يختلف معي الكثير من الناس ، لكن الحقيقة هي أن تصميم OOP في C # أو Java لم يتم التفكير فيه علميًا ، ولم يكن نتيجة بحث علمي جاد. على عكس البرمجة الوظيفية ، على سبيل المثال ، في هاسكل ، حيث يعتبر حساب لامدا أساسًا نظريًا صلبًا. OOP لا يعتمد على أي شيء من هذا القبيل.
في المشاريع الصغيرة ، يعمل OOP جيدًا. لكن ماذا يحدث عندما ينمو المشروع؟ OOP هي قنبلة موقوتة ستنفجر حتماً عندما يصل كود المشروع إلى حجم معين. تبدأ المشاريع في التأخر ، وتفشل المواعيد النهائية ، ونفاد طاقة المطورين ، وتصبح إضافة ميزات جديدة شبه مستحيلة. في النهاية ، تضطر الشركات إلى وضع علامة "عفا عليها الزمن" على هذا الرمز وإجبار المطورين على إعادة كتابته.
لا يتناسب OOP جيدًا مع طريقة تفكير أدمغتنا. نحن معتادون على التركيز على العمل: الذهاب في نزهة على الأقدام ، والتحدث إلى صديق ، وتناول البيتزا. لقد تطور دماغنا نحو "فعل شيء ما" ، وليس نحو بناء تسلسل هرمي معقد للأشياء المجردة.
كود OOP غير محدد (على عكس البرمجة الوظيفية): لا يمكننا التأكد من أنه باستخدام نفس بيانات الإدخال ، سنحصل على نفس النتيجة في كل مرة. هذا يجعل من الصعب للغاية فهم كيفية عمل البرنامج. إليك مثال بسيط: قارن 2 + 2 مع الآلة الحاسبة ، أضف (2 ، 2) . يجب أن يُرجع التعبير الأخير ، من الناحية النظرية ، دائمًا 4 ، لكن يمكن أن يُرجع 5 أو 3 أو حتى 1004 ، لأن تبعيات كائن الآلة الحاسبة يمكن أن يغير سلوكه بأكثر الطرق التي لا يمكن التنبؤ بها.