كبير منافسيه إلى OOP

Question

من ما أفهم ، OOP هو الأكثر استخداما نموذج للمشاريع الكبيرة.أعرف أيضا أن بعض مجموعات فرعية أصغر من النظم الكبيرة استخدام نماذج أخرى (مثلا ، SQL الذي هو معلن), وأدرك أيضا أن خفض مستويات الحوسبة OOP ليس ممكنا حقا.ولكن يبدو لي أن عادة قطعة من أعلى مستوى الحلول هي دائما تقريبا وضعت معا في OOP الموضة.

هل هناك أي سيناريوهات حيث حقا غير OOP النموذج هو في الواقع أفضل خيار largescale الحل ؟ أو أن يسمع في هذه الأيام ؟

لقد تساءلت هذا من أي وقت مضى منذ أن كنت قد بدأت دراسة CS ؛ فإنه من السهل أن تحصل على الشعور بأن OOP بعض السكينة البرمجة التي لن يتم تجاوزه.

Answer 1

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

السيارة هي سيارة تحتوي على محرك. هذا البرمجة والعالم الحقيقي الكل في واحد!

من الصعب فهم أي شيء يمكن أن يناسب البرمجة والعالم الحقيقي تماما.

Answer 2

لينكس هو مشروع واسع النطاق ليس كثيرا. ولن يكون لديه الكثير لنكسبه منه أيضا.

أعتقد أن OOP لديه حلقة جيدة لذلك، لأنها قد ربطت بممارسات برمجة جيدة مثل التغليف، مختبئ البيانات، إعادة استخدام التعليمات البرمجية، وحدات المنزل. لكن هذه الفضائل ليست فريدة من نوعها ل OOP.

Answer 3

قد يكون لديك نظرة على Erlang، كتبها جو أرمسترونغ.

ويكيبيديا:

"Erlang هو نظام برمجة ووقت تشغيل متزامن للأغراض العامة. المجموعة الفرعية المتسلسلة من Erlang هي لغة وظيفية، مع تقييم صارم، مهمة واحدة، وكتابة ديناميكية."

جو ارمسترونغ:

"لأن المشكلة مع اللغات الموجهة للكائنات هي أن لديهم كل هذه البيئة الضمنية التي تحملها معهم. كنت تريد موزا ولكن ما حصلت عليه كان غوريلا يمسك الموز والغابة بأكملها ".

Answer 4

كان وعد OOP إعادة استخدام التعليمات البرمجية وصيانة أسهل. أنا لست متأكدا من أنها سلمت. أرى أشياء مثل DOT Net كأنها هي نفس المكتبات C التي اعتدنا عليها أن تحصل على موردين مختلفين. يمكنك استدعاء هذا الرمز إعادة استخدامه إذا كنت تريد. أما بالنسبة لصيانة قانون سيء هو رمز سيء. لم يساعد OOP.

Answer 5

أنا أكبر معجبين من OOP، وأنا أمارس OOP كل يوم. إنها الطريقة الأكثر طبيعية لكتابة التعليمات البرمجية، لأنه يشبه الحياة الحقيقية.

