أهم 25 دالة للتعامل مع الـ Strings في JavaScript 💯
.
.

25 JavaScript String Methods Cheat Sheet - Part 1 💡

1. length
2. charAt()
3. charCodeAt()
4. toUpperCase()
5. toLowerCase()
6. slice()
7. substring()
8. trim()
9. trimStart()
10. trimEnd()
11. String.concat()
12. endsWith()

———

وفقكم الله لكل خير 🌿

دردشة سريعة عن الـ Shadow DOM 💡
.
.
تخيل معايا أنك شغال على مشروع ضخم، وعامل Components Modular، بس فجأة حصلت كارثة! الـ CSS اللي كتبته لـمكون (Component) معين بقى بيأثر على مكونات (Components) تانية في الصفحة، والـ JavaScript بدأ يدخل في متاهات بسبب الـ Global Scope. الحل؟ هنا بييجي دور Shadow DOM!

تعال ندردش شوية عن Shadow DOM، إزاي بيشتغل، ليه هو مهم، وإزاي تستخدمه عمليًا في مشاريعك...🔥

———

📍 LinkedIn

https://www.linkedin.com/posts/dev-alisamir_webdeveloper-webdevelopment-devabrguide-activity-7303859163757957121-bwdh

📍 Qabilah

https://qabilah.com/posts/pXMvwi8VKXk

📍 Facebook

https://www.facebook.com/share/p/1A8EL2kmMj

———

وفقكم الله لكل خير 🌿

الـ Asynchronous Programming في JavaScript ⚙️
.
.
البرمجة فيها نوعين أساسيين: Synchronous و Asynchronous، ولما نفهم الفرق بينهم، هيبقى أسهل نعرف ليه الـ Asynchronous مهم جدًا.

📌 الـ Synchronous Programming:

ده يعني إن الكود بيتنفذ خطوة بخطوة، بمعنى إن الكود مبيكملش تنفيذ أي خطوة تانية إلا لما الخطوة اللي قبلها تخلص. يعني لو عندك عملية بتاخد وقت زي إنك بتحمل بيانات من السرفر عن طريق الـ API، الكود هيفضل مستني لحد ما البيانات تتحمل قبل ما يكمل باقي التنفيذ.

📌 الـ Asynchronous Programming:

أما في البرمجة الـ Asynchronous، الكود يقدر ينفذ حاجات كتير في نفس الوقت من غير ما يستنى العملية الطويلة تخلص. يعني لو عندك عملية زي تحميل البيانات من السرفر، الكود ممكن يستمر في تنفيذ أكواد تانية، ولما البيانات تتحمل، الكود هيعرف ويتعامل مع النتيجة.

———

📌 إزاي الكلام ده بيحصل في JavaScript؟

في JavaScript، عندنا طريقتين رئيسيتين للتعامل مع الـ asynchronous programming

🔻 الـ Callbacks
🔻 الـ Promises

(وطبعًا async/await اللي هو تحسين للـ Promises)

———

📌 الـ Callbacks

أول طريقة للتعامل مع الـ asynchronous programming كانت عن طريق الـ Callbacks. الفكرة ببساطة إنك بتمرر دالة معينة كـ "callback" للكود اللي بيتنفذ، ولما الكود ده يخلص، الدالة دي بتشتغل.

لكن الـ callbacks بتتحول بسرعة لكود معقد جدًا لما يكون عندك عمليات كتير وبتحتاج تكتب حاجات كتير جوة بعضها، وده اللي بنسميه Callback Hell.

📌 الحل: الـ Promises

هنا بيجي دور الـ Promises، اللي هي طريقة جديدة وأكثر تنظيمًا للتعامل مع العمليات الـ asynchronous. الـ Promise هو في الأساس "وعد" إن العملية هتخلص في المستقبل.

الـ Promise بيكون ليه 3 حالات:

