أثناء تعاملنا مع ال APIs بنحتاج نعمل User Authentication واللي هي عبارة عن عملية التحقق من هوية المستخدم اللي باعت ال Request, ودا جانب هام جدُا في حماية الـ API وكذلك خصوصية وأمان المستخدمين.
أحد أكبر المشاكل اللي ممكن نواجهها في تصميم الأنظمة الخاصة بالدفع , والمعاملات المالية هي أنك تدفع العميل أكتر من مرة, وعشان كده واحنا بنصمم Payment System محتاجين ناخد في الاعتبار ان عملية الدفع لازم نضمن انها هتتم مرة واحدة فقط لا غير.
الـ Seam هو عبارة عن مكان نقدر من خلاله اننا نغير في الـ Behavior يعني السلوك بتاع البرنامج بتاعنا في المكان ده من غير منغير اي حاجة في المكان ذات نفسه.
مش دايما بيكون السبب الوحيد لاننا نكسر الاعتمادية هو اننا نعمل Testing للـ Class , وده لان احيانا كتير الـ Class اللي عاوزين نعملها Testing بيكون ليها تأثير على Classes تانية , والـ Tests بتاعتنا محتاجة تعرف اكتر عن التأثير ده كويس.
التغييرات اللي بتتم في أي نظام ممكن تتم بطريقتين أساسيتين , ممكن نقول عليهم Edit and Pray أو Cover and Modify .. ولسوء الحظ الـ Edit and Pray هي نوعا ما الـ Standard , طب ايه هم الطريقتين دول , ده اللي هنتكلم عنه في الـ Chapter ده بشكل أساسي ..
كتير مننا بيتعامل مع Legacy Code ولكن ما بنكونش عارفين ازاي نتصرف ونتعامل معاه بشكل فعال , وده لإن زي ماحنا عارفين أغلب الـ Legacy Code بتكون ضخمة وفيها تعقيدات كتير جدا, وكون الـ Code Legacy مش بالضرورة انه يكون كود سيء
كتير مننا بيحتاج في شغله انه يتعامل مع الـ HTTP requests زي GET و POST علشان يتواصلوا مع Servers أو APIs مختلفة. واحدة من الطرق اللي ممكن نستخدمها في الـ Java هي استخدام الـ HttpClient اللي بيسهل علينا العملية دي بشكل كبير.
مع مرور الوقت وزيادة حجم البيانات لا يمكن لجهاز واحد أن يتحمل كل هذه البيانات، فلا بد من زيادة عدد الأجهزة وتخزين البيانات عليها، وهنا يمكننا توزيع الـ Read Requests على أكثر من جهاز فبدلًا من قراءة البيانات من جهاز واحد فقط
3 دقيقة قراءة
اشترك الآن بنشرة اقرأ-تِك الأسبوعية
لا تدع أي شيء يفوتك. واحصل على أحدث المقالات المميزة مباشرة إلى بريدك الإلكتروني وبشكل مجاني!