فكرة أن الكود المصمم لإعادة الاستخدام يمكن أن يكون الدواء الشافي لجميع مشكلات البرمجة هي أسطورة خطيرة. الآن سوف أشرح لماذا.
دعنا نتخيل أنك تكتب مكتبة وتلتقط فجأة فكرة رائعة ، يمكن من خلالها الحصول على حل معمم ، قابل للتطبيق في مجموعة واسعة من الحالات. أنت تصف واجهات برمجة التطبيقات بشكل محموم من شأنه التغلب على أي وظيفة والتكيف مع أي سيناريو. يمكنك إضافة جميع النصوص التي تتبادر إلى ذهنك فقط. تتضخم الشفرة وتتضخم ، لكن في النهاية ، تصبح حقيقة معممة بكل معنى الكلمة. إنه مثل الكعك الساخن ، وأنت سعيد.
لكن في يوم من الأيام ، ظهرت واجهة برمجة تطبيقات جديدة في الأفق. إنه أكثر إيجازًا ومناسبًا لعدد أكبر من السيناريوهات ، علاوة على ذلك ، فهو يفوز بالسرعة والبساطة. تقع API الخاصة بك في غياهب النسيان - كل شخص يتحول على الفور إلى حداثة مغرية. ومع ذلك ، بعد مرور بعض الوقت ، تتكرر نفس القصة معها: يصبح API أكثر ثقلًا بسبب الإضافات المستمرة للرمز ، المصممة لظروف جديدة ، حتى يأتي شيء آخر ليحل محله في النهاية. وهلم جرا الإعلان اللانهائي.
لماذا هذا هكذا؟
جذر كل المشاكل في هذه الحالة هو الرغبة في كتابة حلول معممة. إذا أخذ الرمز القابل للتكرار الحالة القياسية كمعيار ، يصبح منتفخًا وغير مريح للاستخدام ، ويتحول تدريجياً إلى صداع نقي.
درجة من التعميم هو شرط مسبق للاستخدام المتكرر لأي رمز. ولكن إذا ذهبت بعيدا مع هذا ، تبدأ النفعية في المعاناة. لذلك ، إذا أعربت عن تفكيري باختصار ، فإن كتابة الكود القابل لإعادة الاستخدام لا يعني جعله شاملاً قدر الإمكان. كل شيء أكثر تعقيدا بكثير.
لإنشاء رمز استنساخ عملي ، تحتاج إلى التأكد من عدم استخدامه بانتظام ، ولكن تلقائيًا عند الحاجة. قل ، عند العمل على منتج ما ، فجأة صادفت رمزًا يمكن استخدامه لاحتياجاته. يمكنك أخذ هذا المقتطف وتعديله قليلاً وتنفيذه في التطبيق. وبالتالي ، أنت تدفع فقط مقابل الفوائد الحقيقية ، وعندما يكون ذلك ضروريًا بالضبط.
تكتشف لاحقًا أن هذا الإصدار المعدل قد يكون مفيدًا في تطبيق آخر. يمكنك أخذ هذه القطعة مرة أخرى ، وتعديلها قليلاً واستخدامها في الدائرة الثالثة. لذلك ، مع زيادة إمكانية الاستنساخ تدريجياً ، لا تحصل على أقصى استفادة من هذه القطعة فحسب ، ولكن أيضًا تحمي منتجك من الكود الذي لا يفعل شيئًا له ولا يحتاج إليه بشكل عام.
الشيء الرئيسي هنا هو بأي حال محاولة التنبؤ بالمستقبل. يجب أن تقتصر إعادة الإنتاج على حدود الرؤية الحالية ؛ في المستقبل ، ستقوم بتصحيح الكود وفقًا لذلك كلما ظهرت فرصة جديدة لتطبيقه. لن يوفر لك هذا الوقت والجهد فحسب ، ولكن أيضًا كتابة رمز أكثر اقتصادا وباردًا وحديثًا ، تم شحذه لإعادة الاستخدام.
فيما يلي بعض الاقتراحات العملية حول كيفية جعل التعليمات البرمجية قابلة لإعادة الاستخدام.
تجنب الازدواجية
كما قال Lemony Sinquet بحق: "لا تكرر. أولاً ، كرر نفسك ، وثانياً ، أنت تقول نفس الشيء ، وثالثا ، لقد سمع الجميع ذلك بالفعل ".
تذكر ، تحدثنا عن إعادة استخدام يحدث بشكل عفوي؟ هذا هو بالضبط ما (وهذا فقط) ينبغي أن يقتصر على الغرض من رمز مريح. لذا اكتب الكود الذي تحتاجه في هذه اللحظة بالذات ، واستمر بنفس الروح حتى تلاحظ أن عليك حل المشكلة نفسها مرارًا وتكرارًا. ثم قم بإعادة إنشاء المبنى ، ثم ضع الكود في مكان يمكن الوصول إليه وأشر إليه حسب الحاجة. بالتصرف بهذه الطريقة ، لن تحصل على رمز عام مضيِّل ، ولكن رمزًا لا يوجد فيه تكرار.
في الواقع ، يتم فرض نفس المبدأ من خلال مبدأ DRY (لا تكرر نفسك) ، والذي ينص على أنه لا ينبغي كتابة نفس المنطق مرارًا وتكرارًا في الشفرة - وهذا يؤدي إلى واجب فني. تؤدي عمليات التكرار التي لا معنى لها إلى إعاقة النظام وتقليل جودة قاعدة الشفرة ، بالإضافة إلى تحويلها إلى كابوس لأولئك الذين يتحملون مسؤولية الحفاظ على رمز المنتج. من المهم أن نتذكر: مبدأ DRY هو نوع من الفلسفة التي تدعو إلى التخلي عن طموحات البرمجة الشخصية والقيام بما هو أفضل للمشروع. إذا قام شخص ما بالفعل بشيء ما ، فاستخدمه. لا حاجة لإعادة اختراع العجلة.
تأكد من أن الفئة / الطريقة / الوظيفة مسؤولة عن شيء واحد.
في هذه المناسبة ، يمكننا أن نتذكر بيان لويس سوليفان الجميل: "النموذج يأتي من الوجهة". في الترجمة ، يعني ذلك ما يلي: إذا قامت دالة أو فئة أو أسلوب بعمل الشيء الوحيد ، فستغيرها لسبب واحد فقط. نعم ، من خلال هذا النهج ، سيكون عليك غالبًا إنشاء طرق تستخدم طرقًا أخرى ، لكنها ستبقى بسيطة وليست متماسكة للغاية.
تم بناء كل نظام عن طريق لغة موجهة للموضوع ، والتي تم إنشاؤها من قبل المبرمجين بهدف وصف مثل هذه الأنظمة بشكل صحيح. تؤدي الوظائف دور الأفعال في هذه اللغات ، وتلعب الطبقات دور الأسماء. معا ، كقاعدة عامة ، يشكلون المستوى الأساسي لتنظيم أي لغة ؛ وفقًا لذلك ، إذا وصفتهم بطريقة جيدة ، فسيكون الرمز الخاص بك عالي الجودة.
هناك قاعدتان ذهبيتان لإنشاء وظائف وفئات يمكن تطبيقها عدة مرات ، وهما فقط:
- يجب أن تكون صغيرة
- يجب عليهم فعل شيء واحد ، وكذلك
هذا يفترض أن الوظيفة يجب أن لا تنمو كافية لاحتواء بنيات متداخلة. وبالتالي ، يجب ألا يتجاوز مستوى التعشيش واحدًا أو اثنين. بفضل هذه التقنية ، يصبح الكود أسهل في القراءة والتحليل والاستيعاب.
بالإضافة إلى ذلك ، من الضروري التأكد من بقاء جميع المشغلين داخل وظيفة واحدة على نفس المستوى من التجريد. خلط المستويات دائمًا أمر محير ، وعاجلاً أم آجلاً سيؤدي إلى عمل شاق مع الكود. يرى المبرمجون المحترفون الشفرة القابلة للتكرار كنوع من السرد وليس مجرد جزء من النص. يستخدمون إمكانيات لغة البرمجة المختارة لإنشاء كتل أكثر تعبيرية وذات مغزى وأنيقة تبني السرد بشكل مثالي.
لا تسيء الإرث
في بعض الأحيان ، نحاول نحن المطورين النظر في المستقبل البعيد للمشروع والبدء في طرح وظائف إضافية بالأفكار "ماذا لو كنت في حاجة إليها" و "في يوم من الأيام". لا تفعل ذلك. حتى الآن ، لم يكن هذا مفيدًا بالنسبة لك ، والآن لا تحتاج إليه وفي معظم الحالات ... لن تحتاجه (لإعادة صياغة مبدأ YAGNI المعروف - أنت لست بحاجة إليه). هذا المبدأ ينطبق على الميراث. لا تدخله إذا لم تكن لديك ثقة تامة في أن التنفيذ سيتكرر عدة مرات.
مع كل هذا ، تعد الوراثة وسيلة رائعة لإضافة وظائف إلى الفصل. لكن المبرمجين يميلون إلى الاستيلاء على الحافة ، وبناء تسلسل هرمي للفصول الدراسية في ستة مستويات أو أكثر. تصف "عصابة الأربعة" في كتابها "أنماط التصميم" بإيجاز مخاطر الوراثة المفرطة:
"نظرًا لأن الفئة الفرعية لديها إمكانية الوصول إلى تفاصيل تنفيذ الفصل الأصل ، فغالبًا ما يقال إن الميراث ينتهك التغليف."
يؤدي الوراثة إلى تماسك قوي للمكونات ، لأن الطبقة الفائقة تفتح جوانبها الداخلية للفئات الفرعية ، والتي تعتمد بدورها تمامًا على الطبقة الفائقة في كل ما يتعلق بالتشغيل الصحيح. في هذه الحالة ، تفقد الطبقة الفائقة مرونتها - يصبح من الصعب تغيير أي شيء في وظائفها. لهذا السبب بالذات ، الوراثة هي وسيلة سيئة لتحقيق إعادة استخدام الشفرة.
هناك طريقة أكثر منطقية تتمثل في التفكير في نموذج بنية الأشياء ، بدلاً من الوراثة. سيتيح هذا للأشخاص الذين يستخدمون الكود الخاص بك الحصول بسهولة أكبر على الوظائف التي يحتاجون إليها وإنشاء كائنات خاصة بهم بناءً على القيود ذات الصلة بهم. يجب أن تفكر في إنشاء واجهات إجرائية يمكن لكل فئة أن تنفذها بطريقتها الخاصة. غالبًا ما تكون الواجهات أسهل في الفهم والتنفيذ من الفصول ذات الميراث متعدد الطبقات.
للتلخيص ، يجب ألا يلجأ المرء إلى الوراثة إلا إذا كانت فئة ما هي استمرار منطقي لفئة أخرى ومعظم كود الفئة الوراثية يستخدم كود الطبقة الفائقة. في أي حالة أخرى ، عليك ببساطة توقيع عقوبة الإعدام لنفسك وفرص إعادة رمز الاستخدام.
في الختام
بشكل عام ، لا تعني كتابة التعليمات البرمجية لإعادة الاستخدام إنشاء كتل متجانسة ضخمة. مفتاح كتابة التعليمات البرمجية القابلة للتكرار هو في العناصر التي تهدف إلى مهمة محددة ، والتي يتم تجميعها بسهولة ، ملحوم جيدًا وليست مترابطة جدًا.
وأخيراً ، لا تضع حداً بحد ذاتها من الاستخدام المتكرر - لا يستحق كل هذا العناء. من الأفضل وضع هدف لتجنب الازدواجية ، وليس كتابة أجزاء فارغة غير ضرورية ، لضمان سهولة قراءة التعليمات البرمجية والحفاظ عليها. عندما تقوم بتطوير النظرة الصحيحة للأشياء ، فإن التكرار سيأتي من تلقاء نفسه.
تذكر دائمًا: إعادة الاستخدام تبدأ بحقيقة أنك قد وجدت حلاً ناجحًا لمهمة معينة. يجب أن يتدفق كل شيء آخر من هذه الفرضية ، ولديك الحق في اختيار الطريقة الأكثر ملاءمة من أجل جلب جزء معين من الشفرة إلى مستوى جديد. كما قال رالف جونسون بحق: "قبل أن تفكر في إعادة استخدام الرمز ، عليك التأكد من أنه يمكنك استخدامه على الإطلاق."