البرمجة الوظيفية مقابل البرمجة الموجهة للكائنات [مغلقة

Question

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

• متى تختار البرمجة الوظيفية على الكائنات الموجه؟
• ما هي تعريفات المشكلة النموذجية حيث تكون البرمجة الوظيفية خيارًا أفضل؟

Answer 1

متى تختار البرمجة الوظيفية على الكائن الموجهة؟

عندما تتوقع نوعًا مختلفًا من تطور البرمجيات:

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

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

عندما يذهب التطور بطريقة خاطئة ، لديك مشاكل:

• قد تتطلب إضافة عملية جديدة إلى برنامج موجه نحو الكائن تحرير العديد من تعريفات الفئة لإضافة طريقة جديدة.

• قد تتطلب إضافة نوع جديد من الأشياء إلى برنامج وظيفي تحرير العديد من تعريفات الوظائف لإضافة حالة جديدة.

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

ما هي تعريفات المشكلة النموذجية حيث تكون البرمجة الوظيفية خيارًا أفضل؟

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

Answer 2

ليس عليك بالضرورة الاختيار بين النموذجين. يمكنك كتابة البرامج مع بنية OO باستخدام العديد من المفاهيم الوظيفية. FP و OOP متعامد في الطبيعة.

خذ على سبيل المثال C#. يمكنك القول أنه في الغالب OOP ، ولكن هناك العديد من مفاهيم FP والبناء. إذا كنت تفكر LINQ, ، أهم البنيات التي تسمح بوجود LINQ وظيفية في الطبيعة: تعبيرات لامدا.

مثال آخر ، و#. يمكنك القول أنه في الغالب FP ، ولكن هناك العديد من مفاهيم OOP والبنيات المتاحة. يمكنك تحديد الفصول الدراسية والفصول المجردة والواجهات والتعامل مع الميراث. يمكنك حتى استخدام قابلية التبديل عندما يوضح الكود الخاص بك أكثر وضوحًا أو عندما يزيد الأداء بشكل كبير.

العديد من اللغات الحديثة هي متعددة البرامج.

قراءات موصى بها

لأنني في نفس القارب (خلفية OOP ، تعلم FP) ، أقترح عليك بعض القراءات التي أقدرها حقًا:

• البرمجة الوظيفية لتطوير .NET كل يوم, ، بقلم جيريمي ميلر. مقال رائع (على الرغم من تنسيقه سيئ) يوضح العديد من التقنيات والأمثلة العملية في العالم الحقيقي لـ FP على C#.

• برمجة وظيفية في العالم الحقيقي, ، بقلم توماس بيترسيك. كتاب رائع يتعامل بشكل أساسي مع مفاهيم FP ، في محاولة لشرح ما هي عليه ، عندما يجب استخدامها. هناك العديد من الأمثلة في كل من F# و C#. ايضا، مدونة بيترسيك هو مصدر كبير للمعلومات.

Answer 3

عروض البرمجة الموجهة نحو الكائن:

1. التغليف ، ل
   • طفرة السيطرة على الحالة الداخلية
   • الحد من الاقتران للتمثيل الداخلي
2. النوع الفرعي ، السماح:
   • استبدال الأنواع المتوافقة (تعدد الأشكال)
   • وسيلة خام لمشاركة التنفيذ بين الفصول (ميراث التنفيذ)

يمكن أن تسمح البرمجة الوظيفية ، في Haskell أو حتى في Scala ، الاستبدال من خلال آلية أكثر عمومية لفئات النوع. حالة داخلية قابلة للتغيير إما محبط أو ممنوع. يمكن أيضًا تحقيق تغليف التمثيل الداخلي. يرى هاسكل مقابل OOP لمقارنة جيدة.

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

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

Answer 4

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

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