🔻 حالة الـ Pending: يعني العملية لسه مخلصتش.
🔻 حالة الـ Fulfilled: يعني العملية نجحت وطلعت النتيجة.
🔻 حالة الـ Rejected: يعني العملية فشلت وفيه خطأ حصل.

لما العملية تخلص بنجاح، الـ Promise بيتحول لحالة "fulfilled"، ولو العملية فشلت بيتحول لحالة "rejected".

———

خلينا نشوف مثال عشان نفهم الكلام ده بشكل أوضح. هنفترض إننا عايزين نحاكي عملية استرجاع بيانات من الـ API.

const fetchData = () => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const dataAvailable = true;

      if (dataAvailable) {
        resolve("Data retrieved successfully!");
      } else {
        reject("Error: Unable to retrieve data.");
      }
    }, 3000);
  });
};

fetchData()
  .then((result) => console.log(result))
  .catch((error) => console.log(error));

في الكود ده، الدالة fetchData بترجع Promise. داخل الـ Promise، بنستخدم إما resolve لو العملية نجحت أو reject لو حصل خطأ.

باستخدام then، بنقدر نتعامل مع النتيجة لو العملية نجحت، ولو حصل خطأ، الـ catch بتساعدنا في التعامل معاه.

———

📌 الـ Async/Await

علشان نخلي الكود أبسط وأوضح، ظهر حاجة اسمها async/await اللي بتشتغل على الـ Promises بس بشكل مبسط جدًا وبتخلي الكود يبان كأنه synchronous.

نفس المثال اللي اللي فات نقدر نكتبه بطريقة async/await بالشكل ده:

const fetchData = async () => {
  try {
    const result = await new Promise((resolve, reject) => {
      setTimeout(() => {
        const dataAvailable = true;
        if (dataAvailable) {
          resolve("Data retrieved successfully!");
        } else {
          reject("Error: Unable to retrieve data.");
        }
      }, 3000);
    });
    console.log(result);
  } catch (error) {
    console.log(error);
  }
};

fetchData();

الميزة هنا إننا استخدمنا await عشان نستنى النتيجة من الـ Promise وكأن العملية دي synchronous، لكن في الحقيقة الكود شغال بطريقة asynchronous.

وبدل ما نستخدم then و catch، استخدمنا try و catch علشان نتعامل مع النجاح أو الفشل.

———

📌 ليه تستخدم الـ Promises والـ Async/Await؟

✅ تنظيم الكود: الكود بيبقى أنضف وأبسط في الفهم مقارنة بالـ Callbacks.
✅ الـ Error Handling أفضل: التعامل مع الأخطاء بقى أسهل باستخدام try/catch.
✅ لما يكون عندك مشروع كبير، الـ async/await هيساعدك في إدارة الأكواد الطويلة والمعقدة بسهولة.

———

وفقكم الله لكل خير 🌿

يعني إيه Bearer Token وإزاي بيشتغل؟ 🤔

.
.
خليني أسألك سؤال... لما تدخل أي موقع ويطلب منك تسجيل الدخول، هل كل مرة بتفتح الموقع بيطلب منك اسم المستخدم والباسورد من الأول؟ "في الغالب" لا، لأنه بعد ما بتسجّل دخول بيتم إصدار Token تستخدمه بدل ما تدخل بياناتك كل مرة.

هنا بقى بييجي دور الـ Bearer Token... ده واحد من أشهر أنواع الـ Access Tokens واللي بيتم استخدامه في الـ authentication (وغالبًا مع معيار OAuth 2.0)، وده معناه إنك لما تبعت request لأي API محمي (Protected)، بدل ما تبعت بيانات تسجيل الدخول كل مرة، بتبعت الـ Token بيأكد إنك شخص موثوق.

بس خليني أقولك إن استخدام Bearer Token محتاج شوية تفاصيل لازم تبقى فاهمها كويس، لأن أي غلطة في التعامل معاه ممكن تخلي بياناتك عرضة للإختراق.
.
.
لا تنسوا أهلنا المستضعفين من الدعاء.
———

