لوحة المتصدرين

لا تخدع نفسك، فتقديرات تسعير البرمجيات بصفتها خدمة ليست بالأمر البسيط. دعني أُجمِل لك الأمر، لقد ارتكبتُ عددًا من الأخطاء فيما يخص التقييم. وبفضل تجربتي (وهي أثمن معلّم في الحياة)، اكتشفتُ كيف أقيّم منتجًا ما، وأُحسّن القيمة الدائمة للعميل، وكيف أضيف مضامين ترتقي بالصفقات، وتؤمّن المدفوعات الرقمية، وتتجنب تخفيض قيمة الموجودات التجارية أكثر. وسأشاركك فيما يلي بعضًا مما تعلمتُ. تعقيد تسعير المنتج إن الحل الذي أشاركك إياه بسيط لدرجة لا تُصدّق، وسأعرضه لك بصيغة استعراض تمهيدي. السؤال: ما أكبر صعوبات التسعير؟ الجواب: تحديد المقياس الصحيح للسعر. السؤال: ما الحل؟ الجواب: ارفع سعرك. لا تقلق، سأكشف لك عن ذلك الحل، لكني سأضع مبدأً أسير عليه قبل ذلك، بقولي إنه لا توجد خطوة سهلة أثناء تسعير المنتجات. تسعير المنتجات تجربة معقدة ومليئة بالعوائق لا يمكنك تحديد سعر منتج ما بوضع بعض الأرقام فحسب، بل عليك أيضًا التفكير في الجانب النفسي لدى المشتري. لماذا يُعَد ذلك مهمًا؟ لأنه بصرف النظر عن المنطق التجاري الذي يعكسه سعرٌ ما، فقد لا يتحسسه المستهلك المحتمَل. ولكن، هناك سبب أكثر أهميةً لأخذ الجانب النفسي للمشتري بالحُسبان، وهو أنه لا يشتري بناءً على السعر وحده، بل عندما يدرك قيمة المنتج أيضًا، وذلك بصورة مستقلة عن سعره. إليك خمس خصائص لنفسية المشتري عليك إدراكها أثناء تسعير المنتج: يحتاج المشتري إلى فهم الكيفية التي ستمكّنه فيها برمجيتك بوصفها خدمةً من جني المال: إن تكلفة المنتج هي فقط إحدى المتغيرات التي يحتاج المشتري إلى موازنتها بإمكانية الكسب التي تقدّمها برمجيتك كونها خدمة. يحتاج المشتري إلى استيعاب الجوانب التي تتفوق فيها خصائص منتجك على تلك الخاصة بمنتج منافسيك: عندما نافستُ شركة أومنتشور -التي تقدّر قيمتها بمليارات الدولارات- بشركتي الناشئة الصغيرة، كنت أعلم أني سأتمكن من تحقيق مبيعات، وذلك لإدراكي أن منتجها كان شديد السوء رغم الاستحواذ الذي كانت تحققه، ويشتكي منه عملائي الذين يطلبون مني الاستشارة، ولكن لم يكن لديهم بديل غيرها لإعداد التقارير الإحصائية. وبفضل هذا الذكاء في مجال السوق، علمتُ أن بوسعي تطوير منتج بخصائص تفوقت على منتج تلك الشركة. لا يحتاج المشتري إلى موازنة بين الأسعار، بل بين الخصائص: لا يشتري المستهلكون حلولًا، بل يشترون خصائص، ولذا ستفشل العديد من مخططات الموازنة السعرية المستخدمة بوصفها وسيلة إقناع سوقية. لكن ما السبب في ذلك؟ لأنها -وفقًا لباحثي جامعة ستانفورد- قد تقدّم نمطًا تفكيريًا يُبعد خيار المستهلك عنك ويجعله يختار منافسيك. وبدلًا من التركيز على السعر، فليكن منصبًّا على ما يريده المستهلك فعلًا، أي على الخصائص، وذلك لأن الخصائص تضيف قيمة، وهذا كل ما تتمحور حوله مسألة التسعير. يجب ألا يختار المشتري، بل أنت من عليك الاختيار له: نعيش وسط ثقافة نعتقد فيها أنّه كلما كثرت الخيارات، كان ذلك أفضل. لكن الحال ليست كذلك فيما يخص تسعير برمجيتك بصفتها خدمة. أترى كل تلك الباقات الفاخرة، والخصائص والخيارات الإضافية على صفحة التسعير الخاصة ببرمجيتك مثل خدمة؟ دعكَ منها. فعندما تكثر الخيارات أمام المستهلك، لا ينتقون أيًا منها في نهاية المطاف. يتأثر المشترون بسياق التسعير، وليس فقط بالتسعير: ثمة الكثير من المناورات التي بوسعك تنفيذها في لعبة التسعير. ففي ذهن المستهلك، لا يمثل السعر سوى واحدة من خصائص عديدة تؤثر في قراره. فجوانبٌ بأهمية القيمة وبهامشية حجم الخط، تؤثّر جميعها في خيار الشراء. ورغم تعقيد عملية التسعير، فكلي ثقة بأن اختراقًا بسيطًا من شأنه إحداث ثورة في منهجك المستخدم في تسعير المنتج. وهناك ما يدعم تأكيدي هذا في كل من علم النفس والتجربة. سأشرح لك ذلك لاحقًا. ما أكبر صعوبات التسعير؟ علينا أولًا فهم الصعوبة الأكبر في مجال تسعير البرمجيات كونها خدمة. إذ أجرت "زورا" -وهي مزوِّد تجارة اشتراك-، دراسةً استقصائيةً لتحديد المشاكل المتكررة في نماذج تسعير الاشتراك، وهي المنهجية الأكثر شيوعًا في مجال البرمجيات كونها خدمة. إليك ما تبيّن لها: أقرَّ أكثر من نصف المُجيبين أن "تحديد مستوى السعر الصحيح" يمثل الصعوبة الأكبر التي يواجهونها؛ أما المشكلة التي تأتي في المرتبة الثانية من حيث الصعوبة، والتي استغرقت أكثر من ربع الرسم البياني الدائري الخاص بهذه الدراسة، فهي مقاييس السعر التي تُعرّف بأنها: خصائص المنتج التي يُبنى عليها السعر، إلى جانب الطريقة التي تشترط الدفع وفقًا لها بوصفك مزوِّدًا لتلك الخدمة مثل نموذج الاشتراك. وبدمج هاتين المشكلتين معًا، يتّضح جليًّا أن نسبة 75% من مشكلة المجيبين في هذه الدراسة متعلقة بكيفية تسعير منتجهم. وتتضمن تلك الكيفية كلًا من الطريقة والمبلغ. فإذا نجحت شركةُ خدمة برمجيات في حل هذه المعضلة، فيمكنها زيادة الربحية والنمو وتقديم قيمة أكبر لعملائها. إن الإيجابيات المحتملة لاستراتيجية تسعير مثالية هائلة، لكن المشكلة تكمن في كيفية الوصول إلى تلك الاستراتيجية. دعني أعطيك الحل البسيط، ثم سأشرح لك السبب الذي يجعله منطقيًا. ما الحل؟ ارفع سعرك كل ما عليك فعله للاقتراب من مستوى السعر الصحيح هو جعل سعرك أعلى مما تظن أنه يجب أن يكون. من الواضح أنه لا يمكنني إعطاؤك صيغة لتحديد نقطة السعر الأصلية الخاصة بك. ما الذي يجعلني عاجزًا عن ذلك؟ هل تتذكر مسألة التعقيد التي تحدثتُ عنها للتقديم لهذه المقالة؟ عليك تحديد تكلفة الإنتاج، وتوقعات الإيرادات، وتكلفة الاستحواذ على عميل، إلخ. ثم عليك تحديد النقطة التي تكسب عندها مالًا كافيًا. يمكنك البدء بتكلفتك المعتادة، ثم تضيف إليها استراتيجية هامش السعر، وبعدها تأخذ الرقم الناتج عن ذلك، وترفعه إلى رقم أعلى، وأعلى من ذلك، ثم أعلى قليلًا، بعدها ترفع السعر أعلى من ذلك أيضًا. كيف يذلل السعر الأعلى صعوبات التسعير الكبرى لنعُد إلى صعوبات التسعير لدى مزوِّد تجارة الاشتراك المسمى "زورا"، ونحدد كيف يمكن لهذه الاستراتيجية التغلّب على الصعوبات: القصور الذاتي عن تغيير تسعيرنا: هذه مشكلة في الواقع؛ فلتتذكر أن القصور الذاتي (أو العطالة، في الفيزياء) في جسم مادي يميل إلى مقاومة أي تغييرات على حالته من السكون إلى الحركة. ولذا عليك استخدام قوة متفجرة لتحقيق ذلك التغيير، مثل تلك التي تُحدثها قنبلة. فإذا كنت صاحب القرار في مؤسستك، فعليك اتخاذ فعل جذري حاسم لتحقق ذلك التغيير. تحديد مقياس السعر الصحيح: لا يوجد مقياس وحيد يحدد استراتيجية التسعير الصحيحة. فهناك حقيقتان اثنتان فقط في هذا الشأن، هما: نموذج الاشتراك وتسعير القيمة، ويُقصَد به تسعير منتج ما وفقًا للقيمة التي يعطيها للمستهلك، ولا شيء غير ذلك. تحديد مستوى السعر الصحيح: هذه مشكلة الارتباك وغياب الوعي البسيطة. يشرح الجزء المتبقي من هذه المقالة السبب الذي يجعل سعرًا أعلى الاستراتيجيةَ الأفضل للتسعير. العوائق المؤسساتية الداخلية: فمَن الذي يرغب في الاعتراض على هوامش الربح والرواتب الأعلى وأسعار الأسهم المتصاعدة؟ العوائق التي تفرضها النُّظم: يبرر السعرُ المرتفع وهوامش الربح العالية، استخدامَ نظام تجارة أفضل. فإذا كان نظامٌ أفضل من سواه فسيدرّ عليك مزيدًا من المال، ولتشتره إذًا. بم سيفكر عملاؤك؟ يقول بول غراهام: عندما يتذمر المشترون ومع ذلك يشترون، تكون قد عثرتَ على سعر السوق. هذا قولٌ مضلِّل، لكنه لا يخلو من حقيقة. إذ يقصد غراهام من ذلك إيصال رسالة مفادها أن عملاءك يحبون منتجك لدرجة تجعلهم يدفعون أيّ سعر للحصول عليه. ولكن الناس بالتأكيد لا يريدون دفع مزيد من المال لك؛ إذ لا نود خسارة أموال إضافية، ولكن عندما يدرك المستهلك قيمة منتجك بالموازنة مع سعره، فلا يفكر في توفير المال. يحيلنا ذلك إلى السبب الأصلي وراء القيمة المطلوبة، فالمستهلكون لا يشترون سلعة بل يشترون قيمة. وها هو لينكولن ميرفي متحفظًا على مقولة بول غراهام، إذ يرى أن سعرك ينبغي أن يقترن بقيمة متصوَّرة عند كل مستوى. تحدث عن القيمة لا عن السعر عندما ترفع السعر، فليس ذلك بالمشكلة العظيمة بالنسبة للمستهلكين، لأن القيمة هي الأهم بالنسبة لهم، وليس السعر. فالسعر نسبي تجاه القيمة، وأعني بذلك أنّ المستهلك يفكّر بالقيمة أولًا، ثم يحدد قيمة المنتج نسبةً إلى سعره. أي إن المستهلكين سيدفعون أي مبلغ عليهم دفعه ما دام أن القيمة المتصوَّرة تفوق السعر. يُطلق لينكولن ميرفي -مؤسس شركة الاستشارات المسماة سيكستين فينتشرز Sixteen Ventures- على ذلك وصف تسعير القيمة، ويعرّفه بقوله: إعادة صياغة سعر بالنسبة لخدمة تتوافق مع القيمة المشتقة من استخدام الخدمات، بدلًا من التكلفة الضمنية لإنشاء وتقديم البرمجيات مثل خدمة وأسعار السوق والهوامش المحددة، وغيرها. كلما ارتفع السعر زادت القيمة المتصورة لاحِظ أنّ القيمة المتصورة تختلف عن القيمة الواقعية. لِنَقُل مثلًا إن برمجيتك بصفتها خدمة تكلف 15 دولارًا في الشهر الواحد، فإذا حصل المستهلك على قيمة تُعادِل 500 دولار في الشهر، فسيدفع ذلك المبلغ 15$ بكل رضا. وحتى لو رفعتَ سعرك إلى 455 دولار شهريًا، فسيبقى ذلك المستهلك يثمّن القيمة التي يحصل عليها، لأنه يكسب قيمةً إضافيةً تبلغ 5 دولارات، وهذا ليس مقياسًا نسبيًا، بل ثابتًا. يعمل تغيير مستوى السعر والقيمة لصالح أفضليتك التسويقية، لأن بوسعك رفع تصوّر المستهلكين للقيمة، وذلك برفع السعر. تُسمّى هذه الظاهرة بـ "القيمة المتصوَّرة". ويعرّفها موقع إنفيستوبيديا investopedia الإلكتروني المالي بأنها الأهمية التي يتمتع بها منتج أو خدمة في ذهن المستهلك. يؤثّر التصور الذي لدى المستهلك، تجاه قيمة سلعة ما أو خدمة مُرضية، في السعر الأساسي الذي هو مستعد لدفعه لقاء الحصول عليها، كي تبقى تلك السلعة أو الخدمة مقدَّمةً في المجال التجاري ذي الصلة. وبالنسبة للجزء الأكبر الحاسم، لا يكون المستهلك غالبًا على دراية بالتكلفة الحقيقة للإنتاج ذي الصلة باستخدام المنتجات التي يميل إلى شرائها. وبدلًا من ذلك، يسيطر على ذلك المستهلك شعور داخلي غير محدد تجاه الأشياء، مثل كم من القيمة تساوي منتجات محددة بالنسبة له موازنةً بمنتجات مماثلة لشركات منافسة. لذلك وفي محاولة من المنتجين للحصول على سعر أعلى لمنتجاتهم، فقد يلجؤون إلى استراتيجيات تسويقية لتحقيق قيمة متصوَّرة بارزة لها. يبسّط الأستاذ في جامعة كاليفورنيا، ليف نيلسون، الموضوع بقوله: يمكن للسعر أن يهيمن على التقييم. فلو نظرتَ إلى علبة عطر مُسعّرة بخمسة دولارات، وإلى أخرى بألف وخمسمئة دولار، فستفترض تلقائيًا وبدون تفكير، أن علبة العطر الأعلى ثمنًا بينهما لها قيمة أكبر، حتى ولو كان العطر في كلتا العبوتين هو ذاته. الحقيقة بالنسبة للمستهلك تأتي مع ما يسمى معايير أمان صناعة بطاقات الدفع PCI Compliance. فإذا تصوَّرَ أنّ منتجك ذو قيمة بالنسبة له، فهذا ما يريده، وستجهد في إقناعه بعكس ذلك. ووفقًا للبحث الذي أجرته مجلة جورنال أوف ريتيلنغ، فلدى المستهلكين أربعة دوافع تؤثر في تصوّرهم: القيمة العاطفية للمنتج. الخاصّية الاجتماعية التي تترافق مع اقتناء المنتج. الجودة/ الأداء المشتقيَن من المنتج. سعر المنتج مقابل قيمته. ولك أن تلاحظ خلوّ الخصائص الثلاثة الأولى من كل ما يتعلق بالسعر الحقيقي، بل تتعلق جميعها بالتصوّر؛ أما الخاصية الرابعة (السعر مقابل القيمة)، فهي الوحيدة التي يولي فيها المستهلك أهمية لموضوع السعر. أي يتعلق الأمر برمّته بتصوّر القيمة لدى المستهلك، وهي حقيقة مقنعة تمامًا في تبرير رفعك للسعر لزيادة ذلك التصوّر. السعر الأعلى يعني قيمة فعلية أعلى أجرى باحثو معهد كاليفورنيا للتقنية Caltech وجامعة ستانفورد Stanford تجربة تذوّق مشروب، للوقوف على ما إذا كان المنتج ذو السعر الأعلى سيزيد استمتاع الخاضع للتجربة به. لقد حصل ذلك فعلًا، إذ قال المشاركون الذين تذوقوا المشروب ذا السعر الأعلى إنه ألذ مذاقًا من المشروب الأدنى سعرًا، وذلك رغم أن المشروبين كانا مشروبًا واحدًا موزعًا في زجاجتين. تنطبق هذه الظاهرة على برمجيتك بوصفها خدمة، فكلما زاد التباهي بمنتج ما، زاد إحساس المستخدم بقيمته، وبالمتعة في استخدامه. وهو تكتيك فعال خصوصًا في مجال خدمة البرمجيات، لأن للبرمجية "عنصرًا كبيرًا غير ملموس" حسب وصف ناغاسيمها كاناجال Nagasimha Kanagal في مجلة جورنال أوف مانجمنت أند ماركتينغ ريسرتش Journal of Management and Marketing Research. يمكنك جعل منتجك أفضل بجعله أعلى سعرًا. فبهذه الطريقة تحدد قيمة المنتج. الخاتمة أُسرُّ لرؤيتي مستهلكًا سعيدًا بدفع ماله، لعلميَ أنه مدرك حتمية حصوله على صفقة جيدة، فرضاه ينعكس رضىً لديّ، والخوف من انزعاج المستهلك مسؤول عن قدر كبير من التردد الذي يسبق رفع السعر. ومثلما شرحتُ في السطور السابقة، لا يؤدي سعرك المرتفع إلى خسارة عملائك. بل بالعكس، يمكن للسعر العالي إسعاد العميل بفضل القيمة العالية التي يحصل عليها، فالمستهلكون الذين يحصلون على قيمة من منتجك -سواء أكانت قيمة حقيقية أو متصوَّرة- هم مستهلكون سعداء؛ وحَسْبُ ذلك سببًا لرفع سعرك. ترجمة -وبتصرّف- للمقال How To Price Your SaaS Product لصاحبه Avinash Mittal. اقرأ أيضًا استراتيجيات التسعير واتجاهاتها الحديثة والمستقبلية وتطوير المنتجات المنتج وتصنيفه ودورة الحياة التي يمر بها مالم يخبرك به علماء النفس عن تسعير المنتجات كيف تختار السعر الملائم للمنتج؟ أهداف تسعير المنتج واستراتيجياته المختلفة مجموعة نصائح تحقق النمو لمشروعك التجاري الصغير عبر الإنترنت النسخة العربية الكاملة لكتاب: مدخل إلى التسويق

