الفريق العربي للبرمجةأرشيف المنتديات · 2000 – 2023
نسخة أرشيفية للقراءة فقط — التسجيل والمشاركة مغلقان، والمحتوى محفوظ كما كان.

الاضافات في سي#2 - All the rest

مغلق
بدأه هاني الأتاسي في 11 أكتوبر 2005 · 7 رد · 2,137 مشاهدة · في Microsoft Visual C#.NET
مشاركة: واتساب X فيسبوك تيليجرام
#1 صاحب الموضوع

بهذا الموضوع أنهي الاضافات في سي# 2..

بقية الاضافت تجدها في الوصلات التالية:

/index.php?showtopic=77743

/index.php?showtopic=77004

/index.php?showtopic=77102

/index.php?showtopic=77327

تعريف نوع بشكل جزئي Partial Types

هذه الخاصية الجديدة التي تمت اضافتها في سي# 2 ، تمكنك من تعريف class او struct او interface في عدة ملفات مصدرية . حيث جزء من التعريف في ملف وجزء في ملف آخر .

هذه الميزة مهمة في عدة نواحي:

1- إذا كان التعريف سوف يعمل عليه مطورين فكل مطوريطور جزء من النوع

2- إذا أردت اضافة كود على أنواع تم انشائها بشكل آلي عن طريق visual studio ، فمثلا يمكنك الاضافة على strong typed dataset class و form class .

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

تمت اضافة كلمة محجوزة جديدة للغة partial يتم اضافتها على كل نوع يمكن أن يكون جزئي .. إذا أردنا تعريف الكلاس Student بشكل جزئي في ملفين فكل ملف يجب أن يحتوي على التعريف التالي :

File1.cs
======
public partial class Student
{
      int Id {}
}

File2.cs
======
public partial class Student
{
      string Name {}
}

Property Accessor Accessibility

هذه الميزة جديدة في سي# 2 .. وهي موجودة بالأساس في VB.NET .. حيث الآن يمكنك تغيير صلاحيات الوصول إلى كل من get & put accessor في ال property . ففي معظم الأحيان نريد أن نجعل get من صلاحيات public و set من صلاحيات protected .

مثال على هذا:

public class MyType {
	private string _name;
	public string Name {
  get { return _name; }
  protected set { _name = value; }
	}
}

كلاس من نوع static .

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

Friend Assemblies :

هذه الخاصية التي تم اضافتها جديدا تمكن assembly معينة من الوصول إلى التعاريف الداخلية internal في assembly اخرى . وهي ببساطة أن نضيف attribute في ال assembly الأساسية ومن خلالها نعرف ال assembly الصديقة بأنها يمكن أن تصل إلى التعاريف الinternals .

مثال:

1stAssembly
==========

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo(“2ndAssembly, PublicKeyToken=21231231ababab”)]

Internal class InternalType { … }


2ndAssembly
==========

class Program 
{
	static void Main()
	{
  InternalType t = new InternalType();
	}
}

#pragma Warning

يمكنك من خلالها تعطيل وتفعيل رسائل ال warning التي يظهرها المترجم . ويمكنك تحديد رقم الwarning من أجل هذا .

#pragma warning disable 332  // disable warning 332
#pragma warning enable 332  // enable warning 332
#pragma warning enable  // enable all warnings
#pragma warning disable  // disable all warnings

Coding on the Cloud and for the Cloud!

My Blog

#2

شكرا لك هاني على المجهود الرائع وليس بغريب عليك..

لدي سؤال أو تعليق فيما يتعلق بالـpartial classes..

تولد لدي الإحساس أنه ربما فصل الـclass الى أكثر من ملف يدخل عنصر غريب على object oriented programming.. لربما تفيد هذه الخاصية في تنظيم وتجميع الكود في ملفات في حالة استخدام code generation.. ولكن عندها شخصيا أفضل استخدام طرق تتوائم مع طبيعة oop أكثر من partial classes.. ما رأيك؟

#3

ربما لا يوجد شيء جديد على البرمجة الشيئية من هذا الجانب وقد أشار هاني أنه بيئة (نت) لا تميز الفئات الجزئية،، لكن السؤال عن مدى فعالية هذا الأسلوب في تقسيم الفئة لعدة ملفات!

