قطعا به نظر من باید برنامه نویسان سطح بالاتر مخاطب این گفتگو ها باشند مگر نه گفتگو های سطح پایین رو ادم های دیگه هم میتونن انجام بدننوشته شده توسط salehbagheri
هدف ایجاد یک سری گفتگو برای روجوع همیشگی به ان برای کسانی که شغلشان برنامه نویسی هست باید باشد
حرف های ساده تر را در تاپیک های ساده تر هم میتوان زد
بحثهاي بي ارتباط رو كجا بايد پست كرد؟
ميخواستم بگم كه اگه اين گفتگوهاي ارزشمند جاي پايي در مجله برنامه نويس داشته باشند فوق العاده ميشه...
حيف هست كه اين مطالب رو به صورت آفلاين نداشته باشيم.
آفلاين كمه بايد اين مطالب رو رو سنگ نوشت ...
امیدم به دستان زیبای اوست . آنکه می آید . همان که نامش منجی ست ....
به راستی اگر غرق نبودیم چرا مارا به منجی ای نیازمند کرده اند؟ ... دنیا دریاست ....
دلنوشته های من
با سلام
جناب مداح در صورت امکان طریق تست کردن کد ها (Unit Test) را در برنامه نویسی با ASP.NET MVC را توضیح دهید
با تشکر
جمله آخر بسيار زيبا بود ، اگر جسارت بنده را بپذيريد چند مطلبي را اضافه مي كنمآقای کارگردان لطفاً مجددا دوربین رو این سمت بیارید... آها مرسی ممنون :)
شما همیشه در بالاترین سطح از موجودیت های مربوط به هم کلاسی داری که بهش میگن کلاس "انتزاعی"... در این کلاس مجموعه ای از خصیصه ها و رفتارهای عمومی اشیا رو گرد هم میاری. به عنوان مثال: تمامی ماشین ها رنگ دارند، تمامی ماشین ها توسط یک شرکت تولید شدند، تمامی ماشین ها می تونن ترمز بگیرن و تمامی ماشین ها می تونن شروع حرکت داشته باشن.
پس دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" می تونن برای همه ی ماشین های دنیا وجود داشته باشن. اینها "انتزاعی" برای ماشین هاست که در بالاترین سطح قرار میدی.
بنده اگر جای برادر موسوی بودم، اسم interface رو ICar نمیگذاشتم. به نظر من نام IMobility بهتر هست.. یعنی هر چیزی که حرکت می کنه. منظور این نیست که مثلاً یک "مگس" هم توسط یک شرکت تولید میشه، منظور این هست که از واژه ای کلی تر استفاده بشه و پیش خود اینطور در نظر بگیری که منظور از IMobility یعنی "تمامی وسایل نقلیه ی قابل حرکت".
"تمامی وسایل نقلیه ی قابل حرکت" دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" رو دارن... پس ICar محدود کننده است. حداقل در ذهن.
و اما... interface یک قالب کلی از خصیصه ها و رفتارهای خامی ایجاد می کنه که بعداً توسط کلاس هایی که اون رو پیاده سازی می کنن تغییر می کنه... من به interface ها میگم "یاد آور".
بعداً اگر قرار بر این بود که کلاسی برای دوچرخه یا موتورسیلکت داشته باشم، کلاسی با نام Bike ایجاد می کنم و اجزای IMobility رو برای اون پیاده سازی می کنم...
این طوری بسیار زیباتر خواهد بود...
در حقیقت interface بهت "یادآوری" می کنه که: "پسرم وسیله ی نقلیه ی تو حتما باید حداقل دو خصیصه ی "رنگ" و "مالک" و رفتارهای "ترمز" و "شروع حرکت" رو داشته باشه تا بتونی یک وسیله ی نقلیه حسابش کنی"
لطفاً جمله ی بالا رو 100 بار با دقت بخون ;)
موفق باشید
يكي از كاربردهاي inteface وراثت چند گانه است ، آيا تا به حال به اين مورد برخورد كرده ايد كه يك كلاس چگونه مي تواند از دو كلاس بطور همزمان ارث ببرد .در اينجا برخي از خصوصيات inteface , و كلاس abstract را بطور خلاصه بيان مي كنم ، به نظرم در اين مورد تايپيك جدا گانه اي لازم داره
خصوصيات اينترفيس
1-كاربرد در بحث وراثت چندگانه
2-اينترفيس نمي تواند عملي را انجام دهد و صرفا يك چارچوب و قاعده براي كلاسها تعريف مي كند
3-سطح دسترسي توابع و متدهاي آن تابع سطح دسترسي خود اينترفيس است
اما كلاس abstract
1-فقط مي تواند يك كلاس آن را به ارث ببرد
2-توابع و متدهاي آن مي توانند عملياتي را انجام دهند
3-توابع و متدهاي آن مي توانند سطح دسترسي داشته باشند
و .........
اما در بحث كد نويسي به نظر من داشتن يك ديكشنري براي متغيرها بسيار ضروري است ، مثلا ممكن است در چند جا شما متغيري همنام استفاده كنيد كه باعث گيجي مي شود
به نظر من قبل از آغاز كار يك قاعده براي نام گذاري قرار دهيم و هر متغيري را در ديكشنري ذخيره كنيم به اين ترتيب كه اين متغير يا كلاس و يا تابع و متد در كجا بكار رفته و چه كارهايي را انجام مي دهد تا به هنگام تعريف تابع يا متغير جديد حداقل از همنام بودن جلوگيري شود
نمي دانم تا چه حد توانستم مطلب را برسانم
با تشكر فراوان از استادان بزرگوار
دوست عزیز
طراحی به صورت
Interface >> Common Implementation >> Special Implementation
یکی از روش های خوب طراحیه
نقل قول: بحث دربارۀ گفتگوی فنی شماره یک (اصول و قواعد کد نویسی)
سلام ،
اول یه پیشنهاد ، برای تشکر در قسمت بحث دربارۀ گفتگوی فنی پاسخ ارسال نکنیم که تعداد صفحات الکی بالا نره و بشه راحت تر مطالب رو دنبال کرد ، از دکمه تشکر استفاده کنیم .
یه درخواست هم از آقایان موسوی ، مداح و عسگری دارم ، اینکه بعضی کلمات خیلی تخصصی هستن ، من که دو سالی هست با .Net حرفه ایی ! کد می زنم ، تو عمرم همچین اصطلاحاتی نشنیدم !!! اگه می شه آخر متن هایی که می نویسید ترجمه که نه ولی معادل فارسی یا اینکه این اصطلاح یعنی چه رو هم بنویسید ، مثل کتاب ها که برای کلمات سختشون * می ذارن !
ممنون .
یک چند نفری سهوا اینکار رو کردن که خودشون هم بعد از اینکه متوجه شدند , پاک کردند.
به نظرم که خیلی ساده و روان توضیح میدند , منتها به نظر من فاصله زمانی بین پستها داره زیاد میشه , که از شکل یک تاپیک داغ فاصله میگیره .
شما میتونی هر اصطلاحی رو که متوجه نشدی اینجا مطرح کنی , اصلا این تاپیک واسه همین جور موارد ایجاد شده .
نقل قول: بحث دربارۀ گفتگوی فنی شماره یک (اصول و قواعد کد نویسی)
در این کد آقای موسوی اومدن GetGrandTotal() از کد اصلی جدا کردن ، این کار باعث شده که foreach دوبار توی تکرار بشه ، درسته که خوانایی برنامه بالاتر رفته و بوی بد کد کمتر شده ولی این باعث کند شدن برنامه نمی شه شاید مجبور بشیم این foreach رو صد بار تو برنامه صدا بزنیم ! اون وقت صد بار می خواد محاسبه کنه
بهتر نیست یه foreach باشه و این تابع ها توی اون تکرار بشه ، توی کد های من این اتفاق خیلی افتاده ... ممنون .
public void PrintInvoice()
{
PrintInvoiceHeader();
decimal grandTotal = GetGrandTotal();
PrintInvoiceDetails(grandTotal);
}
private void PrintInvoiceDetails(decimal grandTotal)
{
//Print invoice items and calculate the grand total...
foreach (Item item in this.items)
{
Console.WriteLine("Id: " + item.Id);
Console.WriteLine("Name: " + item.Name);
}
//Print the grand total
Console.WriteLine("Grand Total: " + grandTotal);
}
private decimal GetGrandTotal()
{
decimal result = 0;
foreach (Item item in this.items)
result += item.Price;
return result;
}
private void PrintInvoiceHeader()
{
//Print invoice header...
Console.WriteLine(this.invoiceId);
Console.WriteLine(this.customerName);
}
ویرایش :
ای کاش تا قبل از اینکه برم سربازی اینو جواب می دادید !! چون برام خیلی مهمه ! من سه شنبه صبح باید برم ... :'(
آخرین ویرایش به وسیله majidmjh : یک شنبه 30 خرداد 1389 در 07:06 صبح
با عرض پوزش از آقای راد، ولی همینطوریش وقتی آقا صالح در مورد اصطلاحات ابهام دارن -یا از طرف بقیه صحبت می کنن-، فکر کنم تعمیم مساله حتی در این حد هم درست نباشه؛ صورت مساله Refactoring بود که آقای موسوی تمام تلاششون رو کردن تا با ساده ترین و در عین حال درست ترین زبان بیانش کنند.
البته شما استاد امثال بنده هستید ولی اگه بخواهیم در مورد ماهیت سولوشن صحبت کنیم، فکر کنم حالا حالاها در جا می زنیم؛ مثلاً IMobility هم میتونه IVehicle باشه، اونهم از IObject منشعب بشه و الا ماشا...
"وقتي يك بنده خدا محتواي كد رو نميفهمه از كجا تشخيص بده خوبه يا بد؟ اگه مخاطبان شما افراد حرفه اي هستند كه هيچ! "
آقای باقری، چرا بچه ها رو می ترسونی؟ مگه کدها چه محتوایی دارن که یه برنامه نویس معمولی، متوجه اش نشه؟ فقط اون آخراش آقای موسوی برای اینکه یکم لذت ببرن، یکم سازنده تو سازنده کردن، که هوشمندانه بوده و خوب برحسب تجربه های مکرر و بنظرم بهتره به چشم ما هم بخوره:
" به Class Diagram این کد نگاه کنید و از اون لذت ببرید"
جالب بود.اگه می شه آخر متن هایی که می نویسید ترجمه که نه ولی معادل فارسی یا اینکه این اصطلاح یعنی چه رو هم بنویسید ، مثل کتاب ها که برای کلمات سختشون * می ذارن !
چه فرقی کرده مگه؟ فقط عوض اینکه همه تو یه تابع زیر هم ردیف بشن، به چند تابع شکسته شدند ولی تو ماهیت کار هیچ فرقی نیست! foreach بازاء هربار فراخوانی تابع GetGrandTotal اجرا میشه و داخل متغیر grandTotal ریخته میشه که اونهم فقط یکبار از تابع PrintInvoice فراخوانی میشه. یعنی در اون حالت که شما میگی: عوض اینکه 100 تا foreach زیر هم بنویسی؛ 100 بار متغیری که تابع مقداردهی کرده رو استفاده میکنی، فقط همین تفاوت هست.
مساله Performance که آقای موسوی در موردش صحبت میکنن، خیلی جزئی تر از اینی هست که شما در موردش صحبت میکنید، بیشتر به روال کامپایل توابع بر میگرده تا عملکرد کد و هیچوقت یک تابع معادل کدهای زیرهم، بیشتر از اون کد بو دار اجرا نمیشه. البته چون موضوع بحث اونجا عوض شده به خودم جسارت توضیح دادم، اساتید میبخشن.
فکر کنم آقای موسوی اونقدر به ریز مسائل توجه شون معطوف شد که حوصله شون سر رفت، بابا دیگه اینهمه همنیستیم :
خدمت متولیان برنامه گفتگوی فنی شماره یک: ما داریم استفاده می کنیم؛ لطفاً ادامه بدین؛ البته مجری هم که فعلاً برنامه رو تعطیل کردن.
من چند تا نکته به ذهنم میرسه:
1) چرا Unit Testing و نیز MVC رو اینقدر خلاصه از روش گذشتید و نظر آقای موسوی رو نپرسیدین، در ضمن مثل اینکه اینا هم مثل مباحث UML هستن، نه؟ یعنی همه درموردشون صحبت میکنن ولی در عمل فقط در سطح همون حرف های قشنگ باقی میمونن! یا فکر کنم من درست توجیه نشدم؛ مثلاً Model، View، Controller و ... رو دیدم و خیلی شبیه UML و DFD و مستندسازی های مراحل هستند که اگه اینطوری باشه، آدم باید تمام پروژه ها رو بخوابونه که از اول همه چیز طراحی بشه؛ واقعاً لازمه که آدم برای آزمایش کد از این روال پیروی کنه؟ بعبارت دیگه همه که برنامه نویس وب یا دیتابیس نیستند و در پروژه های دیگه هم برای Unit Test اِ صحیح، لازمه که از این مباحث استفاده بشه یا روشهای استاندارد و عملی دیگه ای هم هست؟ چون بنده با یک مطالعه کوچک به Event هایی که Delegate ای براشون تعریف نشده و از EventHandler خود دات نت استفاده میکنند یا Singleton Pattern ها و مفاهیم چندریختی و ... توشون استفاده شده که حوصله برنامه نویسان رو شدیداً مورد آزمایش قرار میدن! منظورم اینه که اگه بخواهیم محیط توسعه مون بقول آقای موسوی، Brownfield نباشه ولی برای هر چیز جزئی هم نیاز به اينترفيس IModel و Observer و رویدادهای اطلاع رسانی و ... نداشته باشیم باید چکار کنیم؟ اینا بیشتر توسعه دهنده رو فراری میدن تا ترغیب به تمیزی/نظافت یا بوی خوب کد.
خوب اگه قرار باشه اینهمه پیچیدگی بیاد سمت برنامه نویس، پس صد و خرده ای مگ برای پلت فرم دات نت رو برای چی رو سرورهامون نصب می کنیم؟ با همون ++C/C کدهامونُ می نوشتیم دیگه
2) Divergent Change (تغییر واگرا) و Shotgun Surgery رو میشه بیشتر توضیح بدین؟ من نوعی تو برخی کدهام، فکر میکنم که درست تر از این دیگه نمیشه و از زمان و وقتم هم هزینه میکنم و دنبال کدهای تمیز مشابه و قابل استفاده برای نمونه می گردم و ... ولی باز هم - علیرغم دقت اولیه- طی زمان همچین مشکلاتی شبیه اون چیزی که آقای موسوی فرمودن برام پیش میاد. اینا دیگه Refactoring نیستند که تو توسعه نهایی سیستم تاثیری نداشته باشند؛ باید هزاران خط کد از اول بهینه سازی بشه یا دید توسعه دهندگان سیستم عوض بشه و بردارن تمام اجداد کلاسها رو بهینه نویسی کنند که اونهم معلوم نیست بازم Refused Bequest بشن یا نه! اینا واقعاً تو پروژه هایی که پرونده شون مثلاً بسته شده و تغییرات جزئی میخوان هزینه بر و اعصاب خوردکن هست؛ چه راه حلی پیشنهاد می کنید؟ یا بنظرتون از این به بعد چی کار کنیم بهتره؟
خیلی از به اشتراک گذاشتن تجربیات ارزشمند خودتون تشکر میکنم.
StyleCop صرفا برای #C هست یا برای کدهای VB.Net هم کاربرد داره؟
فقط برای C# هست... البته از "برخی" رهنمون هایی که میده می تونی ایده بگیری و در VB هم پیاده سازی کنی.
موفق باشید.
سلام اقا بهروز
من دلیل بعضی رهنمود هاشو نفهمیدم
مثلا اینکه اسم متغیر با حرف بزرگ شروع نشه یا اکثر مواقع پیشنهاد میده متغیر از نوع var تعریف بشه دلیل این ها چیه؟
ممنون
البته سوال شما مربوط به Visual Studio هست، و در این بحث هم مثال های ارائه شده مربوط به #C و Visual Studio 2010 هستند؛ اما اگر دوستانی از سایر IDEها استفاده می کنند، می تونند معمولا امکانات مشابه قابلیت های مطرح شده در این تاپیک را در IDEهای مورد استفاده خودشان هم پیدا کنند.StyleCop صرفا برای C# هست یا برای کدهای VB.Net هم کاربرد داره؟
به عنوان نمونه؛ دوستانی که از RAD Studio (برای دلفی و C++ Builder) استفاده می کنند، می تونند با استفاده از گزینه Refactoring، در Context menu مربوط به Code Editor، یا استفاده از منوی Refactor، عمل Refactoring را انجام بدند:
refactoring.jpg
برای قابلیتی مشابه StyleCop، هم می تونند از منوی Project گزینه QA Audits را انتخاب کنند، و برای این کار نیاز به نصب ابزار جانبی نیست:
qa_audits.jpg
در IDEهای دیگه هم ممکنه بتونید این قابلیت ها را پیدا کنید، یا با استفاده از ابزارهای جانبی، این قابلیت ها را به IDE مورد نظرتان اضافه کنید.
وَ سَيَعْلَمُ الَّذِينَ ظَلَمُوا [آل محمد حقهم] أَيَّ مُنْقَلَبٍ يَنْقَلِبُونَ - الشعراء (227)
و ظالمین [حق آل محمد (ص) ] به زودی خواهند دانست که به کدام بازگشتگاه بازخواهند گشت.
اینها به همون قواعد نامگذاری بر میگرده که برادران موسوی و مداح در مورد برخی از اونها توضیح دادند.
استفاده از var رو فقط برای Anonymous Types پیشنهاد می کنم. زمانی که نوع متغیر یا شی ای رو می دونید، از var استفاده نکنید چون باعث کاهش خوانایی برنامه میشه.
موفق باشید.
سلام.
ببخشید سوال منحصر به شخص خاصی بود ولی گفتم جواب بدم..
پیشنهاد میکنم Documentation این ابزار رو هم دانلود کنید که دلیل وجود چنین قوانینی رو در اون کاملا توضیح داده.
مثلا برای همین سوال که اسم متغیر با حروف بزرگ نمایش داده نشه این جواب رو داره:
A violation of this rule occurs when the name of a field or variable begins with an upper-case letter. Field and variable names must begin with a lower-case letter, unless the field is public or internal, const, or non-private and readonly. In these cases, the field should begin with an upper-case letter.
If the field or variable name is intended to match the name of an item associated with Win32 or COM, and thus needs to begin with an upper-case letter, place the field or variable within a special NativeMethods class. A NativeMethods class is any class which contains a name ending in NativeMethods, and is intended as a placeholder for Win32 or COM wrappers. StyleCop will ignore this violation if the item is placed within a NativeMethods class.
Close your eyes, take a deep breath, click your heels three times, and say, "There's no better thing than Inversion of Control and Dependency Injection, generic specialization, the decorator pattern, chains of responsibilities, and extensible software."
Design Guidelines for Developing Class Libraries عنوان مجموعه ای هست که بعضی از قسمتهای اون تقریبا مرتب با موضوعات تاپیک هست که خوندنش قطعا مفید خواهد بود . به گفته خودشون :
It is strongly recommended that you follow these design guidelines when developing classes and components that extend the .NET Framework. Inconsistent library design adversely affects developer productivity and discourages adoption.Guidelines for NamesDescribes guidelines for naming types and members in class libraries.
Type Design GuidelinesDescribes guidelines for using static and abstract classes, interfaces, enumerations, and structures.
Member Design GuidelinesDescribes guidelines for designing and using properties, methods, constructors, fields, events, and operators. This section also describes best practices for designing parameters.
Designing for ExtensibilityDescribes guidelines for designing libraries that can be extended.
Design Guidelines for ExceptionsDescribes design guidelines for designing, throwing, and catching exceptions.
Usage GuidelinesDescribes guidelines for using arrays and attributes, and guidelines for implementing equality operators.
Internal Coding Guidelines هم مقاله ای هست که به صورت خلاصه مواردی دیگری رو پیشنهاد میکنه .
یک سوال کوتاه:
قشنگتره که پراپرتی های کلاس رو کجای ادیتور بنویسیم؟
یعنی ترتیب تعاریف اجزا، مثلا:
اول سازنده
بعد پراپرتی ها
بعد متدها
----یا
اول پراپ ها
بعد سازنده
بعد متد ها
آخر سر هم مخرب کلاس و...
کدوم یکیش؟
اینطوری خوبه؟
calss x
{
constructor(){}
props;
methodes(){}
~destructor(){if needed}
}
قرار نیست گفتگوی بعدی رو شروع کنید ؟
در یک ماه اخیر آقای مداح تنها یک پست در این تاپیک داشتند , فکر نمیکنید اینو تمومش کنید بهتره ؟
قوانین ایجاد تاپیک در تالار
