تعرف أحجار المعابد القديمة كيف تتحدث ، لكن القليل من الناس استجابوا لها. الكون مليء بالأصوات التي لا نسمعها نحن البشر. ألوان لا نراها: في بعض الأحيان هي القيود الموضوعية للجسم والروح ، ولكن هناك أيضًا أسباب ذاتية - قلة المعرفة والمهارات أو عدم القدرة على استخدامها في الممارسة اليومية. مثال حي على الثانية في عالم البرمجة - التواقيع الوظيفية. يفكر أطفال عالم OO في أفضل الأحوال في الواجهات - إنه قريب ، ولكن "ليس هذا تمامًا" وكلما أصبحت أكثر انتباهًا ، كلما تحول إلى "ليس على الإطلاق". والتوقيعات وظيفة تعرف أيضا كيفية التحدث.
بصراحة ، أود أن أبدأ من جانب التجريدات عالية المستوى حقًا ، لكن تجربتي السابقة تظهر أنه حتى أبسط الحقائق الرياضية بلغة غير رياضية "لا تبدو سليمة". بعد فترة وجيزة ، أشير إلى أن كل ما أتحدث عنه يولد من الفكر الرياضي - وبالتالي ، يمكن إضفاء الطابع الرسمي عليه.
والآن - التفاصيل. ربما يزعج كل من "يفتشون" أكثر أو أقل القراءة مرة واحدة على الأقل في عمل صنع الحقبة في GoF ؛ ربما حتى تلك "غير الملصقة" تعرف أن هناك مثل هذا النمط - التكرار. وبالتأكيد الجميع يستخدمه كل يوم. لذلك (التمسك الشرطي C #):
bool MoveNext(); T Current { get; }
... والآن نفس الشيء ، ولكن بدون ضوضاء نحوية (يشير هذا إلى أن "بدون ضوضاء تركيبية" تعني في الواقع على Haskell):
MoveNext :: () -> Bool Current :: () -> t
... عند نسيان الأنواع لفترة من الوقت والتركيز على السهم نفسه (->) ، هل تعرّضت بشكل قسري إلى السؤال عما سيحدث إذا تم "عكسه"؟ ثم اتضح:
MoveNext' :: Bool -> () Current' :: t -> ()
شعور طفيف بالتنافر ، أليس كذلك؟ إذا لم تكن هناك مشاكل مع
t -> () ، فإن
Bool -> () تبدو أكثر من مشبوهة. وبالفعل - تم استخدام هذا العلم للإشارة إلى نهاية التسلسل ، أليس كذلك؟ في النموذج المقلوب ، لا يكون للحالة
True -> () أي معنى - فقط
False -> () يكفي. يتم فقدان عدم اليقين الثنائي الذي يوفره نوع Bool - وبالتالي يجب أن يبدو كما يلي:
completed :: () -> () next :: t -> ()
لا يشبه أي شيء؟ ماذا عن
الامتدادات التفاعلية ؟
واو! إن التوقيع (حسناً ، بتعبير أدق ، التوقيعات ، لكن النهج نفسه يعمل على المستوى الفردي) لوظيفة إطار (صغير) رائع (صغير) أخبرنا عن آخر لا يقل برودة ، أليس كذلك؟ تحتاج فقط إلى توخي الحذر وسماع.
أخبار جيدة للعالم من نظرية الفئةمن في هذا الموضوع ، بالطبع ، يعرف أن المثال مع IEnumerator <-> IObserver ليس جديدًا.
من المدهش أنه نادراً ما يدرك أي شخص أن هذا أبعد ما يكون عن المثال الوحيد (على الرغم من أننا يجب أن نشيد به ، وعلى وجه التحديد هذا مشرق للغاية).
يمكن للفضوليين أخذ أنماط GoF المتبقية والنظر في الثنائيات. غالبًا ما ينتهي هذا الهراء - هذا أمر طبيعي: في حد ذاته ، تكون "الازدواجية" أعلى من العالم الدنيوي ولا تعتبر نفسها ملزمة بالحساب مع الاستخدام العملي: ولكن بعد كل شيء ، لا تحتاج الشمس أيضًا إلى أي شيء من الناس للتألق.
فلماذا "بارد تقريبا"؟ نعم ، بسبب التنافر الذي أدى إلى الحاجة إلى مزيد من الطحن والقطع. بالمعنى الدقيق للكلمة ، مع إعادة الأسهم ، فقد تحول الأمر إلى شيء غير مفيد تمامًا ، والذي يمكن تفسيره على أنه عيب في التوقيع الأصلي. بالنظر إلى المستقبل ، أقول أنه يمكن إعادة تعريف هذا التوقيع ذاته بطريقة تختفي التنافر وسيكون من السهل للغاية الانتقال إلى ازدواجيته. لكنني لن أزعج هذا ... على الأقل - ليس في هذه المذكرة.
من الأفضل تلخيصها ، بناءً على تجربتي:
- يمكن أن تتحدث التواقيع الوظيفية ، ولكن غالبًا ما يكون المبرمجون أصمًا.
- في كل مرة تقابل فيها وظيفة جيدة التصميم ، اسأل نفسك ما هو نوعها المزدوج وما إذا كان يمكن أن يكون مفيدًا لأية مهام.
- في حالة وجود مزدوج ، ولكن يتطلب "تعديل طفيف" كما في المثال أعلاه ، فعلى الأرجح يكون للتوقيع الأصلي بعض العيوب الضمنية ؛ ربما يكون من المنطقي إعادة تعريفها بحيث لا توجد مشكلة من هذا القبيل؟