يعتقد أن البرمجة الكينونية تعتمد على ثلاث ركائز توفر للمبرمج مزايا على النهج الإجرائي. هم التغليف ، والميراث ، وتعدد الأشكال.يسمح لك الوراثة بالتخلص بشكل كبير من تكرار التعليمات البرمجية عند استخدام النهج الموجه نحو الكائنات. ولكن عند استخدامه ، يجب أن تتذكر دائمًا أحد مبادئ SOLID ، المسمى Liskov Substitution ، والتي ، ما لم تدخل في التفاصيل ، تنص على أنه يجب استخدام الوراثة فقط كتطبيق لعلاقة "is". أي أن فئة السليل يجب أن تكون "سلالة فرعية من الأصل". على سبيل المثال ، قد يكون لديك فئة Bird وفئاتها الفرعية Sparrow (العصفور) و Raven (الغراب) ، والتي ، على سبيل المثال ، ترث (ويمكن أن تمتد أو تعدل) طريقة الطيران. ومع ذلك ، إذا قمت بإنشاء سليل من الطيور يسمى Penguin (البطريق) وطريقة الطيران الخاصة به ، على سبيل المثال ، يطرح استثناء (لأن البطاريق لا تطير) ، فهذا ينتهك مبدأ استبدال Liskov. بالحديث عن الميراث ،ومن الجدير بالذكر أيضًا أحد المبادئ الهامة التي تلتزم بها عصابة الأربعة (Erich Gamma و Richard Helm و Ralph Johnson و John Vlissides) في كتابه Design Designs: Elements of Reusable Object-Oriented Software (1994) ، والذي ينص على أنه يجب أن تجرب استخدم التكوين (عندما "يحتوي كائن" على كائن آخر) بدلاً من الوراثة قدر الإمكان. في الواقع ، تستند العديد من أنماط التصميم التي اخترعتها "عصابة الأربعة" بدقة على هذا المبدأ.في الواقع ، تستند العديد من أنماط التصميم التي اخترعتها "عصابة الأربعة" بدقة على هذا المبدأ.في الواقع ، تستند العديد من أنماط التصميم التي اخترعتها "عصابة الأربعة" بدقة على هذا المبدأ.بشكل عام ، من الناحية العملية ، يتم استخدام الميراث لا يعني ذلك كثيرًا ، حتى على الرغم من حقيقة أن المبرمجين الجيدين يستبدلونه في معظم الحالات بتركيبة. في كثير من الأحيان هناك تطبيقات متعددة لواجهة واحدة ، والتي يتم تحديدها على أنها تبعيات في فئات العملاء. والذي بدوره يسمح لك باستخدام الركيزة الثانية من OOP - تعدد الأشكال. مما يسمح لك بتمرير تطبيقات التبعية المختلفة إلى رمز العميل. نظرًا لحقيقة أن التبعيات المرسلة لها نفس الواجهة ، لا يهتم العميل (وفقًا للواجهة) بالكائن الذي وصل إليها وهذا يسمح للمبرمج بالتغيير ، أثناء تنفيذ البرنامج ، بأي طريقة (أي تنفيذ للواجهة) سيتم حل المهمة النهائية. بالحديث عن OOP ، لا يسع المرء سوى ذكر التغليف. هذا عنصر أساسي في OOP ،مما يوفر القدرة على إنشاء ملخصات لإخفاء تفاصيل التنفيذ ذات المستوى المنخفض مع تقليل تعقيد التطوير. يتم إخفاء تفاصيل التنفيذ بواسطة معدِّلات الوصول إلى طرق مثل الخاصة والمحمية. عند إنشاء فئات ، تحتاج إلى إنشائها بحيث توفر واجهاتها (الأساليب العامة التي يمكن الوصول إليها) تجريدًا متسقًا ،وإلا لم يعد OOP (!) . على سبيل المثال ، لنفترض أننا نقوم بتطوير برنامج يتحكم في نظام التبريد للمفاعل النووي. ثم يمكن أن يبدو التجريد المتفق عليه للواجهة كما يلي.CoolingSystem::getTemperature()
CoolingSystem::SetCirculationRate($rate)
CoolingSystem::OpenValve($valveNumber)
CoolingSystem::CloseValve($valveNumber)
بفضل الواجهة التعبيرية القصيرة التي تشكل تجريدًا متماسكًا ، يمكننا العمل مع نظام تبريد المفاعل دون الحصول على أدنى فكرة عن تفاصيل التنفيذ ذات المستوى المنخفض التي تتميز بها التكنولوجيا المحددة. يمكن أن يقلل استخدام التجريد بشكل كبير من تعقيد النظام المطور. ومكافحة التعقيد هي الضرورة التقنية الرئيسية للتنمية. فيما يلي بعض الأمثلة على التجريد المتسق:نظام التحكم في السرعة:- ضبط السرعة
- احصل على الإعدادات الحالية
- استعادة قيمة السرعة السابقة
- تعطيل النظام
مطحنة القهوة:- ممكن
- اطفيء
- ضبط السرعة
- ابدأ طحن البن
- توقف عن طحن البن
خزان الوقود:- املأ خزان الوقود
- استنزاف الوقود
- احصل على سعة خزان الوقود
- الحصول على حالة خزان الوقود
مصباح:عند تصميم واجهة كائن ما ، أعلن للجمهور فقط تلك الأساليب التي يحتاجها العميل لإدارتها ، وإخفاء كل شيء آخر. ونتيجة لذلك ، يجب أن تحصل على مربعات سوداء ، يمكنك نسيان الجهاز بعد إضافة رمز الفصل الدراسي. هذا النهج يمكن أن يقلل بشكل كبير من تعقيد النظام المطور.