رغم ذلك، أدرك أن المحاكاة الافتراضية ل Oop قد يسبب مشاكل في الأداء. بالطبع يعتمد ذلك على التصميم الخاص بك، واللغة والمنصة التي اخترتها (قد تؤدي الأنظمة المكتوبة في لغات القمامة القائمة على مجموعة مثل Java أو C # أسوأ من الأنظمة التي كتبت في C ++ على سبيل المثال).

أعتقد في الأنظمة في الوقت الحقيقي، قد تكون البرمجة الإجرائية أكثر ملاءمة.

Answer 6

لاحظ أنه ليس كل المشاريع التي تدعي أنها منظمة OOP هي في الواقع OOP. في بعض الأحيان تكون غالبية الكود إجرائيا، أو نموذج البيانات ويكيميم, ، وما إلى ذلك وهلم جرا...

Answer 7

Zyx، كتبت، "معظم الأنظمة تستخدم قواعد البيانات العلائقية ..."

أخشى أن لا يوجد شيء من هذا القبيل. سيكون النموذج العلائقي يبلغ من العمر 40 عاما في العام المقبل وما زال قد تم تنفيذه أبدا. أعتقد أنك تعني، "قواعد بيانات SQL". يجب عليك قراءة أي شيء من قبل فابيان باسكال لفهم الفرق بين DBMS العلائقية و SQL DBMS.

"... عادة ما يتم اختيار النموذج العلائقي بسبب شعبيته"

صحيح، انها شعبية.

"... توفر الأدوات"

Alas بدون أداة رئيسية ضرورية: تنفيذ النموذج العلائقي.

" الدعم،"

نعم، يحتوي النموذج العلائقي على دعم جيد، أنا متأكد من ذلك، لكنه غير مدعوم تماما من خلال تنفيذ DBMS.

"وحقيقة أن النموذج العلائقي هو في الواقع مفهوم رياضي"

نعم، إنه مفهوم رياضي، ولكن، لا يتم تنفيذه، إنه يقتصر إلى حد كبير على أبراج العاج. نظرية الأوتار هي أيضا مفهوم رياضي لكنني لن أقوم بتنفيذ نظام به.

في الواقع، على الرغم من كونها مفهوما ميثمايا، إلا أنه ليس بالتأكيد علما (كما هو الحال في علوم الكمبيوتر) لأنه يفتقر إلى الشرط الأول من أي علوم: أنه غير قابل للتزامن: لا يوجد تنفيذ ل DBMS العلائقية التي يمكننا التحقق منها المطالبات.

إنه زيت ثعبان نقي.

"... على عكس OOP."

وعقل ذلك، لم يتم تنفيذ النموذج العلائقي.

شراء كتاب على SQL والحصول على إنتاجية.

اترك النموذج العلائقي للنظرين غير المنتجين.

Answer 8

يرى هذه و هذه. وبعد يبدو أنه يمكنك استخدام C # مع خمسة نماذج برمجة مختلفة، C ++ مع ثلاثة، إلخ.

بناء البرمجيات ليست أقرب إلى الفيزياء الأساسية. نسعى الفيزياء إلى وصف الواقع باستخدام النماذج التي قد تحدىها بيانات تجريبية جديدة و / أو نظريات جديدة. الفيزياء هي العلم الذي يبحث عن "الحقيقة"، بطريقة بناء البرمجيات لا.

بناء البرمجيات اعمال. وبعد تحتاج إلى أن تكون إنتاجي, ، أي لتحقيق بعض الأهداف التي سيدفعها شخص ما المال. يتم استخدام النماذج لأنها مفيدة إنتاج البرمجيات بشكل فعال. وبعد لا تحتاج الجميع إلى الاتفاق. إذا كنت أفعل ذلك، فهو يعمل بشكل جيد بالنسبة لي، لا يهمني إذا كان نموذج "جديد" سيكون أكثر فائدة بنسبة 20٪ بالنسبة لي إذا كان لدي الوقت والمال لتعلمه وإعادة التفكير في وقت لاحق في بنية البرامج بأكملها م العمل في وإعادة تصميمها من الصفر.

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

Answer 9

أشك في أن OOP يذهب بعيدا في أي وقت قريب، فإنه يناسب مشاكلنا والعملات العقلية بشكل جيد للغاية.

ما بدأنا نرى أنه مناهج متعددة النماذج، مع إدماج الأفكار التصريحية والوظيفية في التصاميم الموجهة نحو الكائنات. تعد معظم لغات JVM الأحدث مثالا جيدا على هذا (Javafx و Scala و Allojure وما إلى ذلك) بالإضافة إلى LinQ و F # على منصة .NET.

من المهم أن نلاحظ أنني لا أتحدث عن استبدال OO هنا، ولكن حول تكملها.

• أظهر Javafx أن الحل التصريحي يتجاوز SQL و XSLT، ويمكن أيضا أن تستخدم خصائص وأحداث ملزمة بين المكونات المرئية في واجهة المستخدم الرسومية

• لأنظمة الأخطاء المتزامنة للغاية والمتزامنة، البرمجة الوظيفية هي جدا مناسب جيدا، كما يتضح من Ericsson AXD301 (مبرمجة باستخدام Erlang)

لذلك ... حيث تصبح التزامن أكثر أهمية وتصبح FP أكثر شعبية، أتصور أن اللغات لا تدعم هذه النموذج ستعاني. ويشمل ذلك الكثير من الشعبية حاليا مثل C ++ و Java و Ruby، على الرغم من أن JavaScript يجب أن تعامل بشكل جيد للغاية.

Answer 10

باستخدام OOP يجعل الرمز أسهل في إدارة (كما هو الحال في تعديل / تحديث / إضافة ميزات جديدة) وفهم. هذا صحيح بشكل خاص مع المشاريع الكبيرة. نظرا لأن الوحدات / الكائنات تغليف بياناتها وعملياتها على تلك البيانات، فمن الأسهل فهم الوظيفة والصورة الكبيرة.

فائدة OOP هي أنه من الأسهل مناقشة (مع مطوري / إدارة / عميل آخرين) Logmanager أو طلب أمر، كل منها يشمل وظائف محددة، ثم وصف "مجموعة من الأساليب التي تفريغ البيانات في الملف" و "الطرق التي تتبع تفاصيل الطلب.

لذلك أعتقد أن OOP مفيدة خاصة بمشاريع كبيرة ولكن هناك دائما مفاهيم جديدة تحولت، لذا استمر في البحث عن أشياء جديدة في المستقبل، وتقييم والحفاظ على ما هو مفيد.

Answer 11

يحب الناس التفكير في أشياء مختلفة ك "كائنات" وتصنيفها، لذلك لا شك في أن OOP تحظى بشعبية كبيرة. ومع ذلك، هناك بعض المناطق التي لم اكتسب فيها OOP شعبية أكبر. تستخدم معظم الأنظمة قواعد البيانات العلائقية بدلا من الهدف. حتى لو كانت تلك الثانية تعقد بعض السجلات البارزة وهي أفضل بالنسبة لبعض أنواع المهام، فإن النموذج العلائقي يتم اختياره إلى حد كبير بسبب شعبيته، وتوافر الأدوات والدعم وحقيقة أن النموذج العلائقي هو في الواقع مفهوم رياضي، خلاف oop.

منطقة أخرى حيث لم أر Oop أبدا هي عملية بناء البرامج. جميع التكوين وجعل البرامج النصية إجرائية، جزئيا بسبب عدم وجود دعم OOP بلغات شل، جزئيا لأن OOP معقدة للغاية لمثل هذه المهام.

Answer 12

قليلا المثير للجدل فتوى مني ولكن لا أجد OOP, على الأقل من النوع الذي شعبيا تطبيقها الآن ، أن تكون أن مفيدة في إنتاج أكبر نطاق البرامج في المجال بالذات (VFX, الذي يشبه إلى حد ما في المشهد المنظمة وتطبيق الدولة الألعاب).أجد أنه من المفيد جدا في المتوسطة الصغيرة الحجم.يجب أن تكون حذرا بعض الشيء هنا منذ أن دعا بعض الغوغاء في الماضي ، ولكن يجب أن تكون مؤهلة أن هذا هو في ضيق الخبرة في نوع معين من المجال.

صعوبة وجدت في أغلب الأحيان هو أنه إذا كان لديك كل هذه الأشياء الملموسة تغليف البيانات ، وهم الآن يريدون التحدث مع بعضهم البعض.التفاعلات بينهما يمكن الحصول على معقدة للغاية ، مثل ذلك (ما عدا من هذا بكثير مجمع في تطبيق حقيقي يمتد لآلاف الكائنات):

و هذا هو الرسم البياني للعلاقة ذات الصلة مباشرة إلى اقتران بقدر ما هو "التفاعل الرسم البياني".يمكن أن يكون هناك تجريدات إلى فصل هذه الأشياء الملموسة من بعضها البعض. Foo قد لا أتحدث Bar مباشرة.ربما بدلا من التحدث من خلال IBar أو شيء من هذا النوع.هذا الرسم لا يزال الاتصال Foo إلى Bar لأنه وإن كان يجري تنفصل ، فإنها لا تزال تتحدث إلى بعضها البعض.

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

بدلا من ذلك ما وجدته مفيدا في تنظيم مجمل تعليمات البرمجة الأساسية في مستقل تماما, ضخمة الفرعية أن الوصول إلى وسط "قاعدة بيانات".كل نظام فرعي ثم المدخلات والمخرجات البيانات.بعض النظم الفرعية الأخرى يمكن الوصول إلى نفس البيانات ، ولكن من دون أي نظام واحد مباشرة يتحدثون مع بعضهم البعض.

...أو هذا:

...و كل فرد النظام لم يعد محاولات تغليف الدولة.لا تحاول أن تصبح النظم الإيكولوجية الخاصة.بدلا يقرأ ويكتب البيانات في قاعدة البيانات المركزية.

بالطبع في تنفيذ كل نظام فرعي ، فإنها قد تستخدم عدد من الكائنات للمساعدة في تنفيذها.وحيث ان تجد OOP مفيدة جدا في تنفيذ هذه النظم الفرعية.ولكن كل من هذه النظم الفرعية يشكل نسبيا متوسطة إلى صغيرة الحجم المشروع ليست كبيرة جدا ، انه في تلك متوسطة إلى صغيرة الحجم أن أجد OOP مفيدة جدا.

"خط التجميع البرمجة" مع الحد الأدنى من المعرفة

هذا يسمح لكل الفرعي إلى التركيز فقط على فعل شيء لها مع ما يقرب من أي معرفة ما يجري في العالم الخارجي.المطور يركز على الفيزياء يمكن أن مجرد الجلوس مع الفيزياء فرعي و لا يعرفون سوى القليل عن كيفية عمل البرنامج إلا أن هناك قاعدة بيانات مركزية من الذي قال انه يمكن استرداد أشياء مثل الحركة المكونات (البيانات فقط) وتحويلها من خلال تطبيق الفيزياء إلى تلك البيانات.وأن يجعل عمله بسيطة جدا و يجعل من ذلك أنه يستطيع أن يفعل ما يفعل أفضل مع الحد الأدنى من المعرفة من كل شيء آخر كيف يعمل.إدخال البيانات المركزية و إخراج البيانات المركزية:هذا كل ما كل نظام فرعي له علاقة بشكل صحيح على كل شيء آخر للعمل.هو أقرب ما وجدت في حقل "خط التجميع البرمجة" حيث كل مطور يمكن أن تفعل الشيء مع الحد الأدنى من المعرفة حول كيفية عمل النظام الكلي.

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

كسر التغليف

النظام ثم يتحول إلى مسطحة بدلا خط أنابيب تحويل المركزي تطبيق الدولة المستقلة من خلال النظم الفرعية التي هي عمليا غافلين عن وجود الآخر.يمكن للمرء في بعض الأحيان دفع المركزي الحدث إلى قاعدة بيانات نظام آخر العمليات ، ولكن هذا النظام الأخرى لا تزال غافلة عن مكان هذا الحدث جاءت من.لقد وجدت أن هذا هو المفتاح لمعالجة التعقيد على الأقل في المجال و هو فعال من خلال كيان مكون النظام.

إلا أنه يشبه شيئا أقرب إلى الإجرائية أو البرمجة الوظيفية على نطاق واسع إلى فصل كل هذه النظم الفرعية والسماح لهم العمل مع الحد الأدنى من المعرفة عن العالم الخارجي منذ نحن كسر التغليف من أجل تحقيق هذا وتجنب تتطلب أنظمة التحدث مع بعضهم البعض.عندما كنت في التكبير ، فإنك قد تجد نصيبك من الأشياء التي تستخدم في تنفيذ أي من هذه النظم الفرعية ، ولكن على أوسع نطاق ، نظم يشبه شيئا آخر غير OOP.

البيانات العالمية

أنا يجب أن أعترف أنني كنت مترددة جدا حول تطبيق ECS في البداية إلى التصميم المعماري في المجال منذ, الأولى, لم تكن قد فعلت من قبل على حد علمي في شعبية التجارية المنافسين (3DS Max, SoftImage, الخ), و الثاني يبدو في مجمله مجموعة من العالمي إلى إمكانية الوصول إلى البيانات.

لقد وجدت أن هذه ليست مشكلة كبيرة.نحن يمكن أن لا تزال فعالة جدا في الحفاظ على الثوابت ، ربما حتى أفضل من ذي قبل.السبب يعود إلى طريقة ECS تنظم كل شيء في النظم ومكوناتها.يمكنك أن تطمئن إلى أن نظام صوتي لن تحاول أن يتحور الحركة العنصر ، على سبيل المثال ، ولا حتى تحت hackiest من الحالات.حتى مع سوء التنسيق ، واردا جدا أن ECS سوف تتحلل إلى شيء حيث يمكنك لم يعد السبب عن أنظمة الوصول إلى أي مكون ، لأنه واضح على الورق وليس هناك عمليا أي أسباب على الإطلاق على نظام معين للوصول إلى غير المكون.

على العكس من ذلك فإنه في كثير من الأحيان إزالة العديد من السابق الإغراءات hacky الأشياء مع البيانات مفتوحة على مصراعيها لأن الكثير من hacky الأمور في السابق برنامج تحت فضفاض والتنسيق وقت أزمة حدث في محاولات متسرعة إلى x-ray تجريدات و محاولة الوصول إلى الأجزاء الداخلية من النظم الإيكولوجية من الكائنات.تجريدات بدأت تصبح راشح نتيجة من الناس في عجلة من امرنا ، تحاول فقط الحصول على القيام بأشياء مع البيانات التي تريد الوصول إليها.كانوا في الأساس القفز من خلال الأطواق أحاول الوصول إلى البيانات التي تؤدي إلى واجهة تصاميم المهينة بسرعة.

هناك شيء يشبه غامضة التغليف لا يزال فقط بسبب طريقة النظام نظمت منذ غالبا ما يكون هناك نظام واحد فقط تعديل نوع معين من مكونات (اثنين في بعض الحالات الاستثنائية).لكنها لا تملك أن البيانات لا توفر وظائف لاسترداد البيانات.الأنظمة لا يتحدثون مع بعضهم البعض.وكلها تعمل من خلال الوسطى ECS قاعدة البيانات (التي ليست سوى التبعية التي يجب حقنها في كل هذه الأنظمة).

المرونة والتمدد

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

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

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

تحول الأشياء إلى البيانات

في السابق OOP الثقيلة تعليمات البرمجة الأساسية حيث رأيت صعوبة الحفاظ على تعليمات البرمجة الأساسية أقرب إلى الرسم البياني الأول أعلاه ، كمية من التعليمات البرمجية المطلوبة انفجرت لأن هاته Car في هذا الرسم البياني:

...قد تكون بنيت على أنها منفصلة تماما الفرعي (الطبقة) تنفيذ واجهات متعددة.لذلك كان علينا ناسفة عدد من الكائنات في النظام:كائن منفصل عن أضواء نقطة من أضواء الاتجاه, كائن منفصل عن سمكة العين الكاميرا من آخر ، إلخ.لدينا الآلاف من الكائنات تنفيذ بضع عشرات من واجهات مجردة في تركيبات لا نهاية لها.

عندما كنت مقارنة إلى ECS أن المطلوب فقط مئات و كنا قادرين على فعل نفس الأشياء قبل استخدام جزء صغير من الكود لأن ذلك تحولت هاته Car الكيان إلى شيء لم يعد يتطلب فئتها.فإنه يتحول إلى مجموعة بسيطة من عنصر بيانات معممة مثيل واحد فقط Entity نوع.

OOP البدائل

لذلك هناك مثل هذه الحالات حيث OOP تطبيقها في الزائد على أوسع مستوى من التصميم يمكن أن تبدأ حقا تحط الصيانة.في أوسع الطيور رأي العين من النظام الخاص بك, فإنه يمكن أن يساعد على تمهيدها و لا تحاول أن نموذج من ذلك "عميقة" مع الكائنات التفاعل مع الكائنات التفاعل مع الكائنات ، ومع ذلك تجريدي.

المقارنة بين النظامين عملت في الماضي والآن من لديه المزيد من الميزات ولكن يأخذ مئات الآلاف من LOC.السابق المطلوب أكثر من 20 مليون LOC.بالطبع انها ليست الأجمل مقارنة بما السابق كان واحد تركة ضخمة, ولكن إذا كنت تأخذ شريحة من النظامين الذي وظيفيا متساوية تماما دون إرث الأمتعة (على الأقل عن أقرب إلى المساواة كما قد نجد) ، ECS يأخذ جزء صغير من الكود أن تفعل الشيء نفسه ، وجزئيا لأنه يقلل بشكل كبير من عدد من الطبقات في النظام بتحويلها إلى مجموعات (الكيانات) من البيانات الخام (مكونات) مع زيادات كبيرة في أنظمة لهم بدلا من حمولة السفينة الصغيرة/المتوسطة الكائنات.

هل هناك أي سيناريوهات حيث حقا غير OOP النموذج هو في الواقع أفضل خيار largescale الحل ؟ أو أن يسمع هذه الأيام ؟

الآن من لم يسمع به.النظام أنا تصف فوق ، على سبيل المثال ، يستخدم على نطاق واسع في الألعاب.من النادر جدا في مجال عملي (معظم أبنية في مجال COM-مثل مع خالص واجهات و هذا النوع من العمارة عملت في الماضي), ولكني وجدت أن يطل على ما في اللاعبين يفعلون عند تصميم بنية جعل العالم للفرق في أن تكون قادرة على خلق شيء لا يزال جدا مفهومة في ذلك ينمو وينمو.

وقال أن بعض الناس يعتبرون ECS أن يكون نوع من البرمجة وجوه المنحى من تلقاء نفسها.إذا كان الأمر كذلك, فإنه لا تشبه OOP من نوع معظمنا يفكر منذ البيانات (المكونات والكيانات أن يؤلف لهم) و وظيفة (نظم) يتم فصلها.فإنه يتطلب التخلي عن التغليف في واسع على مستوى النظام التي غالبا ما تعتبر واحدة من أهم الجوانب الأساسية OOP.

ارتفاع مستوى الترميز

ولكن يبدو لي أن عادة قطعة من أعلى مستوى الحلول هي دائما تقريبا وضعت معا في OOP الموضة.

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

في مجال عملي في VFX, ونحن في كثير من الأحيان عليك أن تفعل الأشياء التي هي على مستوى منخفض نسبيا مثل تون, معالجة الصور, مش تجهيز ديناميات السوائل, الخ, لا يمكن فقط قطعة هؤلاء معا من منتجات الطرف الثالث بما أننا في الواقع تتنافس أكثر من حيث ما يمكننا القيام به في مستوى منخفض (للمستخدمين الحصول على المزيد من متحمسون المتطورة تنافسية الإنتاج تقديم تحسينات من أجمل واجهة المستخدم الرسومية).لذلك يمكن أن يكون هناك الكثير و الكثير من التعليمات البرمجية بدءا من مستوى منخفض للغاية خلط بت وبايت إلى مستوى مرتفع للغاية من التعليمات البرمجية التي scripters الكتابة من خلال جزءا لا يتجزأ من لغات البرمجة.

الإنترويب الاتصال

ولكن هناك نقطة ويأتي مع نطاق واسع بما فيه الكفاية مع أي نوع من التطبيقات عالية المستوى أو مستوى منخفض أو التحرير والسرد ، التي تدور حول معقدة جدا وسط حالة التطبيق حيث وجدت أنه لم يعد من المفيد أن تحاول أن تغلف كل شيء في الكائنات.وبذلك يميل إلى ضرب من التعقيد و الصعوبة أن السبب حول ما يدور بسبب تضاعف كمية التفاعل الذي يحدث بين كل شيء.أنه لم يعد يصبح من السهل أن سبب عن الآلاف من النظم الإيكولوجية يتحدثون مع بعضهم البعض إذا لم يكن هناك كسر نقطة على نطاق واسع بما فيه الكفاية حيث نتوقف النمذجة كل شيء مغلف النظم الإيكولوجية التي يجب أن تتحدث إلى بعضها البعض.حتى لو كان كل واحد على حدة بسيطة ، كل شيء يؤخذ في ككل يمكن أن تبدأ أكثر من تطغى على العقل ، ونحن في كثير من الأحيان إلى اتخاذ الكثير من ذلك في إجراء التغييرات وإضافة ميزات جديدة و تصحيح الأمور وما إلى ذلك إذا كنت تحاول تدور تصميم كامل نطاق واسع النظام فقط حول مبادئ OOP.فإنه يمكن أن يساعد على التحرر من التغليف في بعض الحجم على الأقل بعض المجالات.

في تلك المرحلة ليس بالضرورة مفيدة بعد الآن, يقول, يكون نظام الفيزياء لتغليف البيانات الخاصة به (وإلا العديد من الأشياء التي قد ترغب في التحدث واسترجاع البيانات فضلا عن تهيئة مع المناسبة إدخال البيانات) ، حيث وجدت هذا البديل من خلال ECS مفيدة جدا ، لأنه يتحول هاته نظام الفيزياء ، و الضخمة النظم ، إلى "قاعدة بيانات مركزية محول" أو "قاعدة بيانات مركزية القارئ الذي مخرجات شيء جديد" والتي يمكن الآن أن تكون غافلة عن بعضها البعض.كل نظام ثم يبدأ تشبه أكثر مثل عملية في شقة أنابيب من كائن الذي يشكل عقدة في الرسم البياني معقدة من الاتصالات.