افشار محبی افشار محبی
نظرات نظرسنجی‌ها
آیا با وجود سی‌ام‌اس فروشگاهی قدرتمندی مثل nopCommerce یا SmartStore آیا منطقی است که ما دوباره خودمان از صفر کد بزنیم؟
با این که کار من نوشتن از صفر است و اگر قرار باشد چیزی از صفر نوشته نشود من هم در آن پروژه نخواهم بود، اما به طور کلی با نوشتن از صفر میانه خوبی ندارم. ترجیح می‌دهم گزینه نوشتن از صفر را به عنوان آخرین گزینه بررسی کنم. نوشتن از صفر بیشتر مناسب پروژه هایی است که مشابه شان وجود نداشته باشد. در کاربردی مثل فروشگاه اینترنتی که خیلی عام به نظر می‌رسد ترجیحم این است که از یک سورس موجود استفاده کنم.
استفاده مجدد از پروژه‌های موجود که تعداد زیادی نصب از آن زیر بار است ارزان‌تر و سریع‌تر از «نوشتن از صفر» به نظر می‌رسد. خیلی از اوقات نوشتن از صفر به معنای اتلاف منابع است.
‫۷ سال و ۵ ماه قبل، یکشنبه ۱۰ اردیبهشت ۱۳۹۶، ساعت ۲۱:۳۰
فرید بکران فرید بکران
مطالب
بررسی Bad code smell ها: درخت ارث بری موازی یا Parallel inheritance hierarchy
این کد بد بو در دسته «جلوگیری کنندگان از تغییر» قرار می‌گیرد. اگر زمان ایجاد یک کلاس فرزند برای کلاسی، مجبور به ایجاد یک کلاس فرزند متناظر آن برای کلاس دیگری باشید، با این کد بد بود مواجه هستید. 
معمولا زمانی این اتفاق می‌افتد که یک درخت ارث بری به درخت ارث بری دیگری وابسته باشد. به‌طوری که هر یک از کلاس‌های موجود در آن، با یک کلاس در درخت دیگر متناظر باشند و ارتباط داشته باشند. این امر ایجاد تغییرات در کد را با مشکل مواجه خواهد کرد. 
به طور مثال: 
public abstract class InvoiceGenerator 
{ 
    public abstract dynamic Generate(); 
} 
public abstract class AmountCalculator 
{ 
    public abstract decimal Calculate(dynamic item); 
}
public class StandardInvoiceGenerator : InvoiceGenerator 
{ 
    public override dynamic Generate() 
    { 
        return new object(); 
    } 
} 
public class StandardInvoiceAmountCalculator : AmountCalculator 
{ 
    public override decimal Calculate(dynamic item) 
    { 
        return 1; 
    } 
} 
public class PrepaymentInvoiceGenerator : InvoiceGenerator 
{ 
    public override dynamic Generate() 
    { 
        return new object(); 
    } 
} 
public class PrepaymentInvoiceAmountCalculator : AmountCalculator 
{ 
    public override decimal Calculate(dynamic item) 
    { 
        return 1; 
    } 
}

در این مثال کلاسی به نام InvoiceGenerator وجود دارد که کلاس پدر تولید کنندگان فاکتور است و کلاس دیگری نیز وجود دارد به نام AmountCalculator که کلاس پدر محاسبه قیمت است. هر یک از سازندگان فاکتور، یک کلاس متناظر در درخت Caluclator‌ها دارند؛ برای محاسبه قیمت آیتم‌های آن نوع فاکتور. به طور خاص در این مثال فاکتور استاندارد و فاکتور پیش پرداخت نوشته شده است  (در این مثال فقط یک سطح از ارث بری پیاده سازی شده است و تمامی کلاس‌ها مستقیما از کلاس پدر به ارث برده می‌شوند. در صورت وجود چند سطح ارث بری، مشکل پیچیده‌تر نیز خواهد شد).
حال فرض کنید قصد افزودن یک کلاس را برای ایجاد «فاکتور گزارش مخارج» (فاکتوری برای ثبت مخارجی که کارکنان زمان انجام کار برای کارفرما متحمل می‌شوند) دارید.
در این حالت نیاز است که یک کلاس ExpenseReportInvoiceGenerator ساخته شود و متناظر با آن نیاز خواهد بود کلاس ExpenseReportAmountCalculator ساخته شود. 