أضف إلى ذلك أن هاني اقترح أيضا أن تصميم الفئة قد يقسم لعدة مطورين! هل الفئات الجزئية صممت لهذا الغرض؟!! أم ما هو الغرض الرئيسي لسلوك هذا الطريق؟!

شرح موفق ،،

#4

الـ Partial Types فعاله من أجل كتابة الكود الذي تم توليده من IDE مثلا في ملف مستقل ... أو فصل كود الـ User Interface عن بقية الأكواد.

تكون جيده أيضا في كتابة الكلاسات التي ترث من كلاس آخر أو Interface أو أكثر فيمكنك أن تضع الـ Implementation الخاص بكل Interface يرث منها الكلاس في ملف مستقل مثلا.

أيضا اذا كان يوجد أكثر من مبرمج يكتب نفس الكلاس فتلك الخاصيه تكون مريحه للغايه.

بالرغم من كل هذا ... انها لا تعتبر ميزه كبيره ولكنها مجرد كماليات :)

نشكرك أخ هاني على الموضوع.

#Read

http://MoutazShams.blogspot.com

projects003.gif

أعتذر عن التغيب هذه الأيام نظرا للانشغال المريب

#5
اقتباس
الـ Partial Types فعاله من أجل كتابة الكود الذي تم توليده من IDE مثلا في ملف مستقل ... أو فصل كود الـ User Interface عن بقية الأكواد.

تكون جيده أيضا في كتابة الكلاسات التي ترث من كلاس آخر أو Interface أو أكثر فيمكنك أن تضع الـ Implementation الخاص بكل Interface يرث منها الكلاس في ملف مستقل مثلا.

افحام!!

الآن اقتنعت.. ولو أنها كمالية جدا!

#6
اقتباس
لـ Partial Types فعاله من أجل كتابة الكود الذي تم توليده من IDE مثلا في ملف مستقل ... أو فصل كود الـ User Interface عن بقية الأكواد.

بالفعل فكرة جيدة أن يكون كود InitializeComponent في ملف وبقية الوظائف في ملف أخر.. ولكن هذه أيضا محاولة للتغلب على مشاكل code generation بطريقة أعتقد أنها تعطي فرصة أكبر لعدم التفكير في الـdesign بشكل يستفيد من صيغ أكثر OO.

بالنسية للـUI مثلا، لا "يحبذ" أن يكون هناك أي logic أبعد من العرض وعمل libraries للـbusiness objects والـbusiness rules... إلخ... وعندها لن تكون هناك حاجة لأكثر من InitializeComponent وبعض الـevent handlers على أية حال..

المقصود أن أكثر الأمثلة التي يمكن أن تستخدم فيها الـpartial classes في الحقيقة تجعلني شخصيا أفكر في حلول بعيدة تماما عما يفترض أن يكون في تطبيق يحترم تقاليد وصيغ OOP الشائعة.

على أي حال هو رأيي الشخصي، قد يكون نوع من رفض الجديد حتى يثبت وجوده :)

#7

شكرا على تفاعلكم مع الموضوع :)

لا أرى لماذا ال partial classes أو فصل الكلاس على أكثر من ملف غريب على OOP .. لا يوجد مسطلح ملف في البرمجة في OOP وكل ماتفهمه ال OOP هو كلاس .. حيث يمكنك وضع أكثر من كلاس في ملف والآن يمكنك وضع الكلاس في أكثر من ملف .. هذه فقط مرونة في رأيي ..

يمكنك أن تقصد أنها قد لا تكون طريقة برمجية جيدة بحيث يصبح الكلاس الذي تبرمجه مبعثر في كل أنحاء برنامجك .. وهذه تعتبر bad programming practice ..

طبعا يمكن اضافة عمليات أو توابع إلى كلاس ما عن طريق الوراثة (كمفهوم OOP) ولكن بالوراثة لا تستطيع الوصول إلى متحولات وتوابع معرفة كـ private .. لكن ال partial class تعتبر مختلفة عن اي مفهوم OOP وهي كما ذكرت تعتبر فقط كمرونة في كتابة الكلاسات .. ولكن استخدامها يجب أن يكون من أجل حل مشاكل من الصعب حلها عن طريق OOP ..