سنتحدث في المقالات الباقية من هذه السلسلة عن متصفحات الويب، فبدونها لم تكن جافاسكربت لتكون أصلًا، وإذا وُجدت لسبب ما فلم يكن أحد ليلتفت إليها. بُنيت تقنية الشبكات لتكون غير مركزية من البداية، سواءً على الصعيد الفني أو بالنسبة للطريقة التي تطورت بها، فقد أضافت العديد من الجهات الموفِّرة للمتصفحات وظائفًا جديدةً لأغراض محددة بعينها أحيانًا، وبدون تفكير أحيانًا أخرى لتعطينا وظائف ومزايا جديدة في صور سيئة، ثم يدور الزمن بهذه وتلك إلى أن يتبناها أحد ما ثم تصير معيارًا قياسيًا في النهاية. ونرى أنّ هذا قد يكون نعمةً ونقمةً في الوقت نفسه، فمن الجيد ألا يكون لديك تحكم مركزي في نظام مثل الإنترنت ويكون تطوره على يد جهات مختلفة تتعاون أحيانًا فيما بينها بصورة طفيفة، وتكاد تناوش بعضها أحيانًا أخرى؛. لكن من الناحية الأخرى، تعني الطريقة العفوية التي تطور بها الإنترنت أنّ النظام الناتج لن يكون هو الآلية التي يتوقعها البعض من حيث الاتساق النظامي الداخلي، فبعض أجزاء هذا النظام مشوشة إلى حد الحيرة. الشبكات والإنترنت وُجِدت شبكات الحواسيب منذ خمسينات القرن الماضي، ذلك أنك إذا وصلت حاسوبين أو أكثر بسلك لنقل البيانات فيما بينها، فستستطيع فعل الأعاجيب بهذه الشبكة الصغيرة، وعليه فهذه الأعاجيب تزداد عجبًا حين نوصل جميع الحواسيب في العالم ببعضها البعض. وقد بدأت التقنية التي تطبق هذه الرؤية في التطوير في الثمانينيات، ثم حصلنا على الشبكة التي تسمى بالإنترنت، وقد كانت كما حلمنا بها بالضبط. يستخدِم الحاسوب هذه الشبكة ليرسل بِتَّات من البيانات إلى حاسوب آخر، ويجب على كلا الحاسوبين معرفة ماذا يفترض لهذه البِتَّات أن تكون وماذا تمثل من أجل تحقيق تواصل فعال، ويتوقف معنى أي تسلسل من البتات على نوع الشيء المراد التعبير عنه وعلى آلية الترميز encoding mechanism المستخدَمة. يصف بروتوكول الشبكة network protocol أسلوبًا من التواصل عبر أي شبكة، فهناك بروتوكولات لإرسال البريد الإلكتروني وجلبه ومشاركة الملفات، وحتى التحكم في الحواسيب التي قد تكون مصابةً ببرمجيات خبيثة، فيُستخدَم بروتوكول نقل النصوص الفائقة HTTP مثلًا -وهو اختصار لـ Hypertext Transfer Protocol- لجلب الموارد المسمّاة وكتل المعلومات مثل صفحات الويب أو الصور، كما يشترط على الجزء الذي سينشئ الطلب البدء بسطر يشبه السطر التالي مسميًا المورد وإصدار البروتوكول الذي يريد استخدامه: GET /index.html HTTP/1.1 هناك قواعد كثيرة تحكم الطريقة التي يمكن للطالب requester فيها إدخال بيانات أو معلومات في الطلب، والطريقة التي يحزِّم الطرف الآخر بها الموارد المطلوبة، وهو مستقبِل الطلب الذي يعيد هذه الموارد إلى طالبها.. تُبنى أغلب البروتوكولات على بروتوكولات أخرى، حيث يتعامل بروتوكول HTTP مع الشبكة كما لو كانت أداة يضع فيها البِتّات ويتوقع منها الوصول إلى الوجهة الصحيحة بالترتيب المتوقع لها، لكن الواقع المشاهَد يقول عكس ذلك كما رأينا في مقال البرمجة غير المتزامنة في جافاسكريبت. ويعالِج بروتوكول التحكم في النقل TCP -اختصارًا لـ Transmission Control Protocol- هذه المشكلة بما أن كل الحواسيب المتصلة بالإنترنت تفهمه، وقد بُنيت أغلب عمليات التواصل في الإنترنت عليه أصلًا. فكرة عمل بروتوكول TCP هي أنّ الحاسوب يجب أن يكون في وضع انتظار أو استماع للحواسيب الأخرى حتى تكلمه أو تراسله، كما يجب أن يكون لكل مستمِع رقمًا يسمى منفَذًا port ويرتبط به من أجل أن تستطيع استماع عمليات تواصل مختلفة في الوقت نفسه على آلة واحدة، كما تحدد أغلب البروتوكولات المنفَذ الذي يجب استخدامه افتراضيًا، فحين نريد إرسال بريد إلكتروني باستخدام بروتوكول SMTP مثلًا، فيجب أن تستمع الآلة التي نرسله من خلالها إلى المنفَذ 25، ثم سينشئ حاسوب آخر حينئذ اتصالًا من خلال التوصيل بالآلة الهدف مستخدمًا رقم المنفَذ الصحيح، فإذا استطاع الوصول إلى الآلة الهدف وكانت تستمع لهذا المنفَذ، فسنقول أنّ الاتصال تحقق بنجاح، كما يُسمى الحاسوب المستمع هنا بالخادم server والحاسوب المتصَل به بالعميل client. يعمل مثل ذلك الاتصال على أساس خط أنابيب ثنائي الاتجاه يمكن للبِتّات أن تتدفق فيه من كلا الاتجاهين، مما يعني استطاعة كلا الحاسوبين إرسال البيانات واستلامها عبره، وبمجرد أن تُنقل البِتّات بنجاح، فسيمكن للآلة التي على الطرف الآخر قراءتها مرةً أخرى، وهذا النموذج مريح جدًا، بل يمكن القول أنّ TCP هو النموذج المجرَّد للشبكة. الشبكة العنكبوتية العالمية The Web تُعَدّ الشبكة العنكبوتية العالمية -أو الويب- مجموعةً من البروتوكولات والصيغ التي تسمح لنا بزيارة صفحات الويب داخل متصفح ما، وتشير كلمة الشبكة العنكبوتية فيها إلى حقيقة إشارة هذه الصفحات إلى بعضها بعضًا وارتباطها ببعضها، وبالتالي تكوّن شبكةً عملاقةً يستطيع المستخدِم التنقل خلالها بحُرية، كما يجدر بنا الإشارة هنا إلى أنّ هذه الشبكة ليست هي كل الإنترنت، فالأخير أوسع وأشمل. لكي تكون جزءًا من هذه الشبكة، لا تحتاج إلا إلى توصيل آلة بالإنترنت وتجعلها تستمع إلى المنفَذ 80 ببروتوكول HTTP كي تستطيع الحواسيب الأخرى طلب مستندات وملفات منها، ويُسمى كل مستند على الشبكة بمحدِّد موقع الموارد الموحَّد Uniform Resource Locator -أو URL اختصارًا-، حيث يكون أشبه بما يلي: http://eloquentjavascript.net/13_browser.html | | | | protocol server path يخبرنا أول جزء أنّ هذا الرابط يستخدم بروتوكول HTTP على خلاف بروتوكول HTTP المشفَّر مثلًا التي سيكون هكذا: https://‎، ثم يعرِّف الجزءُ الذي يليه الخادمَ الذي نطلب منه المستند، ولدينا في النهاية مسار من سلسلة نصية يعرِّف المستند المحدَّد أو المورد الذي نريد. تحصل الآلات المتصلة بالإنترنت على عنوان IP يكون رقمًا يمكن استخدامه لإرسال رسائل إلى هذه الآلة، حيث يبدو هكذا: 149.210.142.219 أو 2001:4860:4860‎::‎8888 غير أن هذه الأرقام المتتالية يصعب حفظها وكتابتها، لهذا تستطيع تسجيل اسم نطاق لأحد تلك العناوين أو بعضها، وقد سجلنا eloquentjavascript.net مثلًا لنشير إلى عنوان IP لآلة نتحكم فيها ونستطيع استخدام اسم النطاق حينئذ لإرسال صفحات الويب لمن يطلبها. إذا كتبتَ محدِّد المواقع ذاك في شريط عنوان المتصفح، فسيحاول المتصفح جلب المستند الذي في ذلك الرابط وعرضه، فيبدأ بالنظر في العنوان الذي يشير إليه eloquentjavascript.net، ثم يستخدِم بروتوكول HTTP ليحقق اتصالًا بالخادم الذي في ذلك العنوان ويطلب المورِد ‎/13_browser.html، وإذا تم ذلك كله فسيرسل الخادم حينئذ مستندًا يعرضه لك المتصفح على الشاشة. HTML تُهيأ صفحات الويب التي تراها أمامك على الشاشة بتنسيق يتكون من تراكيب محددة، واللغة التي نكتب بها تلك التراكيب اسمها HTML أو Hypertext Markup Language وتعني لغة ترميز النصوص الفائقة، ويحتوي المستند العادي المكتوب بهذه اللغة على نصوص ووسوم tags، وتحدد التركيب البنائي لتلك النصوص كما تصف الأنواع المختلفة لها سواءً كانت روابط أو فقرات أو عناوين، وتبدو هذه اللغة هكذا: <!doctype html> <html> <head> <meta charset="utf-8"> <title>My home page</title> </head> <body> <h1>My home page</h1> <p>Hello, I am Marijn and this is my home page.</p> <p>I also wrote a book! Read it <a href="http://eloquentjavascript.net">here</a>.</p> </body> </html> توفِّر الوسوم معلومات عن بنية المستند وتحاط بقوسين محددين هما رمزا "أصغر من" و"أكبر من" في الرياضيات كما ترى في المثال أعلاه؛ أما بقية النص فيكون نصًا عاديًا، كما يبدأ المستند بوسم ‎<!doctype html>‎ الذي يخبر المتصفح أن يفسر الصفحة وفق لغة HTML الحديثة وليس الإصدارات القديمة المختلفة منها والتي تكون عادةً قبل HTML5. تمتلك مستندات HTML في الغالب ترويسةً head ومتن body، كما تحتوي الترويسة على معلومات عن المستند؛ أما المتن فيحتوي على النصوص التي في المستند نفسه، وفي هذه الحالة تقول الترويسة أنّ عنوان هذه المستند هو "My home page" وأنها تستخدِم ترميز UTF-8 الذي هو أسلوب نتبعه لترميز نصوص اليونيكود على أساس بيانات ثنائية. يحتوي متن المستند على ترويسة واحدة، وهي <h1> التي تعني الترويسة الأولى، و<h2> حتى <h6> لتشير إلى ترويسات فرعية، كما يحتوي على فقرتين اثنتين محدَّدتين بوسم <p>. تأتي الوسوم في أشكال كثيرة، فيبدأ العنصر مثل المتن أو الفقرة أو الرابط بوسم افتتاحي مثل <p>وينتهي بوسم غالق مثل ‎</p>‎، وقد تكون بعض الوسوم الافتتاحية فيها معلومات أكثر مثل وسم <a> في صورة أزواج من name="value"‎، وتسمى هذه المعلومات بالسمات attributes، وفي حالتنا فإن وجهة الرابط توضَّح بالآتي: href="http://eloquentjavascript.net"‎ وتشير href هنا إلى مرجع لنص فائق hypertext reference. قد لا تغلف بعض الوسوم أيّ شيء ولا تحتاج إلى إغلاقها، ويُعَدّ وسم البيانات الوصفية metadata الذي يأتي بصورة الآتية مثالًأ على ذلك: ‎<meta charset="utf-8">‎ إذا أردنا كتابة أقواس محددة <> داخل نص مستند لتظهر كما هي من غير تفسيرها على أنها محددات وسوم، فيجب كتابتها بصيغة خاصة بها، بحيث يُكتب القوس الابتدائي ‎<‎ الذي يمثل علامة "أقل من" في الرياضيات على الصورة ‎&lt;‎، وكذلك القوس الغالق ‎>‎ الذي يمثل علامة أكبر من في الرياضيات على الصورة ‎&gt;‎. وهكذا، نكتب محرف آمبرساند & ثم اسم المحرف أو رمزه ثم فاصلة منقوطة ;، وتُعرف هذه الصيغة باسم الوحدة entity، حيث تُستبدَل بالمحرف الذي تعبِّر عنه، وذلك مشابه للطريقة التي تُستخدَم بها الشرطة المائلة العكسية في سلاسل جافاسكربت النصية. بما أنّ هذه الآلية تعطي معنى خاصًا لمحارف &، فإنها بذاتها تحتاج إلى تهريب بأن تُكتب ‎&amp;‎ لتظهر بصورتها إذا احتجنا إلى إظهارها في النص، وبالمثل لما بين قيم السمات المغلفة بعلامات تنصيص مزدوجة، إذ يمكن استخدام ‎&quot;‎ لإدخال محرف علامة التنصيص ليظهر بصورته. تُحلَّل HTML بأسلوب يتسامح كثيرًا مع الأخطاء، فإذا كان أحد الوسوم مفقودًا من موضع ما أو نسينا كتابته، فسيكتبه المتصفح ليعالج الخلل، وقد اعتُمِد الأسلوب الذي يحدث به ذلك بحيث تستطيع الاعتماد على جميع المتصفحات الحديثة التي تفعل الشيء نفسه لمعالجة أخطاء الكتابة. انظر المستند التالي الذي سيعامَل على أنه المستند الذي كتبناه في المثال أعلاه رغم أخطاء الصياغة والبناء التي فيه: <!doctype html> <meta charset=utf-8> <title>My home page</title> <h1>My home page</h1> <p>Hello, I am Marijn and this is my home page. <p>I also wrote a book! Read it <a href=http://eloquentjavascript.net>here</a>. عرف المتصفح قد أنّ وسوم <html> و<head> و<body> ليست موجودة، وعرف أنّ الوسمين <meta> و<title> ينتميان إلى الترويسة، والوسم <h1> تعني أنّ متن المستند بدايته من هنا. كما لم يعد هناك حاجة إلى إغلاق الفقرات بصورة صريحة بما أنّ بدء فقرة جديدة أو إنهاء المستند سيغلقها ضمنيًا، ولعلك لاحظت إن كنت منتبهًا إلى أن علامات التنصيص التي حول قيم السمات ليست موجودة أيضًا. سنهمِل في هذه السلسلة وسوم <html> و<head> و<body> من الأمثلة للاختصار ولإبقاء الأمثلة بسيطة، لكن سنغلق الوسوم ونضيف علامات التنصيص حول السمات، كما قد نهمِل تصريح doctype وcharset، لكن لا يعني هذا أننا نشجعك على ذلك، فقد تجد المتصفح يتصرف بغرابة ويفعل أشياءً سخيفةً إذا أهملتها، لذلك نريدك أن تتصرف كما لو كانت البيانات الوصفية الخاصة بهما موجودة في الأمثلة حتى لو لم تكن ظاهرة فعلًا في النص أمامك. HTML وجافاسكربت ما يهمنا في HTML فيما يتعلق بهذه السلسلة هو وسم <script>، إذ يسمح لنا بإدخال شيفرة جافاسكربت داخل المستند. <h1>Testing alert</h1> <script>alert("hello!");</script> ستعمل مثل تلك الشيفرة عندما يرى المتصفح وسم <script> أثناء قراءة HTML، وستُظهر الصفحة نافذة منبثقة حين تُفتح، كما تُشبه دالة alert في المثال أعلاه prompt إلا أنها تخرج نافذة منبثقة تعرض رسالةً ما دون طلب إدخال أي بيانات. يمثِّل المثال السابق برنامجًا صغير الحجم؛ أما إدخال برامج كبيرة مباشرةً في HTML فهو غير عملي، وبدلًا من ذلك يمكن تزويد وسم <script> بسِمة src لجلب ملف سكربت خارجي من رابط URL ما، وهو ملف نصي يحتوي على برنامج جافاسكربت. انظر المثال التالي حيث يحتوي ملف code/hello.js على البرنامج السابق نفسه alert("hello!")‎. <h1>Testing alert</h1> <script src="code/hello.js"></script> حين تشير صفحة HTML إلى روابط أخرى لتكون أجزاء منها مثل صورة أو ملف سكربت، فستجلبها المتصفحات مباشرةً أثناء تحميل الصفحة لتعرضها لك مع الصفحة نفسها في الأماكن التي حددها ملف HTML. يجب إغلاق وسم <script> دومًا بوسمه الغالق ‎‏‎<‏‏‏‎/‎script‎‏‏‎‎‏‎‏‏‏>‎ حتى لو كان يشير إلى ملف سكربت لا يحتوي أي شيفرة، فإذا نسيت ذلك، فسستُفسَّر بقية الصفحة على أنها جزء من السكربت. تستطيع تحميل وحدات ES -التي وردت في مقال الوحدات Modules في جافاسكريبت- في المتصفح بتزويد وسم script بسِمة type="Module"‎، كما يمكن أن تعتمد مثل هذه الوحدات على وحدات أخرى باستخدام روابط متعلقة بها على أساس أسماء وحدات في تصريحات import. كذلك يمكن لبعض السمات أن تحتوي على برنامج جافاسكربت، فالوسم <button> الذي في المثال التالي والذي سيُظهر زرًا به سمة onclick، كما ستعمل قيمة السمة في كل مرة نضغط على الزر فيها. <button onclick="alert('Boom!');">لا تضغط هنا</button> لاحظ أننا اضطررنا لاستخدام علامات تنصيص مفردة للسلسلة النصية التي في سمة onclick لأن العلامات المزدوجة كانت مستخدِمة سلفًا للسمة ككل، لكن كان بإمكاني أن أستخدم ;quot‏&‎ كذلك. داخل صندوق الاختبارات sandbox لا شك أنّ تشغيل البرامج المحمَّلة من الإنترنت قد يكون خطيرًا، إذ أنك لا تدري مَن وراء أغلب المواقع التي تزورها، وقد يكون فيهم الخبيث واللئيم، كما أنه لا نريد اختراق حواسيبنا بسبب إغفالنا لأمر مثل هذا، لكن الجميل في الموضوع هنا أنك تستطيع تصفح الويب دون الحاجة إلى توكيد الثقة في كل صفحة تزورها، لهذا فإنّ المتصفحات تحدّ كثيرًا من الصلاحيات التي تكون لبرامج جافاسكربت، فلا تستطيع النظر في الملفات التي على حاسوبك أو تعديل أي شيء غير متعلق بالصفحة التي هي فيها. ويسمى هذا العزل لتلك البرامج بصندوق الرمل أو صندوق الاختبار Sandbox، وإن كانت الترجمة الحرفية له هي صندوق الرمل إلا أنّ وظيفته هي عزل البرمجيات التي لا نثق فيها إلى حين البَت في أمرها أو تنتفي الحاجة إليها، وتعمل هذه البرامج كما تشاء داخل هذا الصندوق دون أذى للحاسوب نفسه أو لبياناتك، فلو كان هذا الصندوق قفصًا حديديًا سميك الجدران، فستكون البرامج حينها هي الكائنات التي تعبث فيه كما تشاء دون أن تؤذي من هو خارج القفص، ودون أن تستطيع هي نفسها الخروج. لكن الأمر الصعب عند التعامل مع هذا الصندوق هو السماح لهذه البرامج بفسحة تكفي لتكون مفيدةً مع حجزها عن التسبب في أذى للحاسوب والبيانات التي عليه في الوقت نفسه، لكن احذر أن تشمل هذه الفسحة أمورًا مثل التواصل مع الخوادم الأخرى وقراءة محتويات حافظة النسخ واللصق، فهنا قد يتطور الأمر إلى منحى خطير على الخصوصية. قد يخرج علينا أحد بين الحين والآخر بطريقة جديدة للتحايل على حدود المتصفح والتسبب في اختراق وأذى للمستخدم من تسريب معلومات طفيفة عنه حتى السيطرة التامة على الجهاز المخترَق، كما يستجيب مطورو المتصفحات لهذه التهديدات بإصلاح الثغرات التي تتسبب فيها إلى حين ظهور مشكلة جديدة، لكن مكمن الخطر هنا هو عدم إدراك المطورين للمشكلة إذا لم تُفضَح وتنتشر، فإذا استغلها أحد أو شركة أو منظمة أو جهة حكومية دون الإبلاغ عنها فستكون هنا الخسائر المحتملة أكبر. التوافقية وحروب المتصفحات كان المتصفح المسيطر على الساحة في بدايات الويب يسمى موزايك Mosaic، ثم انتقل السوق إلى متصفح نِت سكيب Netscape الذي ما لبث أن أفرغ الساحة قهرًا لمتصفح إنترنت إكسبلورر Internet Explorer الشهير الخاص بمايكروسوفت. كانت الجهة التي تقف خلف المتصفح في كل مرة تشعر أنّ لها الحق في اختراع المزايا الجديدة التي تشاء للويب، وبما أن أغلب المستخدِمين كانوا يستخدِمون متصفحها، فستضطر المواقع إلى استخدام تلك المزايا مع غض النظر عن باقي المتصفحات، وهذا سبب الكثير من مشاكل التوافقية للمواقع مع المتصفحات المختلفة. نستطيع القول أنّ هذا كان هو العصر المظلم للتوافقية، والذي كان يُعرف بعصر حروب المتصفحات، كما كان المطورون يجدون أنفسهم بين منصتين أو ثلاث لا تتوافق أي منها مع الأخرى بدلًا من ويب واحدة، وزاد الطين بلة امتلاء المتصفحات التي كانت في السوق في بداية الألفية الثالثة -نحو 2003- بالزلات البرمجية Bugs والمشاكل، وكل متصفح له مشاكله، وهكذا كانت حياة المطورين أشبه بالحرب فعليًا. ظهر بعد ذلك متصفح موزيلا فاير فوكس Mozilla Firefox، وهو فرع لا يهدف للربح من نِت سكيب ليبارز إنترنت إكسبلورر في السوق في أواخر عام 2002، وقد سيطر على حصة كبيرة من السوق لعدم اهتمام مايكروسوفت بمتابعة التطوير وزهدها في مجال المتصفحات حينها، ثم خرجت جوجل بمتصفح خاص بها هو جوجل كروم Chrome، وكذلك شركة آبل بمتصفح سفاري Safari الذي اكتسب شهرةً بسبب أنه يأتي مع أجهزتها تلقائيًا، وبالتالي صار لدينا أربعة متصفحات رئيسية على الساحة بدلًا من واحد فقط. اتجهت هذه الهيئات الأربعة نحو وضع معايير موحَّدة وأساليب هندسية أفضل لتصميم هذه المتصفحات، لتعطينا متصفحات لا تعاني كثيرًا من الزلات البرمجية ولا مشاكل التوافقية، وقد رأت مايكروسوفت مؤخرًا أنّ حصتها في هذا السوق قد تهاوت كثيرًا، فتبنّت هذا الرأي في النهاية في متصفح إيدج Edge الخاص بها واستبدلت به متصفحها القديم. يصب كل هذا في مصلحة من يقرِّر تعلم تطوير الويب هذه الأيام، إذ أن الإصدارات الأخيرة من هذه المتصفحات تكاد تتصرف بالأسلوب نفسه تقريبًا وليس لديها الكثير من الزلات البرمجية. ترجمة -بتصرف- للفصل الثالث عشر من كتاب Elequent Javascript لصاحبه Marijn Haverbeke. اقرأ أيضًا المقال السابق: مشروع بناء لغة برمجة خاصة ما هي البرمجة ومتطلبات تعلمها؟ هيكل البرنامج في جافاسكريبت اكتشاف دعم المتصفحات لميزات HTML5 تنسيقات المتصفحات المخصصة ودعمها وأداءها في CSS

