استخدام الإطارات في دلفي ل HUI معلومات إخفاء

Question

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

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

type
  TMyForm = class(TForm)
   private
    MyFrame: TMyFrame;
    procedure SetTimeDate(const Value: TMyItem);
    function ReadTimeDate:TMyItem ;

ثم تسجيل الإطار في قسم تهيئة النموذج

initialization 
begin
RegisterClasses([TMyFrame])

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

  public
    property TimeDate: TOverlayItem  read ReadTimeDate  write SetTimeDate;

أنا أيضا استخدام إطارات لتعزيز مجموعات المكونات المتكررة في كثير من الأحيان.

يبدو أن هذا يعمل لأغراض أريد (إخفاء MyFrame ومكوناتها)، ولكن هل لدى أي شخص آخر أي تجربة لهذه الطريقة؟

هل هناك أي عيوب باستخدام الإطارات؟ هل سأكون فعلا أي فائدة من القيام بذلك؟ هل هناك أي مشاكل باستخدام إطارات متداخلة داخل الإطارات؟ هل هناك أي أدلة ممارسة جيدة لاستخدام إطارات في دلفي؟ هل هناك أفضل / أسهل في تحقيق نفس التأثير فيما يتعلق بمعلومات واجهة المستخدم الرسومية المختبئة في دلفي؟

HMCG.

Answer 1

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

إذا كنت تريد المزيد من الهيكل من القراءة على نمط MVC.

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

Answer 2

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

بضع نقاط إعادة إطارات ومعلومات تختبئ في واجهة المستخدم:

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

لذلك بدلا من وجود رمز مثل هذا:

ClientForm := TClientViewForm.Create(Self);
try
  ClientForm.Client := MyClient;
  ClientForm.ShowModal;
finally
  ClientForm.Free;
end;

سأجبر الناس عموما على كتابة شيء من النوع:

ClientViewer := TClientViewer.Create(MyClient);
try
  ClientViewer.Show;
finally
  ClientViewer.Free;
end;

او حتى

TClientViewer.ShowClient(MyClient);

ولها طريقة فئة عرض مقبض المعرض بتظهر بت في القائمة الأولى. بهذه الطريقة لا يتلقى رمز الاتصال مطلقا مؤشر النموذج ولا يمكن لمس أي بت غير متوفر خصيصا بواسطة فئة المجمع.