چرا چنین بویی به راه می‌افتد 

دلایل بوجود آمدن چنین بویی به سه دسته تقسیم می‌شوند: 

  • تشخیص نادرست روابط بین کلاس‌ها  
  • استفاده نامناسب از الگوهای طراحی 
  • تشخیص نادرست مسئولیت‌های کلاس‌ها و طراحی نامناسب آن 


روش‌های اصلاح این کد بد بو  

اصلاح چنین بوی بدی آسان نیست؛ زیرا درخت‌های ارث بری موازی، همیشه اتفاقی اشتباه نیستند و معمولا زمانیکه اصل Single responsibility در کدها به طور وسیعی رعایت شود، احتمال به‌وجود آمدن چنین الگویی وجود دارد؛ مانند مثالی که ذکر شد. در مثال مطرح شده اصل Single responsibility به درستی رعایت شده‌است. 
در برخورد با چنین بویی معمولا سه راه وجود دارد. 
اول:  عدم تغییر درخت‌های ارث بری موازی 
معمولا در مواردی مانند مثال ذکر شده در این مطلب، بهترین گزینه، عدم تغییر درخت ارث بری است. اگر رعایت کردن اصل single responsibility مهمتر از سادگی در ایجاد تغییرات باشد، این گزینه یک انتخاب خوب خواهد بود. یکی از مزایای دست نخوردن کدهایی مانند مثال مذکور، سهولت در نوشتن تست‌های واحد است. 

دوم: تبدیل درخت ارث بری به یک درخت ارث بری ناقص
در این روش می‌توان interface هایی را برای AmountCalculator و InvoiceGenerator ساخت و کلاس‌هایی که این دو interface را پیاده سازی می‌کنند؛ مانند:  
public interface IInvoiceGenerator 
{ 
    dynamic Generate(); 
} 
public interface IAmountCalculator 
{ 
    decimal Calculate(dynamic item); 
} 
public class StandardInvoiceGenerator : IInvoiceGenerator, IAmountCalculator 
{ 
    public dynamic Generate() 
    { 
        return new object(); 
    } 
    public decimal Calculate(dynamic item) 
    { 
        return 1; 
    } 
} 
public class PrepaymentInvoiceGenerator : IInvoiceGenerator, IAmountCalculator 
{ 
    public dynamic Generate() 
    { 
        return new object(); 
    } 
    public decimal Calculate(dynamic item) 
    { 
        return 1; 
    } 
}
با این تغییر، بخشی از اصل single responsibility نادیده گرفته شده‌است. اما با وجود یک درخت ارث بری فیزیکی، درخت منطقی موجود دست نخورده باقی مانده و در صورت نیاز می‌توان دوباره اقدام به جداسازی مسئولیت‌ها کرد. این جداسازی بیشتر اوقات زمانی اتفاق می‌افتد که یکی از جنبه‌های مسئولیتی یک کلاس، در جای دیگری به صورت مستقل مورد استفاده قرار گیرد. 