بصراحة أنا أجدها جدا رائعة ومهمة .. ففي الاصدار الأول من سي# كان لدي في مشروع strong typed datasets قام فجوال ستديو بانشائها بشكل آلي في مشروعي .. كنت أريد أن أقوم باضافة بعض التوابع للكلاسات التي أنشئتها لي البيئة وكان الحل إما أن أرث من تلك الكلاسات أو أن أضيف الكود بشكل يدوي داخل تلك الملفات .. طبعا الاضافة غير مجدية لأن فجوال ستديو يمكن أن يولد الكود من جديد في أي لحظة إذا قمت بأي تعديل على ال datasets diagrams . والوراثة لم تكن مجدية لعدة اسباب . فمع ال partial classes هذه محلولة بشكل تام حيث تقوم بتمديد الكلاس السابق في ملف آخر تكون أنت المسؤول عنه .

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

Coding on the Cloud and for the Cloud!

My Blog

#8

هاني، شكرا على الرد.. وأنا أتفق معك في الحالة التي ذكرتها .. ولكن.. يبدو أنني لم النقطة التي تحدثت’ بها لم تتضح تماما..

ما أود قوله أن استخدام partial classes في حالة InitializeComponent أو حتى Typed Data Set أمر رائع ولكن المشكلة أساسا تكمن في أن كلاهما يعتمد على code generation.. أي أن الـscalability في هذه الحالة تكون ضعيفة، ونقل جزء من الـclass الى ملفـ(ات) أخرى سيحل الجزء "الفيزيائي" أكثر من أي شيء أخر.. فعلى أي حال طالما أنك لا تتحكم في الـgenerator ستواجهك مشاكل..

اقتباس
كان لدي في مشروع strong typed datasets قام فجوال ستديو بانشائها بشكل آلي في مشروعي .. كنت أريد أن أقوم باضافة بعض التوابع للكلاسات التي أنشئتها لي البيئة وكان الحل إما أن أرث من تلك الكلاسات أو أن أضيف الكود بشكل يدوي داخل تلك الملفات .. طبعا الاضافة غير مجدية لأن فجوال ستديو يمكن أن يولد الكود من جديد في أي لحظة إذا قمت بأي تعديل على ال datasets diagrams . والوراثة لم تكن مجدية لعدة اسباب . فمع ال partial classes هذه محلولة بشكل تام حيث تقوم بتمديد الكلاس السابق في ملف آخر تكون أنت المسؤول عنه .

أهم مافي الموضوع أننا سنبدأ في سؤال أنفسنا، يا ترى هل أستخدم inheritance أو أستخدم partial class؟ تماما كما أنك كنت تحاول أن تعمل في مشروعك أن تحل مشاكل الـTyped Data Set.. المفترض أن يكون السؤال: هل أستخدم الـ.Net Typed Data Set أم لا؟ الأمر هنا ربما متعلق بتصميم التطبيق وليس تغيير الشكل الفيزيائي.. ففي معظم الأحوال يكون الجواب: لا.

مرات عدة كنت مضطرا لأن أعمل web site/application يحتوي على تفاعل بسيط مع قاعدة بيانات ربما بسيطة للغاية في بعض الحالات.. في حالات كهذه لم يكن OO في تفكيري ولم أهتم إذا كان التطبيق مصمما بعناية، أحيانا كنت أقوم باستخدام codesmith template مثلا لأضغط الزر Generate وينتهي الكثير، وفي أحيان أخرى أفوض الدوت نيت وأستخدم typed datasets.. وهذه هي الحالات التي من الممكن أن أستخدم partial classes لتعديل البرنامج بسرعة،.. ولكن هذا مع الأخذ في الاعتبار أنني غير مهتم الا بوظائف بسيطة لتطبيق صغير.. وغير مهتم بمدى scalability على مدى طويل..

نقطة أخيرة فقط.. إذا كنا نعطي للمطور إمكانية أن يزيد من حجم (وتوزيع) الـclass أفلا يسبب ذلك شيء من الإزعاج إذا كان مطلوبا منه أن يعمل بمبدأ مثل Extract Class؟

هذا الموضوع مغلق.

مواضيع مشابهة