السلام عليكم
منذ مدة طويلة لم أكتب في هذا القسم
بالطبع انشغلت بمواضيع كثيرة
وكعادتي تركت ثقوباً ورائي
اليوم أعود إلى هذا الثقب الكبير
وأحاول أن أسد منه ما أستطيع
يذكرني هذا التشبيه
بالذي شبه الفيل بالنملة
تخيلوا أني أشبه علم الأنماط بالثقب
أوووووووووف
على كل حال عدت لأتكلم
وأنا عندما أتكلم أحتاج إلى طلقة مدفعية لإسكاتي
(ياليت لو يخدمنا أحدهم ويقوم بذلك)
عبده احترم نفسك وإلا طردتك من الموضوع
(يا شيخ اتنيل أنتا ومواضيعك الغبية)
الأخ عبده لا يصلح معه إلا حل واحد
بالتأكيد ليس إخراجه بالقوة
لأن هذا موضوع ستطير فيه الكثير من الرقاب
على كل حال سنستحمله حتى نحافظ على الرقاب في مكانها
اليوم أحدثكم عن نمط الوكيل proxy
المشكلة:
أحياناً هناك كائنات تحتاج إلى ذاكرة كبيرة
وأحياناً أخرى هناك كائنات تحتاج إلى معالجات كبيرة لإنشائها
وبكل وقاحة تجد أحدهم ينشئ منها العشرات
أوووووووووف
هذا مكلف جداً
ما الحل إذن؟
سنقوم بالحجر على هذه الكائنات
وتوكيل كائن محايد لكي يقوم بإدارة عملية إنشائها
ومن هنا نشأت تسمية الوكيل
نحتاج إلى مثال لتوضيح المفهوم
لدينا الفئة صورة هذه الفئة تقوم بالعمليات المعقدة
public class Image{ protected Image(String path){ //complex operation and logic //huge memory } }
لهذا سننشئ فئة وكيل عن الصورة لتنظم عملية إنشاء الكائن
public class ImageMangement{ Mapimages=new HashMap (); public ImageMangement(){ //complex operation and logic //huge memory } public Image load(String path){ if(imagesPath.containsKey(path) return images.get(path); else{ Image image=new Image(path); images.put(path,image); } } }
لاحظوا أنا راعينا أن إنشاء كائن من صورة مكلف جداً
فلا نقوم بإنشاؤه إلا إذا كان غير موجود مسبقاً
الآن نرى كيفية الاستخدام
أنا الآن فئة من خارج الحزمة
وأريد أن أتعامل مع هذه الحزمة
أحتاج إلى صورة
أريد صورة يا أخوة هل هناك من لديه واحدة
يتبرع الأخ الوكيل بأن يلبي طلبي
لو أتيت مرة أخرى أريد نفس الصورة
لن يقوم بتحميلها مرة أخرى إلى الذاكرة
وإنما سيعطيني الصورة السابقة
لاحظوا أن الفئة صورة مخفية عن الفئات خارج حدود الحزمة
لهذا فلن نستطيع التعامل معها إلا من خلال الوكيل
يا سلام ما أجمل الحياة
هذا نمط سهل جداً
ومفيد جداً
وفائدته واضحة هنا
في الحزم الكبيرة يجب أن يكون هناك تنظيم للذاكرة بشكل جيد
وهذا مايقوم به الأخ وكيل
طبعاً هذا نوع من التجريد
الذي يمنع المطور من الإضرار ببرنامجه
تحياتي
Tags: design pattern, pattern, proxy, proxy pattern, الوكيل, عالم الأنماط, نمط
ههههههههههههه يا زلمة زود الرامات تبعتك وفكنا من مواضيع التقنين في الموارد تبعتك هادي يا اخ علوش
طبعا بمزح معك الموضوع جد مفيد
انشالله تكونو بخير في غزة وطمنونا عنكم
جزاك الله خير ولكن لم أفهمى جيداً الموضوع يحتاج بعض التفصيل -معلش دايماً مبفهمش بسرعة
المهم انت اخبارك إيه الروتر فسد من 4 أيام مع بداية الضرب ولسه مشتري واحد تاني النهارده -طمني عليك
اسكت ولك مش تطورنا وصار معنا لابتوب
بعدين برامات كبيييييييييييرة
لزوم الشغل 🙂
حبيبي يا حج
بعدين ولا بتتصل ولا بتسأل
تحياتي
السلام عليكم
بصراحة يا عبد الله هذا المقال
لا يندرج تحت بند المبرمج المبتدئ أو حتى المتوسط
فليس العيب فيك إذا لم تستطع الفهم
لكن لأسهل عليك الموضوع
فكر في برمجة الحزم packages
بمعنى آخر برمجة الفئات classes لاستخدام الآخرين
بمعنى آخر البرمجة لتسهيل البرمجة
أقصد بالعبارة الأخيرة أنك لا تبرمج لتحصل على برنامج يستخدمه الآخرون
وإنما لتحصل على أداة تساعد الآخرين على البرمجة
الحمد لله يا على كل حال
صحيح أن الوضع سيء إلى أبعد الحدود
وأنا نعاني فقر في الاحتياجات الأساسية
لكن الحمد لله على كل حال
تحياتي
الحمدلله فهمت الفكرة
والحمدلله أني شوفت ردك بصراحة كنت قلقان عليك
وربنا ينصركم
الحمد لله أن الفكرة كوصلت
شكراً على مشاعرك الجياشة عبد الله
تحياتي
نحن نستخدم ال Proxy Pattern حتى بدون ان نشعر اننا نستخدمه مثلاً عند انشائك بروكسى للتعامل مع جدول وحيد فى قاعدة البيانات فهنا انت قمت بعملية تجريد Abstraction فيتعامل مستخدم هذا البروكسى مع كائن بدون ان يدرى اى شئ عن قاعدة البيانات او ما يتعلق بها و من ثم فبامكانك تغيير محرك قاعدة البيانات كيفما تشاء و تتعامل مع البروكسى بدون الاهتمام بالتغيير الذى طرأ
أخ طارق إبراهيم أظن هذا أقرب إلى النمط Facade
إن لم تخني الذاكرة في اسمه
النمط الوكيل متخصص في إدارة آلية التعامل مع كائن وحيد
بينما النمط Facade متخصص في تسهيل التعامل مع الحزمة خاصتك
ما رأيك؟ أتمنى أن أستفيد من خبرتك في الموضوع
تحياتي
كلامك صحيح يا علاء
ال Facade مخصصة لتتعامل مع ال Sub Systems التى ربما تتكون من عدة كائنات اصغر (ربما تكون بروكسى لكائنات اخرى) فى ال Complex Systems و تستخدم ايضاً ك API Inerface و هدفها هى التسهيل لمستخدمها
اما البروكسى فهو يتشارك معها الفكرة العامة و لكن نمط الوكيل Proxy Pattern يحمل مؤشر Reference لكائن اخر حيث يتحكم فى الوصول إليه بكافة خصائصه … اعتقد ان لديكم فى J2EE على حسب معلوماتى EJB Proxy Object و ال Spring Transaction Object فى جافا و دوت نيت
اوضح مثال من وجهة نظرى لمط الوكيل هو ال Business Object الذى يتعامل مع جدول فى قاعدة البيانات من خلال ال DAL
فعلاً أخ طارق EJB proxy pbject يقوم بالتحكم بالكائن EJB object ويمنع التعامل معه بدون المرور بالوكيل تقريباً نفس المنطق في Spring
بالمناسبة أخ طارق أنت أول شخص أستفيد من مشاركته في المدونة
أقصد بطريقة مباشرة
فالأغلب أستفيد من أسئلتهم بطريقة غير مباشرة
تحياتي
جزاك الله خيراً يا علاء
و انا استفدت كثيراً بوجود شخص مثلك يتحدث عن انماط التصميم فى مدونته باللغة العربية و لجافا خصوصاً
مثل اخر لنمط الوكيل : استخدام خدمات الويب Web Services فعتد استخدامك لاى خدمة من خدمات الويب فانت تقوم بانشاء Proxy من هذه الخدمة (لا اعلم لماذا لم اتذكر هذا المثال سوى الان)
تقريباً web service هي ابن EJB
فعلياً web service و EJB يقومان على نفس المبدأ
“عزل منطق البرنامج عن واجهاته”
لكن web service يقوم بعزل منطق البرنامج عن اللغة التي تتم برمجته بها
بحيث يمكنك استخدام المنطق نفسه في لغات أخرى
لهذا ليس غريباً أن يكون هناك أشياء مشتركة بينهما
تحياتي
Hello! I have some propblem with you rss. Is it work?
yes, it is