📌 إزاي الـ Bearer Token بيشتغل؟

الموضوع بيتم على 3 مراحل:

1- تسجيل الدخول: لما المستخدم بيدخل بياناته الصح، السيرفر بيعمله authenticate، وبعدها بيصدرله Bearer Token (ممكن يكون مشفر زي JWT).

2- استخدام الـ Token: في كل request بعد كده، الـ Token بيتبعت مع الهيدر (Header) في الـ Authorization بالشكل ده:

Authorization: Bearer YOUR_ACCESS_TOKEN

وده معناه إن أي حد معاه الـ Token يقدر يستخدمه للوصول للـ API

3- التحقق من الـ Token: السيرفر بيستلم الـ Token ويشوف إذا كان صالح ولا لا (ممكن بمفتاح تشفير لو مشفر)، ولو كان صحيح، بيكمل تنفيذ الطلب، ولو كان منتهي أو غير صحيح، بيرد بخطأ Unauthorized (401).

———

📌 طب ليه اسمه Bearer Token؟

كلمة Bearer معناها "حامل"، وده لأن أي حد معاه الـ Token ده يقدر يستخدمه من غير ما يثبت هويته بأي حاجة تانية. بمعنى إن الـ Token لو اتسرق، اللي سرقه هيقدر يستخدمه كأنه أنت بالضبط.

———

📌 إيه المشاكل الأمنية اللي ممكن تواجهك مع Bearer Token؟

💀 الـ Token Theft: لو حد قدر يحصل على الـ Token بتاعك، يقدر يستخدمه كأنه أنت، ومفيش extra verification زي الـ refresh tokens أو OAuth flows اللي بتتأكد إن الشخص فعلًا هو المستخدم الحقيقي.

⌛️ الـ Expiration Issues: لو الـ Token مش بيخلص بسرعة، يبقى عندك مشكلة، لأن أي حد يسرقه يقدر يستخدمه لمدة طويلة، عشان كده الـ Tokens بتبقى لها expiry time، وبعدها لازم تعمل refresh.

📡 الـ Man-in-the-Middle Attacks: لو الـ Token بيتبعت من غير encryption، ممكن حد يعترضه ويستخدمه، عشان كده لازم تتأكد إن كل حاجة بتتم تحت HTTPS مش HTTP

🔄 الـ Replay Attacks: لو مكنش فيه حماية زي timestamps، ممكن حد يستخدم الـ Token المسروق أكتر من مرة.

———

📌 إزاي تأمن الـ Bearer Token؟

✅ استخدم HTTPS: عشان تمنع أي حد من التجسس على الـ Token أثناء نقله.

✅ حدد مدة صلاحية قصيرة للـ Token: خلي الـ Token يخلص بعد فترة قصيرة عشان لو اتسرق، يبقى ملوش لازمة.

✅ استخدم Refresh Tokens: عشان المستخدم يقدر يحصل على Token جديد لما الـ Token القديم يخلص.

✅ خزن الـ Token في مكان آمن: في المتصفح، بلاش تخزنه في localStorage لأنه ممكن يتسرق بسهولة، استخدم HttpOnly Cookies لو أمكن.

✅ استخدم Scopes: لو بتستخدم API، متديش الـ Token صلاحيات أكتر من المطلوب، مثلًا متديلوش صلاحية إنه يمسح داتا لو هو بس هيقرأ بيانات.

✅ ظبط CORS كويس: عشان تمنع أي مصدر مش موثوق من استخدام الـ Token.

———

وفقكم الله لكل خير 🌿

برنامج ITIDA Gigs لتأهيل الشباب للعمل الحر

https://landing.eyouthlearning.com/index.php/digital-freelancing-placement-program

💡 الحل هو التطبيق العملي