يُعتبر مبدأ المسؤوليّة الواحدة Single Responsibility Principle (أو اختصارًا SRP) المبدأ الأوّل من مبادئ التصميم SOLID، وهو مفيد بصورة خاصّة في التصميم كائنيّ التوجّه object-oriented design. يعتمد هذا المبدأ على تجزئة مكوّنات النظام البرمجي بحيث يكون لكلّ جزء منه مهمّة (مسؤوليّة) واحدة ووحيدة. ينص هذا المبدأ على ما يلي: لا يظهر من النص السابق أي إشارة مباشرة إلى المسؤوليّة الواحدة. لتوضيح الربط بين المسؤولية الواحدة وبين نص المبدأ السابق، لننظر إلى المثال التالي الذي يحوي صنفًا مكتوبًا بلغة ++C ويُستخدم للاتصال بخادوم قواعد بيانات MySQL. اسم هذا الصنف MySQL أيضًا، ويمتلك واجهة لتأسيس الاتصال مع خادوم MySQL وإغلاقه، وإرسال استعلامات SQL إلى الخادوم واستقبال ومعالجة النتائج: class MySQL { public: bool connect(); void disconnect(); bool executeQuery(std::string queryString); MySQLResult* getQueryResult(); }; من الواضح أنّ لهذا الصنف مهمّتان أساسيّتان، الأولى هي إدارة عملية الاتصال مع خادوم MySQL (فتح وإغلاق الاتصال) والثانية هي التواصل مع الخادوم في إجراء الاستعلامات واستقبال النتائج (تنفيذ استعلامات SQL). لو افترضنا الآن حدوث السيناريو التالي: أصبح خادوم MySQL يقبل الاتصالات المشفّرة فقط. حدثت بعض التغييرات ضمن الخادوم بحيث أنّه بدأ بالاستجابة بشكل مختلف لبعض الاستعلامات. سيؤدي ذلك بالطبع إلى حدوث تغييرين ضمن صنف MySQL السابق، أو بمعنى آخر، سيكون هناك سببان لتغيير الصنف MySQL. ويُعدّ هذا خرقًا لمبدأ المسؤولية الواحدة كما هو واضح. يُعتبر وضع أكثر من مهمّة قابلة للتغيير (من أجل سبب ما) لأحد الأصناف خطأً تصميميًّا. قد لا تبدو تلك مشكلةً في الوقت الحالي، ولكن أيّ نظام برمجي يتغيّر ويتطوّر. فما يبدو حلًّا مقبولًا في الوقت الحاضر، قد يُفضي إلى نتائج سيّئة في المستقبل. يمكن استخدام الحل التالي لمشكلتنا السابقة: class MySQLConnection { public: bool open(); /* former connect() */ void close(); /* former disconnect() */ }; class MySQLQuery { MySQLConnection* session; public: bool execute(std::string queryString); MySQLResult* getResult(); }; يبدو مبدأ المسؤوليّة الواحدة بسيطًا، ولكنّه في الحقيقة صعب التطبيق. والسبب في ذلك، هو أنّ وضع المسؤوليّات المتعدّدة لصنف ما معًا، هو أمر بديهي ومألوف بالنسبة إلينا، أمّا عملية الفصل والتجزئة إلى أصناف أصغر لكلٍّ منها مسؤوليّة واحدة، فقد لا تبدو جذّابةً أوّل الأمر. بالنسبة لي، عندما عدت وراجعت بعض تصميمات الأصناف القديمة لديّ، قلّما وجدت صنفًا من الممكن جعله يراعي هذا المبدأ. ولكن عندما أمعنت النظر والتفكير وجدت أنّ الفصل في المهام سيقلّل من تعقيد التصميم، وسيجعل الشيفرة أيسر للقراءة والفهم. بالمقابل، فإنّ تطبيق هذا المبدأ بشكل صارم، ليس فكرةً جيّدة. فعلى المرء أن يكون حكيمًا في تحديد متى يمكن تطبيق هذا المبدأ، وخصوصًا عندما يجد أنّ الملف الخاص بأحد أصنافه بات يحتوي على أكثر من 500 سطر من الشيفرة البرمجيّة! ترجمة -وبتصرّف- للمقال Single Responsibility Principle لصاحبه Radek Pazder.