سوم: از بین بردن درخت ارث بری موازی 
این روش تقریبا مشابه روش ذکر شده در بخش دوم است. تنها با این تفاوت که در این روش، رابطه منطقی ارث بری موازی نیز حذف می‌شود؛ مانند: 
public abstract class InvoiceGenerator 
{ 
    public abstract dynamic Generate(); 
    public abstract decimal CalculateItemAmount(dynamic item); 
} 
public class StandardInvoiceGenerator : InvoiceGenerator 
{ 
    public override dynamic Generate() 
    { 
        throw new NotImplementedException(); 
    } 
    public override decimal CalculateItemAmount(dynamic item) 
    { 
        throw new NotImplementedException(); 
    } 
} 
public class PrepaymentInvoiceGenerator : InvoiceGenerator 
{ 
    public override dynamic Generate() 
    { 
        throw new NotImplementedException(); 
    } 
    public override decimal CalculateItemAmount(dynamic item) 
    { 
        throw new NotImplementedException(); 
    } 
}
در این روش دو درخت ارث بری از نظر منطقی و فیزیکی با یکدیگر ادغام شده‌اند. البته همان طور که در بخش یک گفته شد، بهترین گزینه برای مثال ذکر شده در این مطلب، دست نخوردن آن است. این روش زمانی مناسب است که موجودیت‌های ادغام شده از نظر ذاتی به قدری به یکدیگر شباهت داشته باشند که عملا بتوانیم آن‌ها را یک موجودیت مستقل در نظر بگیریم. 

جمع بندی 

روش‌های رفع بوی بد «درخت‌های ارث بری موازی» به زمینه ایجاد آنها وابستگی شدیدی دارد. به همین دلیل نمی‌توان راه حلی کلی را برای آن ارائه داد. سه روش ذکر شده در این مطلب در واقع سه نوع رفتاری هستند که می‌توان با چنین بوی بدی داشت. بسته به زمینه ایجاد این بوی بد و شرایط کد می‌توان هر یک از این روش‌ها را انتخاب نمود. نکاتی مانند سهولت نگهداری، تست نویسی آسان و خوانایی کد، فاکتورهایی هستند که می‌توانند در تصمیم گیری مد نظر قرار گیرند.
‫۷ سال و ۲ ماه قبل، یکشنبه ۸ مرداد ۱۳۹۶، ساعت ۱۴:۲۰
رضا پویا رضا پویا
مطالب
تزریق وابستگی‌ها در ASP.NET Core - بخش 1 - مقدمه
مقدمه

زمانیکه یک برنامه را بر پایه‌ی شیء گرایی طراحی می‌کنید و می‌نویسید، به صورت معمول جریان وابستگی‌ها در برنامه‌ی شما به صورت زیر است:


 
در این حالت برای کامپایل شدن برنامه نیاز است که فرآیند کامپایل از دورترین کلاس و متد شروع شود. همانطور که می‌بینید در اینجا هر کلاس به تمام زیر کلاس‌های خود وابسته است و هر تغییر در هر کدام از کلاس‌های خدمتگزار می‌تواند تاثیرات مستقیمی بر روی سایر کلاس‌ها داشته باشد. در واقع جریان کنترل برنامه‌ی ما بجای اینکه در اختیار کلاس‌های سیاست گذار ( کلاس‌های بالایی در شکل) باشد، به دست کلاس‌های خدمتگزار افتاده است.  این قضیه باعث درهم تنیدگی و جفت شدگی کدها و کلاس‌ها به یکدیگر می‌شود که مشکل‌زاست و امکان نگهداری، تغییرات و توسعه‌ی برنامه را به شدت کاهش می‌دهد.

به عبارت دیگر در طراحی ساخت یافته، کلاس‌های سطح بالا، به کلاس‌های سطح پایین وابسته‌اند. این مسئله دو مشکل را ایجاد می‌کند:
  1. هر تغییری در کلاس‌های سطح پایین ممکن است باعث ایجاد اشکالی در کلاس‌های سطح بالا گردد.
  2. استفاده‌ی مجدد از کلاس‌های سطح بالا در جاهای دیگر مشکل است؛ زیرا وابستگی مستقیمی به کلاس‌های سطح پایین دارند.

اصل معکوس سازی / وارونگی وابستگی‌ها Dependency Inversion Principle
 