في الـ Front-End، ممكن تبدأ بمشاريع بسيطة زي صفحة ويب شخصية أو آلة حاسبة، وبعدين تطور نفسك بمشاريع زي تطبيق إدارة مهام أو موقع إخباري بواجهة احترافية.

أما في الـ Back-End، ابدأ بمشاريع زي API بسيطة، ومع الوقت اشتغل على حاجات زي نظام إدارة مستخدمين أو تطبيق شات متكامل.

المهم تفضل تطبق عملي عشان المهارات اللي بتتعلمها تبقى ثابتة، وكل مشروع هتعمله هيرفع من مستواك واحدة واحدة لحد ما تبقى محترف.

دي مجموعة مشاريع في مجال الـ Front-End ومجال الـ Back-End هتنقلك من المستوى المبتدئ للمستوى الاحترافي

⚡️ مشاريع الـ Front-End

https://roadmap.sh/frontend/projects

⚡️ مشاريع الـ Back-End

https://roadmap.sh/backend/projects

الفرق بين الـ Monorepo والـ Multirepo 💯
.
.
تخيل أنك شغال على مشروع ضخم، عندك أكتر من فريق، وكل فريق بيشتغل على جزء مختلف. فجأة، تبدأ المشاكل تظهر: كود مكرر، صعوبة في التعديلات، تعارض بين الفرق، وأوقات ضايعة على الـ builds والـ pipelines.

المشكلة هنا ممكن تكون في الطريقة اللي بتنظم بها الكود بتاعك. 💡

هنا تبدأ تسأل نفسك: تختار Monorepo ولا Multirepo؟

كل طريقة لها ميزاتها وعيوبها، واختيارك ممكن يحسن شغلك بنسبة كبيرة أو يعقد حياتك لو اختارت الغلط.

تعال نوضح الفرق بينهم وامتى تختار الطريقة المناسبة...

———

📌 أولًا: يعني إيه Monorepo؟

الـ Monorepo ببساطة هي إنك تحط كل الكود الخاص بالمشروع بتاعك، بكل الـ components أو الـ modules اللي فيه، داخل Repository واحد.

يعني حتى لو عندك أكتر من خدمة (microservices) أو أكتر من مكتبة أو أكتر من تطبيق مرتبطين ببعض، كله بيكون في مكان واحد.

———

📍 مميزات الـ Monorepo:

- سهولة إدارة الكود: كل حاجة في مكان واحد، فلو عايز تعمل تغييرات على أكتر من جزء، هتبقى شايف الصورة الكبيرة بسهولة.

- إعادة استخدام الكود (Code Reusability): لو في مكتبة أو جزء معين من الكود محتاج تستخدمه في أكتر من موديول، تقدر تعمله بسهولة من غير duplication.

- تنسيق أفضل بين الفرق: كل فريق شايف الكود بتاع باقي الفرق، فده بيسهل التعاون بينهم وبيقلل تعارض التعديلات (conflicts).

- تكامل أفضل بين الأدوات: زي الـ CI/CD (Continuous Integration/Continuous Deployment) اللي بيشتغل بسهولة على مشروع واحد بدل ما يتقسم على أكتر من repository.

———

📍 عيوب الـ Monorepo:

- الحجم الكبير للـ repo: مع مرور الوقت وعدد المساهمين الكبير، حجم الـ repo بيكبر وده ممكن يبطّأ العمليات زي cloning أو حتى الـ builds.

- التعقيد في إدارة الصلاحيات: صعب تقول إن فلان يقدر يشتغل على جزء معين بس من غير ما يشوف الباقي.

- مشاكل مع الـ Tools: لو مش عندك أدوات قوية لإدارة الـ monorepo، ممكن تواجه مشاكل في التنظيم وعملية الـ build.

———

📌 ثانيًا: يعني إيه Multirepo؟

على العكس تمامًا، الـ Multirepo معناها إن كل جزء أو موديول من المشروع يكون في Repository خاص به. يعني كل موديول بيبقى مستقل بذاته وكأنه مشروع لوحده.