يُعتبر مبدأ الفتح والإغلاق Open/Closed Principle أو اختصارًا OCP، من المبادئ التي تساعد مطوّري البرمجيّات على تحقيق تصاميم برمجيّة عالية الجودة. على أيّة حال، قد يكون من الصعب أحيانًا أن نوضّح ما الذي نعنيه بالبرمجيّات عالية الجودة. بالعودة إلى المبدأ OCP، يعود الفضل إلى برتراند ماير في وضع مصطلح مبدأ الفتح والإغلاق، حيث ظهر أوّل الأمر في كتابه البنية كائنيّة التوجّه للبرمجيّات "Object Oriented Software Construction" ينص هذا المبدأ على ما يلي: الذي يعنيه هذا المبدأ، هو أنّنا عندما نُصمّم جزءً من تطبيق برمجي، فإنّه من الضروري أن نضع في حسباننا إمكانيّة التوسّع المستقبليّ، فكلّنا يعلم أنّ المتطلّبات الخاصّة بالزبائن تتغيّر على الدوام وبسرعةٍ كبيرة. لذلك فإنّ الشيفرة البرمجيّة ستتغيّر وتتوسّع لتلبّي المزيد من المتطلّبات والمزايا، وقد لا يؤدّي هذا الأمر على الدوام إلى عواقب حميدة على الصعيد البرمجي. الهدف الذي يُنشده هذا المبدأ هو أن ننظر إلى المستقبل (ابنِ الآن، وخطّط للمستقبل) بحيث نصمّم تطبيقاتنا البرمجيّة بحيث لا تحتاج إلى تغيير في الشيفرة المكتوبة مسبقًا عند إضافة مزايا ووظائف جديدة إليها. لندع الشيفرة البرمجيّة تُعبّر عن نفسها مع المثال التالي: def area(geometric_entity): if geometric_entity.type() == SQUARE: return geometric_entity.a * geometric_entity.a elif geometric_entity.type() == CIRCLE: return PI * geometric_entity.r * geometric_entity.r else: raise UnknownEntityError("I literally have no idea.") قد توحي الشيفرة السابقة بالبساطة أوّل الأمر، ولكنّها تُظهر جانبًا أساسيًّا من مبدأ OCP. فإذا أردنا مثلًا أن تدعم الدالّة السابقة إمكانية حساب مساحة مستطيل فيمكن ذلك بسهولة وذلك بإضافة مقطع elif جديد. ولكن بالمتابعة على هذا المنوال، وفي حالة حساب مساحة شكل هندسي غير قياسي، فستتحول الأسطر البرمجيّة البسيطة السابقة إلى ما يزيد عن 1500 سطر برمجي لحساب مساحة هذا الشكل باستخدام تكامل ريمان Riemann Integral، مما سيجعل هذه الأسطر كوحش برمجيّ إذا لم يلتهمك، فإنّ مدير المشاريع سيفعل ذلك حتمًا! النقطة التي نريد الوصول إليها، أنّه في كلّ مرّة نريد فيها إحداث تغيير في البرنامج لدعم مزايا جديدة، فإنّه من الممكن أن يؤدّي هذا التغيير إلى مشاكل في عمل المزايا القديمة التي كانت تعمل بشكل جيّد أصلًا، وهذا أمر غير مرغوب بالطبع. وهذا ما يحذّرنا منه مبدأ OCP، فيجب أن تكون العناصر البرمجيّة مفتوحة للتوسعة (دعم مزايا إضافيّة) ولكنها مغلقة للتعديل (عدم الحاجة إلى تعديل الشيفرة التي تدعم المزايا القديمة). قد يتبادر إلى ذهن البعض أنّه في حالة حدوث مشاكل جرّاء هذا التعديل فمن الممكن إصلاحها باستخدام وحدات الاختبار unit tests ومنقّحات الأخطاء debuggers، ولكن لماذا نلجأ لمثل هذه الأساليب إذا كان بإمكاننا تجنّبها أصلًا؟ فدرهم وقاية خير من قنطار علاج. وكما أنّه من الصعب وضع تعريف رسميّ لمعيار الجودة للبرمجيّات، فكذلك الأمر بالنسبة لهذه المبادئ. فلا توجد قواعد صارمة للتقيّد بها، فكل شيء يعود للخبرة الشخصيّة والتخطيط الجيّد. ترجمة -وبتصرّف- للمقال Open/Closed Principle in Software Design لصاحبه Radek Pazdera.

