عادات تكتسبها من لغات البرمجة

اقتباس

ماهي المشكلة هي انها تترك الطريق مفتوح ، مثلا وجود الدوال من نوع friend يفتح الطريق لاكواد سيئة كان يمكن كتابتها بطرق اخرى.

ماهي وظيفة friend برأيك, و مالفائدة من وضعها في ++C, و الأهم كيف تفتح الطريق أما كتابة كود سيء؟

اقتباس

ماهي المشكلة هي انها تترك الطريق مفتوح ، مثلا وجود الدوال من نوع friend يفتح الطريق لاكواد سيئة كان يمكن كتابتها بطرق اخرى.

friend داخل الـ ++C تساوي internal داخل الـ #C.

بجد انا مستغرب لماذا ينظر لمبرمجي فيجول بيسك على انهم من اسوء المبرمجين ,,

هل لأنها لغة بسيطة , او ان الساينتكس تبعها سهل وبسيط !!

يا جماعة , , بغض النظر عن اللغة التي تكتب بها برنامجك ,, أهم شي مخرجات البرنامج ,,

والكل يعلم ان الناس عامة ,, يفضلون واجهات الGUI على واجهات الكونسول !!

فلماذا التهجم ؟؟

كان البعض في السابق يتهجم على امكانيات اللغة ,,

لكن الان مع الدوت نت اصبحت امكانياتها جباارة جدا ,, حتى انك تستطيع ان تبرمج لعبة 3D قوية جدا باستخدام XNA Games !!!!

AL-RAHEEB كتب:

بجد انا مستغرب لماذا ينظر لمبرمجي فيجول بيسك على انهم من اسوء المبرمجين ,,

هل لأنها لغة بسيطة , او ان الساينتكس تبعها سهل وبسيط !!

يا جماعة , , بغض النظر عن اللغة التي تكتب بها برنامجك ,, أهم شي مخرجات البرنامج ,,

والكل يعلم ان الناس عامة ,, يفضلون واجهات الGUI على واجهات الكونسول !!

فلماذا التهجم ؟؟

كان البعض في السابق يتهجم على امكانيات اللغة ,,

لكن الان مع الدوت نت اصبحت امكانياتها جباارة جدا ,, حتى انك تستطيع ان تبرمج لعبة 3D قوية جدا باستخدام XNA Games !!!!

هل قرأت ردي الأخير؟ لا أحد يهجم على مقدرات اللغة هنا، بل على فئة معينة من مستخدميه.

تحليل رائع أخي عبدالله :)

عندما قرأت المثال بالبي أتش بي وأن المبرمج يستخدم المصفوفات إنتقلت فورا إلى مثال الجافا لأرى هل يمكن ذلك بغير المصفوفات :)

Khaled.Alshaya كتب:

ماهي وظيفة friend برأيك, و مالفائدة من وضعها في ++C, و الأهم كيف تفتح الطريق أما كتابة كود سيء؟

باختصار تكسر الـــــــ encapsulation

اقتباس

باختصار تكسر الـــــــ encapsulation

عزيزي لا تعتمد على المقارنات الموجودة على الويب لبناء آرائك حول إمكانات معينة لـ ++C. قولك بأنها تكسر الـ encapsulation يعني أنك لا تفهم وظيفة friend, لأنها في الحقيقة تقوي الـ encapsulation, و ليس هذا الموضوع مجالاً لنقاش هذه النقطة و لكن أحببت أن أستفسر عن رأيك و كما يبدو أنه نفس الكلام الموجود في مواقع كثيرة دون وعي عن ماهية الـ friend functions & classes.

تحياتي...

محمد علاء الدين كتب:

friend داخل الـ ++C تساوي internal داخل الـ #C.

هذا غير صحيح بالمرة

الinternal في #C يجعل المتغيرات أو الدوال أو الفئات المعرفة تحتها متاحة لأي فئة داخل نفس الAssembly لكن ما تم تعريفة على انه Private أو Protected لا يكون متاح. يجب أن تعرف الشئ Internal من البداية

لكن الFriend يتيح لفئة تحديد فئة أو مجموعة من الفئات الأخرى التي لا تمت لها بأي صلة بأن تكون قادرة على استخدام أي متغيرات او دوال حتى لو كانت private داخل هذه الفئة

Khaled.Alshaya كتب:

عزيزي لا تعتمد على المقارنات الموجودة على الويب لبناء آرائك حول إمكانات معينة لـ ++C. قولك بأنها تكسر الـ encapsulation يعني أنك لا تفهم وظيفة friend, لأنها في الحقيقة تقوي الـ encapsulation, و ليس هذا الموضوع مجالاً لنقاش هذه النقطة و لكن أحببت أن أستفسر عن رأيك و كما يبدو أنه نفس الكلام الموجود في مواقع كثيرة دون وعي عن ماهية الـ friend functions & classes.

