سؤال

آخر مسألة مسجلة من طراز TFrame-IDE مني. شكرا لجميع المساعدة، زملاء المبرمجين. :)

اللعب مع اقتراح ميراث Tframe في Darrian هنا:

تفاصيل:

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

ما هي أفضل طريقة إلى الميراث Tframe "Refactor" بهذه الطريقة؟ (قد ينطبق ذلك على أحفاد الدرجة المشورة أيضا، غير متأكد). ما هي التحذير والأشياء التي يجب مراقبتها؟

مثال:

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

تم تجميعها بشكل جيد، ولكن عندما حاولت إسقاطها في نموذج، حصلت على "العميل غير موجود" (أو "خاصية العميل غير موجودة")، ولن تسقط على النموذج. حذف العميل والملائقي من DFM Reaked Havoc، وانتهى استبدالها عند تغيير حجمها على أي حال. لقد لاحظت شرحها وبرزجة في الفصول الدراسية، وأنا أفكر في أن القيمة المتعلقة بقيمة الممتلكات من القيم الموروثة، لكنني لست متأكدا. إعادة إنشاء إطار جديد تماما عبر العناصر الجديدة -> الموروثة، ثم نسخ كل شيء، لم تسفر عن نتائج رائعة بعد.

ملاحظة النهائية

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

لقد قمت بإنشاء حزمة اختبار صغيرة للاختراق في محاولات التعلم، وأنا أتعلم الكثير، لكنها بطيئة، وأي إرشادات / رؤية منك دلفي "جدي ماسترز" سيكون هناك تقدير أكثر. :)



أجب التحديث لاحقا:

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

هل كانت مفيدة؟

المحلول

بالإضافة إلى تغيير الفئة الأساسية من TMyFrameTreeView ل TMyBaseFrame تغيير الكلمة الأولى في ملف DFM ل TMyFrameTreeView من object ل inherited.

نصائح أخرى

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

ما هي أفضل طريقة إلى الميراث Tframe "Refactor" بهذه الطريقة؟

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

لذلك، ربما من الأفضل استخدام ديكور:

TMySharedEngine = class(Whatever)
property LinkedFrame: TFrame;
property P1;
property P2;
...
procedure Proc1;
procedure Proc2;
... //etc.
end;

وفي إطارات "أختك" لاستخدام مثيلات منه:

var
TMyFrame1 = class(TFrame)
...
FDecorator: TMySharedEngine;
  ...
  public
  property MySharedPart: TMySharedEngine read FDecorator;
  constructor Create(AOwner: TComponent); override;
  ...
end;

constructor TMyFrame1.(AOwner: TComponent); override;
begin
  inherited;
  FDecorator:=TMySharedEngine.Create; //ok, ok do not forget to Free it .Destroy
  FDecorator.LinkedFrame:=Self;
  ...
end;

Otoh، إذا كنت ترغب في استخدام نهجك، فيمكنك استخدام ميراث النموذج البصري (كما اقترح ديبي) أو (أكثر مرونة) يمكنك القيام بذلك باليد: إنشاء، باستخدام الإطارات IDE التالية: TBASEFRAME، TCHILDFRAME1، TCHILDFRAME2 ... إلخ . الآن اذهب إلى وحدة TchildFrame1 وتغييرها باليد تعريف الفئة من TchildFrame1 = فئة (TFRAME) إلى TchildFrame1 = فئة (TBASEFRAME). تجميع. يجب أن تعمل. ينصح بذلك عندما تقوم بعمل هذه الخدعة TBASEFRAME لتكون فارغة من أجل تجنب الروايات الصغيرة المحتملة (تصادم ميزة وما إلى ذلك)

هث.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top