مبدأ آخر من مبادئ التصميم الكائنيّ التوجّه ضمن مبادئ SOLID يُطلق عليه اسم مبدأ ليسكوف للاستبدال Liskov Substitution Principle ويُرمز له اختصارًا بالرمز LSP. سنبدأ هذا المبدأ بشيء من المفاهيم النظريّة. صاحبة هذا المبدأ هي البروفسور باربارا ليسكوف، وقد طرحته أوّل الأمر عام 1987 وكان ينص على ما يلي: قد يبدو الكلام السابق مبهمًا بعض الشيء، يمكننا توضيحه بالشكل التالي: "إذا استطعنا استبدال كل كائن O1 مكان كائن O2 فمن الممكن الجزم بأنّ S هو نوع فرعي (نوع ابن) للنوع T". ولكن في بعض الأحيان رغم أنّ S هو نوع فرعي للنوع T ولكن لا يمكن الاستبدال بين كائناتهما بالصورة الموضّحة قبل قليل وهذا بالطبع أمر غير جيّد. أعادت باربارا ليسكوف بالاشتراك مع جانيت وينغ Jeannette Wing صياغة المبدأ السابق بشكل مختصر أكثر في عام 1994 ليصبح على الشكل التالي: المقصود هنا أنّه إذا كانت خاصيّة أو دالّة (طريقة method) تعمل ضمن كائنات من النوع T، فينبغي أن تعمل أيضًا وبنفس الصورة ضمن كائنات من النوع S بحيث أنّ النوع S هو نوع ابن للنوع T. وهذا هو مبدأ ليسكوف للاستبدال الذي وصفه روبرت مارتن لاحقًا بصورة أكثر عمليّةً في إحدى مقالاته على الشكل التالي: بعد كلّ هذه المقدّمة النظريّة ثقيلة الظلّ بعض الشيء، ينبغي أن نُدعّم المفاهيم النظريّة السابقة ببعض الأمثلة التي توضّحها بالشكل المناسب. واحد من هذه الأمثلة التي تخرق هذا المبدأ هو تمثيل العلاقة بين المستطيل والمربّع بشكل كائنيّ. من البديهي تمامًا أن يكون لدينا صنف اسمه Square (مربّع) يكون صنفًا ابنًا للصنف Rectangle (مستطيل)، فمن الناحية الرياضيّة يُعتبر المربّع حالة خاصّة من المستطيل، فهو مستطيل تساوى فيه بعداه. لنعبّر في البداية عن الصنف Rectangle برمجيًّا بالشكل التالي: class Rectangle { int width; int height; public: int getWidth() { return width; } int getHeight() { return height; } virtual void setWidth(int value) { width = value; } virtual void setHeight(int value) { height = value; } }; وبما أنّ المربّع هو حالة خاصّة من المستطيل كما أسلفنا، فيمكن كتابة الصنف Square مع إعادة تعريف الطريقتين setWidth و setHeight: class Square : public Rectangle { public: void setWidth(int value) { width = value; height = value; } void setHeight(int value) { width = value; height = value; } }; سيضمن هذا التعديل على الطريقتين setWidth و setHeight ضمن الصنف Square أنّ أي كائن (مربّع) ننشئه من الصنف Square ستكون أضلاعه الأربعة متساوية الطول. لننظر الآن إلى الدّالة التالية التي سنستخدمها لتجريب البنية الكائنيّة السابقة: bool test(Rectangle &rectangle) { rectangle.setWidth(2); rectangle.setHeight(3); return rectangle.getWidth() * rectangle.getHeight() == 6; } تقبل الدّالة test تمرير كائن من النوع Rectangle أو كائن من النوع Square، وهذا جائز بالطبع لأنّ Square هو نوع ابن للنوع Rectangle. السؤال هنا هو ماذا سيحدث عند تمرير كائن من النوع Square إلى الدّالة test؟ ستُعيد الدّالة القيمة false رغم أنّ التقييم يجري على مرجع من النوع Rectangle (وسيط الدّالة). المشكلة هنا أنّه رغم أنّ المربّع هو مستطيل من الناحية الرياضيّة إلّا أنّه لا يتشارك السلوك نفسه معه. وهذا يُعتبر خرقًا واضحاً لمبدأ الاستبدال. فالكائنات من النوع Rectangle لا يمكن أن يتمّ استبدالها بكائنات من النوع Square رغم أنّ النوع Square هو نوع ابن للنوع Rectangle، لأنّ ذلك سيؤدّي إلى تغيّر في سلوك الطرائق الموجودة ضمن الصنف Rectangle كما هو واضح. لقد أوضح برتراند ماير هذه المسألة أيضًا على الشكل التالي: الإجراء من النص السابق قد يكون دالة أو طريقة method. الشروط البادئة هي الشروط التي يجب أن تتحقّق كي يتم استدعاء الطريقة وتنفيذها، أمّا الشروط اللّاحقة فهي محقّقة دومًا بعد انتهاء تنفيذ الطريقة. فالّذي قصده برتراند ماير هو أنّه عند إعادة كتابة تابع في صنف ابن يرث من صنف أب، يجب ألّا تكون الشروط البادئة أقوى من الشروط البادئة للطريقة الأصليّة (الموجودة في النوع الأب)، كما يجب ألّا تكون الشروط الّلاحقة أضعف من الشروط الّلاحقة للطريقة الأصليّة. في مسألتنا السابقة (مسألة المربّع والمستطيل)، لم تكن هناك أيّ شروط بادئة، ولكن كان هناك شرط لاحق للطريقة setHeight وهو أنّ هذه الطريقة يجب ألّا تُغيّر العرض width، وهذا الشرط تمّ خرقه (أصبح أضعف) عندما أعدنا تعريف الطريقة setHeight ضمن النوع Square. تُعتبر الوراثة في الحقيقة مفهومًا قويًّا ومحوريًّا في التصميم كائنيّ التوجّه، ولكن من السهل الوقوع في الأخطاء إذا لم نطبّق مبدأ ليسكوف للاستبدال، فقد تجد أنّ تصميمك الكائنيّ جيّد ومقنع، ولكن سرعان ما ستقع في المتاعب إذا لم تراعي هذا المبدأ. ترجمة -وبتصرّف- للمقال Liskov Substitution Principle لصاحبه Radek Pazdera.