محاولة لصناعة لعبة

[makhlouf]

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

[piratewar]

بصراحة أستاذي العزيز قمت بتجربة النتائج المترتبة
عند عدم استخدام parameter Aowner الخاص بالإجراء create
و قادني ذلك إلى هذه الصورة التوضيحي
ولكن يبقى السؤال هل يجب معرفة التخطيط السابق بالتفصيل
عند محاولة برمجة الكائنات(وبالأخص المكونات)

[kachwahed]

هل يجب معرفة التخطيط السابق بالتفصيل

أبدا، لست مضطرا إلى معرفة كل تفصيل

وهذا يحدث حتى مع شركات التطوير التي تشتري مكتبات كائنات وأحيانا لا تنظر إلى السورس
كل ما يهم ما الذي عندك؟ وكيف تستخدمه؟

نواصل لتتضح الفكرة...

الآن وقد لاحظنا أن الكائنات الفاعلة في اللعبة (لنسميها Actors) تتشارك في نفس الحركات
ولكل منها حركاتها المميزة...

ما رأيك بكتابة كائن TActor يشتق منه بقية الكائنات TShooter, TTarget...
مثلا:

PHP كود :

TActor = class(TShape)
   constructor Create(AOwner: TComponent);
   destructor Destroy; override;
   private procedure Initiate;
   public procedure MoveUp;
   public procedure MoveDown;
   public procedure Update;
 end; 


ثم تشتق بقية الكائنات من TActor مثلا:

PHP كود :

TShooter= class(TActor)
   constructor Create(AOwner: TComponent);
   destructor Destroy; override;
   private procedure Initiate;
 end; 


كود التهيئة Initiate سنجعله مضمن عند الإنشاء Create.
أكمل بقية الكائنات وعدل على الكود ما تشاء، شريطة أن تجميع المناهج المشتركة (procedure/function) في الكائن TActor
المرفق.

[kachwahed]

ما أعلمه (تستخدم override في حالة استخدام رأس إجراء أو دالة أكثر من مرة بمعطيات مختلفة للحصول على نتائج مختلفة)

أعتقد أنك تقصد overload
override تغطي المنهج الموروث

ماذا إن استخدمنا create بدون Aowner

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

ولماذا override مع destroy
في حين أن destroy لم نعطه أي عمليات إضافية ليقوم بها

هنا ينبغي أن نلغي عمل destroy الأصلية إذا أردنا القيام ببعض عمليات التنظيف Clean up قبل تدمير الكائن، لذلك يحسن توظيف override وهذا شائع
وقد نعطه عمليات إضافية لاحقا عندما يكبر المشروع.

[piratewar]

جزاكم الله خيرا ً على المعلومات الرائعة
قمت بعمل المطلوب ولكن Tshoot
لا يندرج تحت TActor
حيث أن إجراءاته و حركاته مختلفة

و لكن في المقابل كانت لدي ميزة جديدة و هو عدم تكرار إجراءات أكثر من مرة
هناك شيء آخر هل إستخدمنا Encapsulation مع الإجراء Initiation

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

[piratewar]

سؤال آخر :
ماذا إن أردت استخدام بعضاً من خصائص Tshape , Timage
هل يسمح باستخدام الوراثة المتعددة؟ وكيف يتم التصريح؟

[piratewar]

المرفق التالي به نفس التعديلات
ولكن استخدمت Timage كancestor
لم بستغرق التعديل دقيقتان

[kachwahed]

قمت بعمل المطلوب ولكن Tshoot لا يندرج تحت TActor

سنأتي عليه...

هناك شيء آخر هل إستخدمنا Encapsulation مع الإجراء Initiation

التغليف مطبق على الفئة كلها TActor تطبيقا لمبدأ الصلاحيات الدنيا Least privileges
باختصار عندما تبرمج فئة Class تخيل أنك لست من سيستخدمها.

بصراحة لم أستخدم البرمجة الكائنية من قبل اللهم إلا عند تطبيق الأمثلة الموجودة بالكتب
أو التعامل مع المكونات التي أقوم بتحويلها من دلفي للازاراس(و لا تعتبر ممارسه أيضاً)
و لكن أول مرة أتعرض لمشكلة برمجية و أحلها بطريقة كائنية
التفكير بها متسلسل و ممتع جداً

رائع، رائع...

هل يسمح باستخدام الوراثة المتعددة؟ وكيف يتم التصريح؟

دلفي ليس مثل ++C لا يدعم الوراثة المتعددة (في نظر البعض هذا أفضل!)
دلفي كبقية لغات البرمجة الأخرى ذات التوجه الكائني يمكنه محاكاة ذلك باستخدام Interface

إقرأ عن: multiple inheritance delphi

كود :

http://stackoverflow.com/questions/1276173/how-to-implement-multiple-inheritance-in-delphi

نعود إلى Tshoot لنحاول صناعة نوعين من الطلقات: TShoot رشاش، TBomb قنبلة
كلاهما يمضي عقد/يتفق/يتعهد... على:
- تصريح إجراء Procedure باسم Fire
- تصريح تابع Function باسم Fired ترجع Boolean
هنا يمكننا كتابة واجهة IFire مثلا:

PHP كود :

type
IFire = interface
   procedure Fire;
   function Fired: Boolean;
end; 


- الواجهات ليست لها Implementation طبعا.
- يمكن بناء صنف آخر (جد) لـ TShoot و TBomb
هناك حلول أخرى الأمر واسع...
كان بالإمكان بناء هيكل برمجي أكثر تطابقا مع حقيقة اللعبة لكنه أكثر تعقيدا

ولكن استخدمت Timage كancestor

انس أمر واجهة المستخدم

المرفق.

[piratewar]

أستاذي السلام عليكم وحمة الله
جزاكم الله خيراً على هذه المنفعة
لم يتم المطلوب كاملاً :confused:
قمت فقط بتعديل الإجراءات الخاصة بكائنات الإطلاق
و قمت ببناء كائن Tbullet هذا مع الكائن Tbomb الذي قمتم ببرمجته مع بعض التعديل .
و عدلت على الكائن Tshoot ليصبح أباً لهما
و بالنسبة للواجهات لم ألمسها (ربما لم أفهمها جيداً)
حيث وجدت أنه تكرار بدون داع و هو تكرار التصريح عن دوال و إجراءات وإعادة التصريح عنها في الكائنات
المشتركة
(ما أفهمة من مبدأ تعدد الواجهات هو إجراءات و أحداث الهدف منها واحد ولكن الكائنات تقوم بتنفيذها بعمليات مختلفة و بمعاملات مختلفة)

[piratewar]

سؤال آخر
كيف سأستفيد بمبدأ تعدد الواجهات
في حين أجد مبدأ الوراثة أسهل و أكثر تنظيماً