غالبًا ما صادفت مطورين لم يسمعوا بمبادئ SOLID (
تحدثنا عنها بالتفصيل هنا . - ترجم.) أو برمجة موجهة للكائنات (OOP) ، أو سمعت ، لكن لا تستخدمها في الممارسة العملية. توضح هذه المقالة فوائد مبادئ OOP التي تساعد المطور في عمله اليومي. بعضها معروف جيدًا ، والبعض الآخر ليس جيدًا ، لذلك ستكون المقالة مفيدة لكل من المبتدئين والمبرمجين ذوي الخبرة.
نذكرك: لجميع قراء "Habr" - خصم بقيمة 10،000 روبل عند التسجيل في أي دورة تدريبية في Skillbox باستخدام الرمز الترويجي "Habr".
توصي Skillbox بما يلي: دورة Java Developer Online التعليمية.
جاف (لا تكرر نفسك)
مبدأ بسيط إلى حد ما ، حيث يتضح جوهره من العنوان: "لا تتكرر". بالنسبة للمبرمج ، هذا يعني الحاجة إلى تجنب تكرار الشفرة ، وكذلك القدرة على استخدام التجريد في العمل.
إذا كان الرمز يحتوي على قسمين مكررين ، فيجب دمجهما في طريقة واحدة. إذا تم استخدام قيمة ذات ترميز ثابت أكثر من مرة ، فإن الأمر يستحق تحويلها إلى ثابت عام.
يعد ذلك ضروريًا لتبسيط التعليمات البرمجية وجعل دعمها أسهل ، وهي المهمة الرئيسية لـ OOP. كما أن الجمع بين الاتحاد لا يستحق كل هذا العناء ، لأن نفس الرمز لن يجيز التحقق مع كل من OrderId و SSN.
تغليف التغيير
منتجات البرمجيات لمعظم الشركات تتطور باستمرار. لذلك ، تحتاج إلى إجراء تغييرات على الكود ، يجب دعمه. يمكنك تبسيط حياتك مع التغليف. سيسمح ذلك بإجراء اختبار وصيانة أكثر كفاءة لقاعدة الشفرة الحالية.
هنا مثال واحد .
إذا كنت تكتب بلغة Java ،
فقم بتعيين الأساليب والمتغيرات الخاصة افتراضيًا .
مبدأ الانفتاح / التقارب
يمكن تذكر هذا المبدأ بسهولة من خلال قراءة العبارة التالية: "يجب أن تكون كيانات البرامج (الفئات ، الوحدات ، الوظائف ، إلخ) مفتوحة للتوسع ، لكن يجب إغلاقها للتغيير." في الممارسة العملية ، هذا يعني أنه يمكنهم السماح لك بتغيير سلوكهم دون تغيير التعليمات البرمجية المصدر.
يعد المبدأ مهمًا عندما تتطلب التغييرات في التعليمات البرمجية المصدر مراجعة واختبار الوحدة وإجراءات أخرى. الكود الذي يطيع مبدأ الانفتاح / التقارب لا يتغير أثناء التمدد ، لذلك هناك مشاكل أقل بكثير.
فيما يلي مثال على الكود الذي ينتهك هذا المبدأ.
إذا كنت بحاجة إلى تغيير شيء ما فيه ، فسيستغرق الأمر الكثير من الوقت ، حيث سيتعين عليك تغيير جميع أجزاء الكود التي لها صلة بالجزء المرغوب.
بالمناسبة ، الانفتاح هو أحد مبادئ سوليد.
مبدأ المسؤولية الفردية (SRP)
مبدأ آخر من مجموعة SOLID. يقول "هناك سبب واحد فقط يؤدي إلى تغيير في الفصل". يحل الفصل مشكلة واحدة فقط. قد يكون لها عدة طرق ، لكن كل واحدة منها تستخدم فقط لحل مشكلة شائعة. يجب أن تخدم جميع الأساليب والخصائص هذا فقط.
قيمة هذا المبدأ هي أنه يضعف الاتصال بين مكون البرنامج الفردي والرمز. إذا قمت بإضافة أكثر من وظيفة واحدة إلى الفصل الدراسي ، فإن هذا يقدم اتصالاً بين الوظيفتين. وبالتالي ، إذا قمت بتغيير أحدها ، فهناك فرصة كبيرة لإفساد الثانية ، المرتبطة بالأولى. وهذا يعني زيادة في دورات الاختبار من أجل تحديد جميع المشاكل مقدما.
مبدأ انعكاس التبعية (DIP)
ما سبق هو رمز مثال حيث يعتمد AppManager على EventLogWriter ، والذي بدوره يرتبط ارتباطًا وثيقًا بـ AppManager. إذا كنت بحاجة إلى طريقة أخرى لإظهار إخطار ، سواء كان ذلك في الرسائل أو الرسائل النصية القصيرة أو البريد الإلكتروني ، فأنت بحاجة إلى تغيير فئة AppManager.
يمكن حل المشكلة باستخدام DIP. لذلك ، بدلاً من AppManager ، نطلب EventLogWriter ، والذي سيتم تقديمه باستخدام الإطار.
يتيح لك DIP استبدال الوحدات الفردية بسهولة مع الآخرين ، وتغيير وحدة التبعية. هذا يجعل من الممكن تغيير وحدة واحدة دون التأثير على الباقي.
التكوين بدلا من الميراث
هناك طريقتان رئيسيتان لإعادة استخدام الكود - وهذا هو الميراث والتكوين ، ولكل منها مزاياها وعيوبها. والثاني هو المفضل عادة لأنه أكثر مرونة.
يتيح لك التكوين تغيير سلوك الفصل في وقت التشغيل من خلال تعيين خصائصه. عند تنفيذ واجهات ، يتم استخدام تعدد الأشكال ، والذي يعطي تنفيذ أكثر مرونة.
حتى "جافا الفعال" لجوشوا بلوخ تنصح بإعطاء الأفضلية للتكوين بدلاً من الميراث.
Barbara Lisk مبدأ الاستبدال (LSP)
مبدأ آخر من مجموعة الأدوات الصلبة. وينص على أن الأنواع الفرعية يجب أن تكون قابلة للاستبدال لنوع كبير. أي أن الطرق والوظائف التي تعمل مع الطبقة الفائقة يجب أن تكون قادرة على العمل مع الفئات الفرعية دون مشاكل.
يرتبط LSP بمبدأ المسؤولية الفردية ومبدأ تقسيم المسؤولية. إذا كان الفصل يوفر وظائف أكثر من فئة فرعية ، فإن الأخير لن يدعم بعض الوظائف ، منتهكًا هذا المبدأ.
فيما يلي جزء من التعليمات البرمجية يتعارض مع LSP.
تحسب طريقة المساحة (المستطيل r) مساحة المستطيل. سيتعطل البرنامج بعد تنفيذ Square ، نظرًا لأن Square ليس مستطيلًا هنا. وفقًا لمبدأ LSP ، يجب أن تكون الوظائف التي تستخدم مراجعًا للفئات الأساسية قادرة على استخدام كائنات الفئات المشتقة دون تعليمات إضافية.
هذا المبدأ ، وهو تعريف محدد لنوع فرعي ، اقترحته باربرا ليسكوف في عام 1987 في مؤتمر في التقرير الرئيسي بعنوان "تجريد البيانات والتسلسل الهرمي" - ومن هنا جاءت تسميته.
مبدأ فصل الواجهة (ISP)
مبدأ صلب آخر. ووفقا له ، لا ينبغي أن تنفذ واجهة غير المستخدمة. باتباع هذا المبدأ يساعد النظام على الحفاظ على المرونة ومناسبة لإعادة التنظيم عند إجراء تغييرات على منطق العمل.
غالبًا ما يحدث هذا الموقف عندما تحتوي الواجهة على وظائف متعددة في وقت واحد ، ويحتاج العميل إلى واحدة منها فقط.
نظرًا لأن كتابة واجهة مهمة صعبة ، بعد الانتهاء من العمل ، فإن تغييرها دون كسر أي شيء سيكون مشكلة.
تتمثل ميزة مبدأ ISP في Java في أنه يجب تنفيذ جميع الأساليب أولاً ، وعندها فقط يمكن استخدامها بواسطة الفصول الدراسية. لذلك ، فإن المبدأ يجعل من الممكن تقليل عدد الطرق.
البرمجة لواجهة ، وليس التنفيذ
كل شيء هنا واضح من الاسم. يؤدي تطبيق هذا المبدأ إلى إنشاء رمز مرن يمكنه العمل مع أي تطبيق واجهة جديد.
استخدم نوع الواجهة للمتغيرات أو أنواع الإرجاع أو نوع وسيطة الطريقة. مثال على ذلك هو استخدام SuperClass ، وليس SubClass.
هذا هو:
قائمة الأرقام = getNumbers () ؛وليس:
أرقام ArrayList = getNumbers () ؛هنا تطبيق عملي لما قيل أعلاه.
مبدأ التفويض
مثال شائع هو أساليب يساوي () و hashCode () في Java. عندما يكون مطلوبًا لمقارنة كائنين ، يتم تفويض هذا الإجراء إلى الفئة المقابلة بدلاً من العميل.
من مزايا المبدأ عدم وجود ازدواجية في الكود وتغيير بسيط نسبيًا في السلوك. هذا ينطبق أيضًا على تفويض الحدث.
كل هذه المبادئ تسمح لكتابة رمز أكثر مرونة وجميلة وموثوق بها مع اتصال عالية والعتاد المنخفض. بالطبع ، النظرية جيدة ، ولكن لكي يبدأ المطور حقًا في استخدام المعرفة المكتسبة ، هناك حاجة إلى ممارسة. يمكن أن تكون الخطوة التالية بعد إتقان مبادئ OOP هي دراسة أنماط التصميم لحل المشكلات الشائعة لتطوير البرمجيات.
توصي Skillbox بما يلي: