قبل م نبدأ اقرأ الي قبل دا من هنا
و لو جاي علشان نشرح ال repo pattern ف لا لسه شوية خلينا ماشين مع الكتاب اتفقنا و يلا نكمل CH1
الـ core code هو الكود اللي تقدر تشغله في أي مكان، من غير ما تحتاج تكون مجهز بيئة معينة أو محمل إعدادات خاصة.
لكن الكود اللي محتاج سياق معين أو إعدادات مسبقة علشان يشتغل، ده بقى مش core code.
تيجي نشوف مع بعض أمثلة على كود محتاج Context مخصوص:
كل الأمثلة دي بتوضح إن الكود محتاج سياق مخصوص علشان يشتغل، وده بيكسر القاعدة رقم 2. ف و انتا بتقرأ اسأل السؤال دا
مثال 1 : مش هتشتغل إلا لو كانت ضمن request حقيقي جاي من HTTP، وده معناه إنها مش مستقلة.
مثال 2 : معتمدة على إن Zend_Registry يكون متحدد قبل كده، يعني برضو محتاجة إعداد.
بتشتغل بس في بيئة معينة (command-line)، وده بيخالف القاعدة.
زي م ذكرتلك فوق كل دول كل الأمثلة دي بتوضح إن الكود محتاج سياق مخصوص علشان يشتغل، وده بيكسر القاعدة رقم 2.
لو توهت مني شوية تعالي نسأل سؤال حلو هيفهمنا الليلة دي كلها
هل الكود ده ينفع يشتغل في أي مكان؟ ولا لازم سياق معين علشان يشتغل؟
لو الإجابة:
"آه، يشتغل في أي مكان" → يبقى ده core code
لكن لو الإجابة:
"لأ، محتاج تهيئة أو سياق معين" → يبقى مش core code حتى لو شكله بسيط أو بيشتغل "تقنيًا".
المثال دا مهم جدا هيفهمك اكتر ف ركز معايا ضروري
اقرأ كلامي الجاي كويس جدا جدا جدا جدا لو ركزت هتلاقي
ال function هنا مش بتستخدم حاجة "غريبة" أو مكسّرة القواعد بشكل واضح،
بس هي مصممة علشان تشتغل في بيئة ويب،
فلو حاولت تشغلها في بيئة تانية (زي CLI أو test suite) هتبقى awkward أو مش عملي.
يعني الكود شكله نظيف،
بس تصميمه نفسه بيخليه مربوط بسياق معين. علشان كده مش نعتبره core code حتى لو معتمدش على global state أو حاجة صريحة.
دلوقتي نقدر نقول إن الكود يبقى core code لو اتحققت التلات شروط دول:
ولو أي شرط من التلاتة دول مش متحقق → يبقى ده مش core code.
دلوقتي انتا عاوز تعرف امثلة علي الcore code
بقا حاضر هتكون ف المقالة الجاية و معاها ال summary كمان و نكون خلصنا ch1 كامل و نبدأ ف الجد بقا ان شاء الله