یکی از اصول پنجگانه‌ی طراحی برنامه‌های شیء گرا  که با نام اصول SOLID  شناخته می‌شوند، اصل «وارونگی وابستگی‌ها» است که روشی برای مشکل جفت شدگی و وابستگی کلاس‌ها به یکدیگر را به صورت تئوری ارائه می‌دهد.

 اصل وارونگی وابستگی‌ها بیان می‌کند:
  •   ماژول‌های (کلاس‌های) سطح بالا نباید به ماژولهای (کلاس‌های) سطح پایین وابسته باشند و هر دو باید به انتزاعات وابسته باشند (برای مثال interface‌ها).
  •   انتزاعات نباید وابسته به جزئیات باشند؛ بلکه جزئیات (پیاده سازی) باید وابسته به انتزاعات باشند.

بر اساس این اصل، ما باید در سطوح بالا سیاست گذاری‌ها و انتزاعات را در قالب interface‌ها تعریف کرده و کلاس‌های سطح بالای خود را بر همین اساس پیاده سازی کنیم و در سطوح پائین‌تر، پیاده سازی‌هایی را بر اساس انتزاعات و سیاست گذاری‌های سطوح بالاتر، انجام دهیم.

در شکل زیر، حالت عادی جریان کنترل را می‌بینید .
 


همانطور که می‌بینید، کلاس M برای اجرا، وابسته به کلاس N و متد F در درون آن است. در اینجا ما با استفاده از اینترفیس‌ها می‌توانیم جریان کنترل را معکوس یا وارونه کنیم که به این عمل «وارونگی کنترل یا Inversion of Control» می‌گویند.


 
شیء گرایی در واقع در مورد نحوه‌ی جریان کنترل است. در اینجا اینترفیس‌ها به ما کنترل کاملی را بر جریان کنترل (Flow of control) می‌دهند که با استفاده از این امکان می‌توانیم از نوشتن کدهای جفت شده، شکننده و کلاس‌هایی یکبار مصرف، بپرهیزیم.


الگوی Dependency Injection 
تزریق وابستگی یا Dependency Injection، یک الگوی طراحی است که از آن برای طراحی و پیاده سازی IoC Container‌ها استفاده می‌شود. این الگو به ما اجازه می‌دهد که اشیاء وابسته را خارج از کلاس بسازیم و آنها را به طریقی دیگر به کلاس، جهت استفاده ارائه دهیم. به‌وسیله‌ی DI ما ساخت و اتصال اشیاء وابسته به کلاس را از تعریف آن خارج می‌کنیم.

الگوی تزریق وابستگی 3 نوع کلاس را درگیر می‌کند:
  •  کلاس کلاینت / Client Class : کلاس کلاینت (کلاس وابسته) کلاسی است که به کلاس سرویس وابسته است .
  • کلاس سرویس  /  Service Class :  کلاس سرویس (وابستگی) کلاسی است که یک سرویس را به کلاس کلاینت ارائه می‌دهد.
  •  کلاس تزریق کننده / Injector Class  :  کلاس تزریق کننده، نمونه‌ای از کلاس سرویس را ساخته و به کلاس کلاینت، تزریق می‌کند.

شکل زیر وابستگی بین کلاس‌ها را شرح می‌دهد:

 
همانطور که می‌بینید، کلاس Injector، نمونه‌ای از کلاس سرویس را می‌سازد و آن را به نمونه‌ای از کلاس Client تزریق می‌کند. با این کار، DI، وظیفه‌ی ساخت یک نمونه از کلاس Service را از درون کلاس Client جدا می‌کند.