———

📍 مميزات الـ Multirepo:

- كل موديول ليه حياته الخاصة، وده بيخلي إدارة كل جزء مستقلة وأسهل لبعض الفرق.

- تقدر تحدد مين يشتغل على إيه بناءً على الـ repo اللي عندهم أكسس عليه.

- لو فيه موديول أو خدمة مش مرتبط بشكل مباشر، مش محتاج تبني كل المشروع، بس تبني الجزء اللي محتاجه.

- كل جزء بيكون صغير ومستقل، فده بيخلي العمليات زي cloning أسرع وأسهل.

———

📍 عيوب الـ Multirepo:

- تكرار الكود: لو فيه أكتر من موديول بيحتاج نفس الكود، ممكن تضطر تكرره أو تحط مكتبة منفصلة ليه.

- تعقيد في التنسيق بين الفرق: التعاون بين الفرق بيبقى أصعب، وخصوصًا لما يكون فيه dependencies كتير بين الـ modules.

- تكامل معقد للـ CI/CD: عشان كل جزء في Repository مختلف، هتحتاج إعدادات أكتر للـ pipelines عشان كل حاجة تشتغل مع بعض.

- صعوبة في إدارة التغييرات الكبيرة: لو عندك تغيير ضخم بيأثر على أكتر من موديول، هتحتاج تدخل على كذا repo وتعدل في كل واحد لوحده.

———

📌 امتى تختار مين؟

✅ اختر Monorepo لو:

1- مشروعك عبارة عن مجموعة modules مرتبطة ببعضها.

2- عندك فريق صغير أو متوسط.

3- بتحتاج تعمل تغييرات بشكل متكرر على أكتر من موديول في نفس الوقت.

4- الأدوات اللي بتستخدمها بتدعم إدارة monorepos بشكل كويس.


✅ اختر Multirepo لو:

1- مشروعك كبير جدًا ومعقد، وكل جزء فيه مستقل تمامًا.

2- بتحتاج تتحكم في الصلاحيات على مستوى كل موديول.

3- عندك فرق مختلفة كل فريق شغال على موديول خاص به.

4- عايز تتجنب المشاكل اللي بتسببها أحجام الـ repos الكبيرة.

———

القرار في الآخر بيرجع لطبيعة مشروعك واحتياجات فريقك. مفيش طريقة "صح" وطريقة "غلط"، لكن فيه طريقة مناسبة أكتر حسب ظروفك. أهم حاجة إنك تكون فاهم كل طريقة بتقدم إيه وعيوبها إيه. 💡

وفقكم الله لكل خير 🌿

دورة مجانية بعنوان: Power BI 101

تهدف هذه الدورة إلى التعرف على أساسيات Power BI، بدءًا من استيراد البيانات، إلى تمثيل البيانات وإنشاء التقارير وdashboard.

ستساعدك الدورة على اكتساب المهارات اللازمة لتمثيل البيانات وإنشاء تقارير فعّالة باستخدام Power BI.

https://satr.codes/course/OC6sfVMdl9/view

الـ MVC

نمط الـ MVC، أو Model-View-Controller، يعتبر من أشهر الأنماط المستخدمة في هندسة البرمجيات، وبيساعد على تنظيم الكود بشكل يخلي عملية تطوير وصيانة البرامج أبسط وأسهل.

———

طيب يعني إيه MVC؟ 🤔

الـ MVC بيتكون من 3 مكونات أساسية:

✅ الـ Model: الجزء ده هو اللي بيتعامل مع البيانات. الـ Model بيقوم بتخزين البيانات، معالجة البيانات، والتواصل مع قواعد البيانات.

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

✅ الـ View: وده المسئول عن كل اللي المستخدم بيشوفه قدامه على الشاشة. هو المسئول عن عرض البيانات اللي جهزها الـ Model.

يعني مثلًا لو عندك صفحة بتعرض المنتجات، فالـ View هو اللي بيحدد إزاي المنتجات هتظهر (الألوان، الشكل، الترتيب... إلخ).

✅ الـ Controller: وده الوسيط اللي بيعمل التنسيق بين الـ Model والـ View.

بمعنى تاني، هو اللي بيستقبل طلبات المستخدمين، زي لما تضغط على زرار أو تدخل بيانات في فورم، وبعدين يوجه الطلب للـ Model علشان يعالج البيانات، وفي الآخر يرجع البيانات دي للـ View علشان يعرضها.

———

مثال بسيط 🛠

تخيل إنك فاتح موقع للتسوق وعايز تشوف قائمة المنتجات:

⚡️ أول حاجة بتضغط على زرار "عرض المنتجات" – هنا الـ Controller بيستقبل الطلب ده.

⚡️ بعد كده، الـ Controller بيروح للـ Model علشان يجيب البيانات من قاعدة البيانات (قائمة المنتجات).

⚡️ الـ Model بيدور في قاعدة البيانات ويجيب المنتجات.

⚡️ بعد ما الـ Model يجهز البيانات، بيرجّعها للـ Controller اللي بدوره يبعتها للـ View.

⚡️ وأخيرًا، الـ View بيعرض المنتجات على الشاشة بالشكل المناسب اللي المستخدم يقدر يشوفه ويتفاعل معاه.

———

ليه تستخدم الـ MVC؟ 🤷‍♂️

📌 تنظيم الكود: بيخلي الكود منظم أكتر، بحيث تقدر تفصل منطق العمل (الـ Model) عن العرض (الـ View) وعن التحكم (الـ Controller)، وبالتالي لو عايز تعدل في جزء معين، بتعدل عليه من غير ما تأثر على الأجزاء التانية.

📌 سهولة التطوير والصيانة: كل مكون في الـ MVC بيشتغل بشكل مستقل، فلو في مشكلة في العرض (الـ View) مش لازم تلمس الكود الخاص بالبيانات (الـ Model) أو التحكم (الـ Controller).

📌 إعادة استخدام الكود: بما إن الكود متقسم ومنظم، ممكن تعيد استخدام أجزاء معينة منه في مشاريع تانية.

———

نمط الـ MVC هيسهل عليك الدنيا خصوصًا لو شغال على مشاريع كبيرة ومعقدة لأنه بيفصل بشكل واضح بين الأدوار المختلفة لكل مكون في التطبيق.

ده هيوفر عليك وقت ومجهود وهتقدر تعمل تعديل في التطبيق بتاعك بكل سهولة.

بالتوفيق يا بطل 💪🏻

الفرق بين AOT Compiler و JIT Compiler في Angular 💡
.
.
طبعًا أنت عارف إن المتصفح مبيفهمش غير لغة واحدة في الآخر، وهي الـ JavaScript. يعني مهما كتبت كود بلغة زي TypeScript أو حتى HTML وCSS، لازم في النهاية الكلام ده كله يتحول لـ JavaScript عشان المتصفح ينفذه ويطلع الموقع على الشاشة.

وده بيحصل عن طريق حاجة اسمها الـ Compiler (أو الـ Transpiler في بعض الحالات زي TypeScript). ولكن في Angular، الـ compilation ده ممكن يحصل بطريقتين مختلفتين، وكل طريقة لها مميزات وعيوب.

———

https://www.linkedin.com/posts/dev-alisamir_angular-devabrguide-typescript-activity-7305272573439713280-pq-Q

الفرق بين Dependency Injection و Inversion of Control 💡

لما تتعمق شوية في مجال السوفتوير هتسمع عن مصطلحات زي Dependency Injection و Inversion of Control، وفيه ناس بتتلخبط بينهم وبتفكر إنهم حاجة واحدة. خلينا نوضح الفرق بطريقة بسيطة تفهمك الفكرة كويس...

———

📍 إيه هو Inversion of Control (IoC)؟