تحياتي...

ياختصار لم أجد فائدة للfriend في مشروع اللهم ليس الا لعمل بعض الUnit Tests التي قد تتطلب من الUnit Test Class أن تتأكد من فيم بعض المتغيرات التي قد تكون معرفة كprivate داخل الفئة تحت الاختبار, لكن في النهاية استخدام الfriend دائماً ما ينذر بمشكلة في التصميم التي جعلتك تحتاج لأن تجعل الخصائص الprivate مكشوفة لفئات ليست لها أي صفة قرابة.

Khaled.Alshaya كتب:

عزيزي لا تعتمد على المقارنات الموجودة على الويب لبناء آرائك حول إمكانات معينة لـ ++C. قولك بأنها تكسر الـ encapsulation يعني أنك لا تفهم وظيفة friend, لأنها في الحقيقة تقوي الـ encapsulation, و ليس هذا الموضوع مجالاً لنقاش هذه النقطة و لكن أحببت أن أستفسر عن رأيك و كما يبدو أنه نفس الكلام الموجود في مواقع كثيرة دون وعي عن ماهية الـ friend functions & classes.

تحياتي...

في الحقيقه انا ادري انك كنت تسال مع انه هناك شيئ اخر في راسك

المعلومة هذه ليست من الويب ، في الحقيقه انا اكسل من ان افتح اي صفحة ويب، ولكن لا ادري ربما انت Psychic وتقرأ ما في نفسي :) ، هههه بطل الاشاعات

الدوال من نوع friend تكسر التغليف فعلا ، ما الفائدة التي ترجى من تمكين دالة من خارج الكلاس من الدخول على عناصر الكلاس؟ كما انها تخلط الOOP بالـــ Procedural Paradigm

أخ mental-driller, بالمثال يتضح المقال بدلاً من التعميم.

تصور أنك تقوم بكتابة Data Structure معينة, و تريد توفير Iterators لهيكل البيانات الذي تقوم ببنائه. الدوال التي سيحتاجها الـ Iterator ستكون دوالاً يجب أن لا تسمح لأحد غير الـ Iterator بالوصول إليها و هذا منطقي و إلا ما الحاجة إلا الـ Iterator أصلاً؟

إما أن تكون تلك الدوال public في واجهة الكائن الأصلية و إما أن تكون private. إذا كانت private لا يمكن لأحد الوصول إليها من خارج الكائن, و إذا كانت public فأنت تصدر دوالاً عبارة عن helpers في واجهة الكائن و تكسر الـ encapsulation. ماذا لو كان هناك friend class تستطيع الوصول إلى هذه الدوال دون أن تكون في واجهة الـ data structure التي نقوم ببنائها؟ فكر في هذا المثال.

المقارنة بين internal و friend غير دقيقة. لأن friend تحدد بالضبط من سيصل إلى الكائن بينما internal تفتح الطريق أمام من يريد. لذلك لا داعي لخوض الخلاف في هذا الأمر.

ملاحظة بسيطة, و هي أنه يمكن أن يحتج على على استخدام friend باستخدام inner classes بدلاً من ذلك, و هذه مشاكلها لا تنتهي بالمناسبة :) أدع لك القراءة في ورقة ممتعة من Stroustrup تنطبق على ++C و #C في نفس الوقت:

Minimizing Dependencies within Generic Classes for Faster and Smaller Programs

ملاحظة إضافية:

اقتباس

كما انها تخلط الOOP بالـــ Procedural Paradigm

و من قال أن الخلط بين الأساليب يؤدي دائماً إلى كود سيء؟ :lol:

إضافة أخرى, هذه الأسئلة التي تتعلق بـ friend في SO, استمتع:

http://stackoverflow.com/questions/tagged/c%2b%2b%20friend

تحياتي...

Khaled.Alshaya كتب:

أخ mental-driller, بالمثال يتضح المقال بدلاً من التعميم.

تصور أنك تقوم بكتابة Data Structure معينة, و تريد توفير Iterators لهيكل البيانات الذي تقوم ببنائه. الدوال التي سيحتاجها الـ Iterator ستكون دوالاً يجب أن لا تسمح لأحد غير الـ Iterator بالوصول إليها و هذا منطقي و إلا ما الحاجة إلا الـ Iterator أصلاً؟

إما أن تكون تلك الدوال public في واجهة الكائن الأصلية و إما أن تكون private. إذا كانت private لا يمكن لأحد الوصول إليها من خارج الكائن, و إذا كانت public فأنت تصدر دوالاً عبارة عن helpers في واجهة الكائن و تكسر الـ encapsulation. ماذا لو كان هناك friend class تستطيع الوصول إلى هذه الدوال دون أن تكون في واجهة الـ data structure التي نقوم ببنائها؟ فكر في هذا المثال.

أضفت -1 خطأً، كنت أود أن أضيف +1