انواع تزریقات وابستگی‌ها:
به صورت کلی به سه روش و در سه مکان، امکان تزریق وابستگی کلاس سرویس، درون کلاس کلاینت وجود دارد:
  •   تزریق درون سازنده / Constructor Injection  : در تزریق درون سازنده، در سازنده‌ی کلاس کلاینت، لیستی از سرویس‌های مورد نیاز کلاس، که کلاس، برای عملکرد خود به آن‌ها «وابسته» است، ثبت می‌شوند و کلاس Injector، سرویس (وابستگی) مورد نظر را درون سازنده‌ی کلاس Client ارائه می‌دهد.
  •   تزریق درون Property  کلاس / Property Injection : در این حالت که همچنین با نام (Setter Injection) هم شناخته می‌شود، تزریق کننده، وابستگی را به وسیله‌ی یک Property عمومی کلاس کلاینت ارائه می‌دهد.
  •  تزریق درون متد / Method Injection  : در این حالت، خود کلاس کلاینت، یک پیاده سازی از یک interface را ارائه می‌کند که درون آن متدهایی برای ارائه‌ی وابستگی‌ها به کلاینت تعریف شده‌اند. در این وضعیت، تزریق کننده از این اینترفیس برای ارائه‌ی وابستگی‌ها به کلاینت درون متدها، استفاده می‌کند. 

هر کدام از روش‌های فوق مزایا و معایب خود را دارند، ولی در NET Core. بیشتر از «تزریق درون سازنده» استفاده می‌شود. در صورت لزوم می‌توانید از اینجا نمونه‌هایی از تزریق وابستگی را به هر کدام از سه روش بالا، مشاهده کنید.

Inversion of Control Container
در واژگان فنی مهندسی نرم افزار، Container (محفظه)  به جزیی از برنامه گفته می‌شود که می‌تواند اجزای دیگر برنامه را در بر بگیرد.  IoC Container ‌ها در واقع فریم ورک‌ها/چارچوب‌ها یا کتابخانه‌های برنامه نویسی هستند که ما در آنها می‌توانیم اشیاء مختلف را به سبک‌های خاصی تعریف و ثبت کنیم و در مواقع لزوم آنها را واکشی و به کلاس‌ها تزریق کنیم. معمولا  IoC Container‌ها لیستی از اشیاء هستند که در آن اینترفیس‌ها و پیاده سازی‌های مربوط به هر کدام از آن‌ها ثبت می‌شوند. درون IoC Container برای پیاده سازی اصل وارونگی وابستگی‌ها، معمولا از یکی از دو الگوی زیر استفاده می‌کنند (گاها هم دو الگو را با هم پیاده سازی می‌کنند) :
  •  Dependency Injection 
  • Service Locator

تمرکز اصلی ما در این نوشتار بر روی DI Container هاست. فرق Dependency Injection و Service Locator در این است که در DI، وابستگی‌ها توسط IoC Container از درون محفظه واکشی می‌شوند و به درون کد تزریق می‌شوند ولی در Service Locator در هر جایی از برنامه می‌توان با استفاده‌ی مستقیم از Container و با استفاده از متدهایی که به ما ارائه می‌دهد،  پرس و جو کرد (کوئری زد) و وابستگی مورد نظر را واکشی کرد.
در تزریق وابستگی، کلاس استفاده کننده از سرویس‌ها، درگیر نحوه‌ی واکشی و نمونه سازی از سرویس مورد نظر خود نمی‌شود و همه‌ی کار توسط DI Container انجام می‌گیرد. ولی در Service Locator باید سرویس مورد نظر، درون خود کلاس، مستقیما از Container دریافت و ساخته شود.
برای استفاده از Service Locator، تنها پیش نیاز، دسترسی به شیء Service Locator است.

به صورت کلی IoC Container ‌ها سه وظیفه‌ی اساسی را برعهده دارند:
  • ثبت سرویس درون خود
  •   ساخت نمونه‌های مورد نظر از سرویس‌ها و ارائه دادن آن‌ها به کلاس‌هایی که نیاز دارند.
  •  از بین بردن نمونه سرویس‌های ساخته شده (Dispose) کردن آن‌ها .