خلينا نبدأ بـ Inversion of Control أو زي ما بنختصرها IoC. المفهوم ده ببساطة بيقول إن بدل ما الكود بتاعك هو اللي يتحكم في كل حاجة بنفسه (يعني هو اللي بيعمل الكائنات (Objects) اللي هيشتغل بيها ويعتمد عليها)، بيكون فيه جهة تانية هي اللي بتعمل ده وتدير الموضوع.

يعني الكود بتاعك مش بيهتم بأنه "ينشئ" الـ dependencies (الكائنات اللي بيعتمد عليها)، بل بيستقبلها جاهزة.

تقدر تتخيل الموضوع كأنك مش بتروح تجيب مكونات أكلك بنفسك من السوبر ماركت، أنت بتخلي حد يجيبهم لك ويجهزهم، وأنت بس تطبخ الحاجات اللي وصلتك.

———

📍 إيه حكاية Dependency Injection؟

هنا بقى ييجي دور الـ Dependency Injection. ده ببساطة أسلوب أو طريقة لتطبيق مفهوم الـ Inversion of Control.

بدل ما الكود بتاعك هو اللي يقول "أنا محتاج الكائن ده أو المكون ده عشان أشتغل"، حاجة تانية (زي الـ framework أو الـ container) بتكون مسؤولة عن إنها "تضخ" الكائنات دي لك في الوقت المناسب.

———

📌 مثال يوضح الفرق:

تخيل أنك عندك عربية، لو أنت بنفسك اللي بتروح لمحطة البنزين وتملاها، ده يعتبر إن العربية معتمدة على البنزين اللي أنت بتجيبه.

لكن لو في نظام ذكي في العربية هو اللي بيتحكم ويوصل لها البنزين من غير ما أنت تتدخل، يبقى ده Inversion of Control، لأنك سبت السيطرة للنظام إنه يدير الموضوع.

أما Dependency Injection، فهو الآلية اللي بيتم بيها توصيل البنزين للعربية. يعني هي دي الطريقة اللي البنزين بيوصل بيها لعربيتك عشان تمشي.

———

📌 طب ليه بنهتم بالحاجات دي في البرمجة؟

الفكرة ببساطة إن الطريقة دي بتخلينا نكتب كود مرن وسهل التطوير. لو كل كائن في الكود بتاعك بيعتمد على كائنات تانية وبيعملها بنفسه، ده هيخلي الكود معقد وصعب تختبره أو تعدل عليه.

لكن لما تخلي Dependency Injection مسؤول عن توصيل الـ dependencies، هتقدر تعدل على الكود أو تستبدل أي جزء بسهولة من غير ما تبقى محتاج تغييرات كبيرة.

———

الخـلاصـة ✅

الـ Inversion of Control: هو المفهوم اللي بيقول إنك تسيب التحكم في الـ dependencies لجهة خارجية.

الـ Dependency Injection: هو طريقة لتطبيق المفهوم ده عن طريق توصيل الـ dependencies للكود بتاعك بشكل أوتوماتيكي.

بالتالي، IoC هو الفكرة الكبيرة اللي بتحكم الموضوع، وDependency Injection هو الأداة اللي بتطبق الفكرة دي.

بالتوفيق يا بطل ⚡️

Our Digital Hubs 🌐

DevGuide | Telegram

https://t.me/the_developer_guide

DevGuide | YouTube

https://www.youtube.com/@The_Dev_Guide

DevGuide | LinkedIn

https://www.linkedin.com/company/dev-guide

DevGuide | Discord

https://discord.gg/nTgfYng5q2

DevGuide | Facebook

https://www.facebook.com/TheDeveloperGuide

DevJobs | Telegram

https://t.me/devsjobs

DevJobs | WhatsApp

https://whatsapp.com/channel/0029Va5wYTe1noz1SKCNcv45

DevJobs | LinkedIn

https://www.linkedin.com/showcase/developersjobs