حاولت أن أصلحها فلم أبصر لذلك سبيلا، لذا اعذرني.

Khaled.Alshaya كتب:

أخ mental-driller, بالمثال يتضح المقال بدلاً من التعميم.

تصور أنك تقوم بكتابة Data Structure معينة, و تريد توفير Iterators لهيكل البيانات الذي تقوم ببنائه. الدوال التي سيحتاجها الـ Iterator ستكون دوالاً يجب أن لا تسمح لأحد غير الـ Iterator بالوصول إليها و هذا منطقي و إلا ما الحاجة إلا الـ Iterator أصلاً؟

إما أن تكون تلك الدوال public في واجهة الكائن الأصلية و إما أن تكون private. إذا كانت private لا يمكن لأحد الوصول إليها من خارج الكائن, و إذا كانت public فأنت تصدر دوالاً عبارة عن helpers في واجهة الكائن و تكسر الـ encapsulation. ماذا لو كان هناك friend class تستطيع الوصول إلى هذه الدوال دون أن تكون في واجهة الـ data structure التي نقوم ببنائها؟ فكر في هذا المثال.

المقارنة بين internal و friend غير دقيقة. لأن friend تحدد بالضبط من سيصل إلى الكائن بينما internal تفتح الطريق أمام من يريد. لذلك لا داعي لخوض الخلاف في هذا الأمر.

ملاحظة بسيطة, و هي أنه يمكن أن يحتج على على استخدام friend باستخدام inner classes بدلاً من ذلك, و هذه مشاكلها لا تنتهي بالمناسبة :) أدع لك القراءة في ورقة ممتعة من Stroustrup تنطبق على ++C و #C في نفس الوقت:

Minimizing Dependencies within Generic Classes for Faster and Smaller Programs

ملاحظة إضافية:

و من قال أن الخلط بين الأساليب يؤدي دائماً إلى كود سيء؟ :lol:

إضافة أخرى, هذه الأسئلة التي تتعلق بـ friend في SO, استمتع:

http://stackoverflow.com/questions/tagged/c%2b%2b%20friend

تحياتي...

امممممممممم، يصادف اني اقرأ عن نمط الiterator في كتاب design patterns لــ Erich Gamma

وبالفعل كما تفضلت يعد استخدام الدوال على شكل friend خيار ولكن كما يقول المؤلف

اقتباس

However, such privileged access can make defining new traversals difficult, since it'll require changing the aggregate interface to add another friend.

ثم يقترح المؤلف العلاج remedy كالتالي :

اقتباس

To avoid this problem, the iterator class can include protected operations for accessing important but publicly unavailable members of the aggregate

انا متاكد من انك تملك الكتاب لذا يمكنك النظر في النمط iterator البند 6 تحت implementation

سوف اقوم بقراءة ورقة بيارين ستروستروب وارد عليك على الخاص علشان ما نشعب الموضوع زيادة اذا كان لا يوجد لديك مانع

الخلط برايي يؤدي الى كود سيئ وهذا لان الprocedural code يمكن كتابتة باستخدام الOOP بطرق اخرى ولكن اكثر تنظيما :)

+1 على الروابط ،

السلام عليكم

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

كنت في البداية قيل أن ادرس البرمجة أستعمل Vb6 وكدلك وبعد الدراسة تم درسنا Delphi ثم PHP و #VB.NET/ C وكل هده اللغات غير تفكيري البرمجي خصوصا دلفي لكونها تشبه ++C

لكن النصيحة التي أوجهها لاخواني المبرمجين هي الابتعاد عن Vb6 أو أي لغة تشبهها فاللغة التي تسمح بهدا Text1 = Text2

فهي حتما ستسبب الغباء لمبرمجها وتبعده عن الطريق الصحيح ...فهنا يتم اسناد كائن لكن Vb6 يعتبر الأمر اسناد خاصية وهي Caption أما في VB.NET فهي لا علاقة لها ب VB6 الا تشابه Syntax

انا لا احب Visual Basic لانها سهلة كثيرا

مقارنة بـ delphi و php و C و C++ الخ.

dr.php5 كتب:

انا لا احب Visual Basic لانها سهلة كثيرا

مقارنة بـ delphi و php و C و C++ الخ.

إذا كنا سنقارن بالسهولة فـPHP بنفس (أو أقل) سهولة من VB لأن كلاهما weak typed. و VB على الأقل يمكنك تحويلها إلى strong typed باستخدام أمر Option Explicit وOption Strict

سهولة اللغة لا تعني تفاهتها, و العكس بالعكس, اللغة الصعبة لا تعني القوة.

اقتباس

انا لا احب Visual Basic لانها سهلة كثيرا

مقارنة بـ delphi و php و C و C++ الخ.

الفجوال بيسك ليست سهله !! ومن قال أنها سهله ؟

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