مكتبة البرمجيات الحديثة 2011

2011 , مكتبة , البرمجيات , الحديثة

مكتبة البرمجيات الحديثة 2011

مكتبة البرمجيات الحديثة 2011

السلام عليكم ورحمه الله وبركاته ،،


من المعروف والمسَلَم به في عالم البرمجيات القاعده " Software Requirement Always change "، هذه القاعده تنص على أن متطلبات البرنامج سواء كانت General Software موجه للعامه أو Custom Software موجه لزبون معين سوف تتغير بمرور الزمن ، فالبرنامج الذي كان يشغل صوتيات mp3 يجب أن يشغل في الاصداره القادمه صوتيات ram,rm والا بالتأكيد سوف يتجاهل المستخدمين هذا البرنامج ويذهبوا الى ما هو أفضل ، بنفس الأمر البرنامج الذي صممته لاداره المدرسه القريبه منكم تغيرت متطلباتها حيث تريد الاداره أن يقوم البرنامج باصدار شهادات للطلاب بالاضافه الى امكانيه استعلام الطالب عن نتيجته من خلال موقع المدرسه ،،



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

وبغض النظر عن المنهجيه المستخدمه في التطوير ، فما زالت هناك مشاكل تحدث دائما عند تصميم البرامج (أتحدث عن البرامج التي تستخدم أسلوب البرمجه الكائنيه Object Oriented ) فمثلا قمت بانشاء كائننين في البرنامج السؤال هو ما هو الكائن المسؤول عن توليد الأخر ، من الذي سوف تنشئه أولا ومن الذي ستنهيه أخرا ، مثال أخر لديك مثلا كائن عباره عن timer للعبه ما ، وأنت تريد أن تكون هناك timer واحده فقط في البرنامج ، كيف يمكن أن تمنع المستخدم للكائن Timer من أن ينشئ كائن أخر ،،

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

علم تصميم الأنماط Design Pattern هو عباره عن تصاميم معينه لمشاكل لطالما سوف تظهر في أي مشروع برمجي (يستخدم بالطبع مفهوم OO) ، وهذه الحلول قدمها مهندسي البرمجيات والمبرمجين المخترفين على مر الزمن وأصبح من الأفضل للمبتدئ مباشره استخدام هذه الانماط في برنامجه لحل المشكله بدلا من التفكيير في حل قد يكون غير صحيح أو قد يُظهر مشاكل أخرى فيما بعد ،

سنتناول في هذه المقاله البسيطه واحد من أشهر الأنماط ويستخدم بشكل كبير في تصميم واجهات البرامج GUI Desgin الا وهو نمط Model-View-Controller واختصارا MVC ،



ما هو الMVC ؟
=-=-=-=-=-=-=

نمط MVC يقوم على أساس فصل الواجهه Interface (سواء GUI,console) وتسمى View عن التطبيق والذي هو مشكله البرنامج الذي تقوم على حلها Busniess Logic وتسمى Model وعن التحكم في الواجهه (مثلا الحدث الفلاني عندما يتم التعامل مع أحد الأزرار في الواجهه) ويسمى Controller .

بعباره مبسطه ينص نمط MVC على فصل الواجهه Interface من التطبيق نفسه ، بحيث في حال تغيير المتطلبات وتم تعديل الBusniess Logic فان الواجهه تكون كما هي بدون أي تغيير ، وبنفس الأمر في حال تغييرت المتطلبات وتم تحديث الواجهه (اضافه واجهه أكثر احترافيه) فإن طبقه الBusiness Logic تكون كما هي بدون تغيير ،،

لنأخذ مثال بسيط لكي نوضح الفكره في تقسم البرنامج لعده طبقات ، مثلا تريد كتابه تطبيق شبكي يتصل بجهه معينه ويقوم بأخذ بيانات ما ويخرجها لديه في الشاشه ،،الطريقه الأعتياديه التي يقوم بها المبرمجين المبتدئين وهي كتابه التطبيق بالكامل في ملف واحد (التعامل الشبكي ، الواجهه ، الأحداث والتعامل معها) وبمجرد انتهاء البرنامج ستجد هذا المبرمج -المسكين- في قمه السعاده لأنه باع أول برنامج قام به وأخذ عمولته بالكامل $$ ، لكن ولنفرض بمرور أيام اتصل العميل وطلب من المبرمج أن يغير طريقه طلب الخدمه أو الأتصال الشبكي ،، من هنا ستبدأ رحله معاناه مبرمجنا المسكين حيث سيتوجب عليه تغيير طريقه تقديم الخدمه في الجزء الشبكي وليس هذا فقط بل تغيير جزء الواجهه المرتبط بالجزء القديم بالاضافه الى الجزء المتحكم والذي هو event-handler يجب أن يتغير أيضا ،، كل هذا بسبب التزواج والأعتماديه الخاطئه في تصميم الكلاسات من البدايه ،،

لكن ماذا لو قام المبرمج من البدايه باتباع اسلوب MVC ، فقط عليه التغيير في الجزء Model (المتعلق بالتعامل الشبكي) ولن يحتاج لأي تغيير في الواجهه والتحكم VC ، والسبب أن Model لا يعلم أصلا كيف سيتم عرضه (GUI,Console) والجزء المتعلق بالعرض هو View . لذلك استخدام هذا الأسلوب من البدايه يجعل البرنامج قابل للتغيير والتطوير بشكل أفضل بكثير ،،

بعض الأحيان أو في الكثير من الأحيان الجزء View والجزء Controller يكونان مع بعض والسبب أنهم قريبين جدا ويصعب الفصل بينهم ، فالزر Button يمثل الواجهه ، والحدث الخاص بالضغط عليه يمثل المتحكم وهو يقوم بالوظيفه المناسبه ، وحقيقه الفصل بينهم كل منهم في طبقه أمر يعقد البرنامج أكثر لذلك الكثير يجعل VC مع بعض وهكذا سوف نستخدم النمط M-VC .



والسلام عليكم ،،

ساعد في نشر والارتقاء بنا عبر مشاركة رأيك في الفيس بوك

المصدر: شبكة ومنتديات همس الأطلال شبكة ومنتديات همس الأطلال Network Forum whispered ruins - من قسم: أطلال الكمبيوتر .

---

l;jfm hgfvl[dhj hgp]dem 2011

الله يعطيك العافيه

ودي

يسلمووووووووووووووووووو ولا عدمنااك


دمت والسموووووووو