بحث دربارۀ گفتگوی فنی شماره یک (اصول و قواعد کد نویسی)

[Behrouz_Rad]

لطفا يكي به من بگه ، در مثال آقاي موسوي ، اگر از Car از ICar ارث بري نميكرد ، چه اتفاقي ميافتاد ؟

در اين مثال چه ضرورتي داشت كه يك اينترفيس داشته باشيم ؟

آقای کارگردان لطفاً مجددا دوربین رو این سمت بیارید... آها مرسی ممنون :)

شما همیشه در بالاترین سطح از موجودیت های مربوط به هم کلاسی داری که بهش میگن کلاس "انتزاعی"... در این کلاس مجموعه ای از خصیصه ها و رفتارهای عمومی اشیا رو گرد هم میاری. به عنوان مثال: تمامی ماشین ها رنگ دارند، تمامی ماشین ها توسط یک شرکت تولید شدند، تمامی ماشین ها می تونن ترمز بگیرن و تمامی ماشین ها می تونن شروع حرکت داشته باشن.
پس دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" می تونن برای همه ی ماشین های دنیا وجود داشته باشن. اینها "انتزاعی" برای ماشین هاست که در بالاترین سطح قرار میدی.

بنده اگر جای برادر موسوی بودم، اسم interface رو ICar نمیگذاشتم. به نظر من نام IMobility بهتر هست.. یعنی هر چیزی که حرکت می کنه. منظور این نیست که مثلاً یک "مگس" هم توسط یک شرکت تولید میشه، منظور این هست که از واژه ای کلی تر استفاده بشه و پیش خود اینطور در نظر بگیری که منظور از IMobility یعنی "تمامی وسایل نقلیه ی قابل حرکت".

"تمامی وسایل نقلیه ی قابل حرکت" دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" رو دارن... پس ICar محدود کننده است. حداقل در ذهن.

و اما... interface یک قالب کلی از خصیصه ها و رفتارهای خامی ایجاد می کنه که بعداً توسط کلاس هایی که اون رو پیاده سازی می کنن تغییر می کنه... من به interface ها میگم "یاد آور".

بعداً اگر قرار بر این بود که کلاسی برای دوچرخه یا موتورسیلکت داشته باشم، کلاسی با نام Bike ایجاد می کنم و اجزای IMobility رو برای اون پیاده سازی می کنم...

این طوری بسیار زیباتر خواهد بود...

در حقیقت interface بهت "یادآوری" می کنه که: "پسرم وسیله ی نقلیه ی تو حتما باید حداقل دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" رو داشته باشه تا بتونی یک وسیله ی نقلیه حسابش کنی"

لطفاً جمله ی بالا رو 100 بار با دقت بخون ;)

موفق باشید

[alawiala]

آقای کارگردان لطفاً مجددا دوربین رو این سمت بیارید... آها مرسی ممنون :)

شما همیشه در بالاترین سطح از موجودیت های مربوط به هم کلاسی داری که بهش میگن کلاس "انتزاعی"... در این کلاس مجموعه ای از خصیصه ها و رفتارهای عمومی اشیا رو گرد هم میاری. به عنوان مثال: تمامی ماشین ها رنگ دارند، تمامی ماشین ها توسط یک شرکت تولید شدند، تمامی ماشین ها می تونن ترمز بگیرن و تمامی ماشین ها می تونن شروع حرکت داشته باشن.
پس دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" می تونن برای همه ی ماشین های دنیا وجود داشته باشن. اینها "انتزاعی" برای ماشین هاست که در بالاترین سطح قرار میدی.

بنده اگر جای برادر موسوی بودم، اسم interface رو ICar نمیگذاشتم. به نظر من نام IMobility بهتر هست.. یعنی هر چیزی که حرکت می کنه. منظور این نیست که مثلاً یک "مگس" هم توسط یک شرکت تولید میشه، منظور این هست که از واژه ای کلی تر استفاده بشه و پیش خود اینطور در نظر بگیری که منظور از IMobility یعنی "تمامی وسایل نقلیه ی قابل حرکت".

"تمامی وسایل نقلیه ی قابل حرکت" دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" رو دارن... پس ICar محدود کننده است. حداقل در ذهن.

و اما... interface یک قالب کلی از خصیصه ها و رفتارهای خامی ایجاد می کنه که بعداً توسط کلاس هایی که اون رو پیاده سازی می کنن تغییر می کنه... من به interface ها میگم "یاد آور".

بعداً اگر قرار بر این بود که کلاسی برای دوچرخه یا موتورسیلکت داشته باشم، کلاسی با نام Bike ایجاد می کنم و اجزای IMobility رو برای اون پیاده سازی می کنم...

این طوری بسیار زیباتر خواهد بود...

در حقیقت interface بهت "یادآوری" می کنه که: "پسرم وسیله ی نقلیه ی تو حتما باید حداقل دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" رو داشته باشه تا بتونی یک وسیله ی نقلیه حسابش کنی"

لطفاً جمله ی بالا رو 100 بار با دقت بخون ;)

موفق باشید

جمله آخر بسيار زيبا بود ، اگر جسارت بنده را بپذيريد چند مطلبي را اضافه مي كنم
يكي از كاربردهاي inteface وراثت چند گانه است ، آيا تا به حال به اين مورد برخورد كرده ايد كه يك كلاس چگونه مي تواند از دو كلاس بطور همزمان ارث ببرد .در اينجا برخي از خصوصيات inteface , و كلاس abstract را بطور خلاصه بيان مي كنم ، به نظرم در اين مورد تايپيك جدا گانه اي لازم داره

خصوصيات اينترفيس
1-كاربرد در بحث وراثت چندگانه
2-اينترفيس نمي تواند عملي را انجام دهد و صرفا يك چارچوب و قاعده براي كلاسها تعريف مي كند
3-سطح دسترسي توابع و متدهاي آن تابع سطح دسترسي خود اينترفيس است

اما كلاس abstract
1-فقط مي تواند يك كلاس آن را به ارث ببرد
2-توابع و متدهاي آن مي توانند عملياتي را انجام دهند
3-توابع و متدهاي آن مي توانند سطح دسترسي داشته باشند

و .........

اما در بحث كد نويسي به نظر من داشتن يك ديكشنري براي متغيرها بسيار ضروري است ، مثلا ممكن است در چند جا شما متغيري همنام استفاده كنيد كه باعث گيجي مي شود
به نظر من قبل از آغاز كار يك قاعده براي نام گذاري قرار دهيم و هر متغيري را در ديكشنري ذخيره كنيم به اين ترتيب كه اين متغير يا كلاس و يا تابع و متد در كجا بكار رفته و چه كارهايي را انجام مي دهد تا به هنگام تعريف تابع يا متغير جديد حداقل از همنام بودن جلوگيري شود

نمي دانم تا چه حد توانستم مطلب را برسانم

با تشكر فراوان از استادان بزرگوار