در ادامه با ساخت پروژه‌ای، اولین سرویس خودمان را درون Microsoft Dependency Injection Container یا به اختصار DI Container، ثبت کرده و آن را واکشی می‌کنیم.
‫۴ سال و ۴ ماه قبل، یکشنبه ۴ خرداد ۱۳۹۹، ساعت ۰۶:۴۰
وحید نصیری وحید نصیری
بازخوردهای دوره
اجزای جاوا اسکریپتی بوت استرپ 3
- در حالت کلی برای عیب یابی مشکلات نیاز است با «نحوه استفاده از افزونه Firebug برای دیباگ برنامه‌های ASP.NET مبتنی بر jQuery» آشنا باشید. همچنین این مطلب هم مفید است.
- در حال حاضر، کاملترین بسته‌ی راست به چپ بوت استرپ 3 را در این آدرس می‌توانید دریافت کنید.
- مثال پیوست شده در انتهای بحث، فایل‌های کاملی دارد و آزمایش شده.
‫۹ سال و ۱۲ ماه قبل، جمعه ۲ آبان ۱۳۹۳، ساعت ۱۷:۴۰
وحید نصیری وحید نصیری
بازخوردهای دوره
افزونه‌ای برای کپسوله سازی نکات ارسال یک فرم ASP.NET MVC به سرور توسط jQuery Ajax
این افزونه خروجی ساده متنی داره. اگر نیاز به بازگرداندن اطلاعات بیشتر و ساختار یافته‌ای هست، باید خروجی JSON براش طراحی کنید و بعد در سمت jQuery Ajax این ساختار مدنظر رو پردازش کنید. مثلا ساختاری بر اساس خواصی مانند لیست خطاها، لیست پیام‌ها و وضعیت عملیات. بعد قسمت complete افزونه فوق باید کلا بازنویسی شود.
‫۱۱ سال و ۵ ماه قبل، چهارشنبه ۲۲ خرداد ۱۳۹۲، ساعت ۰۱:۲۶
حسامتم حسامتم
نظرات اشتراک‌ها
تقویم شمسی رسپانسیو برای بوت استراپ
اینم یه تقویم فارسی  که هم تاریخ شمسی داره و هم میلادی. دو تا attribute داره .میتونید با jquery معادل میلادی روزی که انتخاب میشه رو بگیرید و اون و ذخیره کنید یا هر کار دیگه. مثلا واسه امروز اینطوریه 
 data-jdate="1395/5/5"  data-gdate="2016/7/26"

  
‫۷ سال و ۱۱ ماه قبل، شنبه ۱۵ آبان ۱۳۹۵، ساعت ۱۵:۲۱
وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
کتابخانه Sortable

Sortable is a JavaScript library for reorderable drag-and-drop lists on modern browsers and touch devices. No jQuery. Supports Meteor, AngularJS, React, Polymer, Knockout and any CSS library, e.g. Bootstrap.  Demo

کتابخانه Sortable
‫۷ سال و ۴ ماه قبل، دوشنبه ۲۹ خرداد ۱۳۹۶، ساعت ۰۸:۰۸
وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
کتابخانه google-places

A jQuery plugin to render google places data. Currently the only only thing that is rendered is a list view of reviews.  Demos 

npm install google-places-data
bower install google-places
کتابخانه google-places
‫۷ سال و ۵ ماه قبل، سه‌شنبه ۲۶ اردیبهشت ۱۳۹۶، ساعت ۱۴:۳۷
وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
کتابخانه gridstack.js

gridstack.js is a jQuery plugin for widget layout. This is drag-and-drop multi-column grid. It allows you to build draggable responsive bootstrap v3 friendly layouts. It also works great with knockout.js, angular.js and touch devices.  Demo  Demo

کتابخانه gridstack.js
‫۷ سال و ۶ ماه قبل، چهارشنبه ۱۶ فروردین ۱۳۹۶، ساعت ۰۵:۴۷