<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های محدثه انتظاری</title>
        <link>https://virgool.io/feed/@mohadese.entezari</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-16 08:30:18</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/1485880/avatar/r4ALDI.jpg?height=120&amp;width=120</url>
            <title>محدثه انتظاری</title>
            <link>https://virgool.io/@mohadese.entezari</link>
        </image>

                    <item>
                <title>Strategy Pattern</title>
                <link>https://virgool.io/@mohadese.entezari/strategy-pattern-rq4glirpqt5q</link>
                <description>چرا گاهی باید رفتارهای برنامه را قابل تعویض کنیم؟در بسیاری از پروژه‌ها یک کار را می‌توان به چند روش انجام داد:محاسبه قیمت، ارسال نوتیفیکیشن، اعتبارسنجی، یا تعیین روش حمل‌ونقل.اگر این رفتارها را داخل یک متد با if/else کنترل کنیم،کدمان کم‌کم تبدیل می‌شود به یک بخش شلوغ، غیرقابل‌تست و سخت‌توسعه.اگر از Strategy Pattern استفاده نکنیم چه می‌شود؟فرض کنید کد ما این شکلی باشد:public decimal CalculateCost(string type, decimal distance)
{
    if (type == &quot;courier&quot;)
        return 10000 + distance * 2000;

    if (type == &quot;post&quot;)
        return 40000;

    if (type == &quot;express&quot;)
        return 20000 + distance * 3500;

    throw new Exception(&quot;invalid type&quot;);
}
مشکلاتش:اضافه کردن هر روش جدید : باید همین متد را تغییر دهیمنقض اصل Open/Closedبالا رفتن احتمال بروز باگتست‌پذیری پایین (تست یک رفتار، کل متد را درگیر می‌کند)شرط‌های تودرتو و پیچیدگی زیاد با بزرگ شدن کسب‌وکاررفتار برنامه در runtime قابل تعویض نیستاین دقیقاً همان چیزی است که Strategy Pattern حل می‌کند.Strategy Pattern دقیقاً چه کاری انجام می‌دهد؟هر الگوریتم را در یک کلاس مستقل قرار می‌دهدهمه رفتارها یک اینترفیس مشترک دارندContext فقط با Interface کار می‌کند، نه با جزئیاترفتار برنامه را می‌توان در زمان اجرا تغییر دادنتیجه؟کدی ساده‌تر، قابل تست‌تر، قابل توسعه‌تر و مطابق اصول SOLIDمثال کاربردی: سیستم محاسبه هزینه ارسالفرض کنید در یک فروشگاه سه روش ارسال داریم:Courier : هزینه براساس مسافتPost : هزینه ثابتExpress Delivery : ترکیب ثابت + متغیربه جای اینکه چند شرط بنویسیم،برای هر روش یک strategy مستقل می‌سازیم1. تعریف Interface مشترکpublic interface ICalculateTransportingCostStrategy
{ 

    decimal Calculate(decimal distanceInKm); 

}2. پیاده‌سازی استراتژی‌هاpublic class CourierStrategy : ICalculateTransportingCostStrategy
{
    public decimal Calculate(decimal distanceInKm)
    {
        return 10000 + distanceInKm * 2000;
    }
}

public class PostStrategy : ICalculateTransportingCostStrategy
{
    public decimal Calculate(decimal distanceInKm)
    {
        return 40000;
    }
}

public class ExpressStrategy : ICalculateTransportingCostStrategy
{
    public decimal Calculate(decimal distanceInKm)
    {
        return 20000 + distanceInKm * 3500;
    }
}3. کلاس Contextpublic class TransportCostCalculator
{
    private readonly ICalculateTransportingCostStrategy _strategy;

    public TransportCostCalculator(ICalculateTransportingCostStrategy strategy)
    {
        _strategy = strategy;
    }

    public decimal Calculate(decimal distanceInKm)
    {
        return _strategy.Calculate(distanceInKm);
    }
}4. نحوه استفاده از Strategyvar calculator = new TransportCostCalculator(new ExpressStrategy());
var cost = calculator.Calculate(12);
Console.WriteLine(cost);و برای تغییر رفتار:calculator = new TransportCostCalculator(new PostStrategy());مزایای Strategyتعویض رفتار برنامه در runtimeپیروی از Open/Closed Principleحذف شرط‌های طولانی if/switchساده‌تر شدن تست واحدجدا کردن رفتار از Context (ترکیب به‌جای وراثت)افزایش خوانایی و انعطاف‌پذیریمعایب Strategyاگر الگوریتم‌ها کم باشند ⇒ کد اضافی و پیچیدگی بی‌دلیلClient باید بداند کدام Strategy مناسب استگاهی می‌توان به‌جای Strategy از lambda / delegate استفاده کرد (در زبان‌های مدرن)کلاس‌ها و فایل‌های بیشتری ایجاد می‌شودجمع‌بندیStrategy زمانی مناسب است که:یک کار چند روش مختلف داشته باشدرفتار برنامه باید قابل تعویض باشدبخواهیم از if/else‌های زیاد خلاص شویمبخواهیم برنامه مطابق SOLID و قابل توسعه باشد</description>
                <category>محدثه انتظاری</category>
                <author>محدثه انتظاری</author>
                <pubDate>Fri, 14 Nov 2025 16:46:37 +0330</pubDate>
            </item>
                    <item>
                <title>آشنایی با تکنیک User Story Mapping در مدل‌سازی دامین‌های پیچیده</title>
                <link>https://virgool.io/@mohadese.entezari/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D8%AA%DA%A9%D9%86%DB%8C%DA%A9-user-story-mapping-%D8%AF%D8%B1-%D9%85%D8%AF%D9%84-%D8%B3%D8%A7%D8%B2%DB%8C-%D8%AF%D8%A7%D9%85%DB%8C%D9%86-%D9%87%D8%A7%DB%8C-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-xfndwdxlcxba</link>
                <description> تکنیک User Story Mapping یک تمرین بصری است که به مدیران محصول و تیم‌های توسعه کمک می‌کند تا کاری را تعریف کنند که تجربه کاربری خوبی ایجاد کند. از آن برای بهبود درک شما از مشتریان و اولویت‌بندی کار استفاده می‌شود.با نوشتن user story، نیازها و اهداف کاربران نهایی را در مرکز گفتگو قرار می‌دهیم. یک توضیح کوتاه و مکتوب به زبان ساده از نحوه عملکرد نرم افزار از دیدگاه کاربر نهایی است: مزایای آن چیست و آنها از محصول چه انتظاراتی دارند. ویژگی محصول را توصیف نمی‌کند، اما هدف نهایی را که کاربر می‌خواهد هنگام استفاده از نرم افزار به آن دست یابد، تعریف می‌کند.چگونه یک User Story Map بسازیم؟گام به گامگام 1: Define user personasبیایید با پرسوناهای کاربری شروع کنیم. توصیه می‌کنیم با یک پرسونا (معمولی‌ترین) کاربری شروع کرده و سپس به مراحل بعدی بروید. بعداً می‌توانید پرسوناهای بیشتری جمع‌آوری کرده و فرآیند User Story Mapping را طی کنید.کاربران اصلی محصول یا خدمات خود را به صورت زیر توصیف کنید:- معرفی کوتاهی از کاربر- توصیف اهداف کاربر- جمع‌آوری مشکلاتی که باید حل شوندمثال:معرفی کوتاه:دکتر احمدی یک پزشک عمومی با بیش از 15 سال سابقه کاری در یک کلینیک خصوصی است. او روزانه بیش از 30 بیمار را ویزیت می‌کند و به دنبال راه‌هایی برای بهبود کارایی خود است.اهداف کاربر:نوشتن نسخه‌های الکترونیکی به سرعت و با دقتدسترسی سریع به تاریخچه پزشکی بیمارانمشکلات و چالش‌ها:کند بودن سیستم‌های فعلی و پیچیدگی کار با آنهانیاز به وارد کردن دستی اطلاعات بیمارانگام 2: Discover user goalsاگر پرسوناهای کاربری اولیه را داشته باشیم، می‌توانیم اطلاعاتی که در بخش اهداف کاربر جمع‌آوری کرده‌ایم را به فعالیت‌ها تقسیم کنیم. اهداف کاربر باید روی sticky note یا Virtual Cardنوشته شوند. تمرکز بر این باشد که کاربر چه چیزی می‌خواهد به دست آورد (نوشتن نسخه الکترونیکی)، نه مراحل انجام آن (مثلاً باز کردن وبسایت).مثلاً اگر هدف کاربر &quot; نوشتن نسخه الکترونیکی &quot; باشد، مراحل می‌تواند شامل &quot;استعلام اطلاعات هویتی و بیمه ای بیمار&quot;، &quot;جستجوی دارو و خدمات&quot;، &quot;ثبت دارو و خدمات&quot;  و &quot;ارسال نسخه به بیمه&quot; باشد.گام 3: Map the user journeyپس از جمع‌آوری اهداف، سفر کاربر را بازگو کنید. کاربر چه کاری انجام می‌دهد؟ جریان طبیعی روایت را دنبال کرده و مراحل را شناسایی کنید. Sticky note ها را در خط دوم، به ترتیب قرار دهید. سعی کنید عناوین کارت‌ها را در طول جلسه User Story Mapping کوتاه نگه دارید؛ اگر به صورت جمعی ایجاد شوند، همه می‌دانند که این عناوین کوتاه به چه معناست.گام 4: Write user storiesمرحله بعدی جلسه User Story Mapping یافتن راه‌حل‌هایی برای دستیابی به مراحل کاربر است. در این فرآیند، شما &quot;user stories&quot; ایجاد می‌کنید. معمولاً می‌توانید از قالب استاندارد user story استفاده کنید:As a &quot;user persona&quot;, I want &quot;goal&quot;, that &quot;benefit&quot;.سعی کنید تا حد امکان داستان‌های بیشتری برای هر مرحله کاربر جمع‌آوری کنید، اما بر روی یک مرحله تمرکز نکنید در غیر این صورت، جلسه User Story Mapping بسیار طولانی خواهد شد.مثال:به عنوان یک پزشک، می‌خواهم کد ملی بیمار را وارد کنم تا اطلاعات هویتی و بیمه‌ای او را به سرعت بازیابی کنم. به عنوان یک پزشک، می‌خواهم بتوانم نام داروها را جستجو کنم تا سریعاً لیستی از داروهای موجود را مشاهده کنم.به عنوان یک پزشک، می‌خواهم نسخه الکترونیکی را تایید نهایی کنم تا مطمئن شوم تمامی جزئیات به درستی وارد شده است.گام 5: Prioritize your backlogاگر تیم در طول جلسه User Story Mapping موفق بوده باشد، backlog باید پر از ایده‌های عالی باشد user stories دارای سطوح اولویت مختلفی هستند. که باید اولویت بندی کنید.گام 6: Slice outدر پایان جلسه User Story Mapping باید ببینیم چه چیزی را اول توسعه دهیم. بنابراین باید کوچکترین بخش قابل کار از محصول، یعنی Minimum Viable Product (MVP) ، را مشخص کنیم. این مرحله می‌تواند به برنامه‌ریزی انتشار محصول کمک‌های زیادی کند. در اینجا چند مورد از این کمک‌ها را توضیح میدهم:MVP: با استفاده از slicing، میتوان حداقل محصول قابل عرضه (MVP) را به دقت تعریف کرد. این کار به تیم کمک میکند تا فقط ویژگی‌های ضروری را برای نسخه اولیه محصول انتخاب کند و از اضافه‌کاری جلوگیری کند.انعطاف پذیری در برنامه‌ریزی: slicing به تیم اجازه میدهد تا به سرعت به تغییرات نیازهای بازار یا مشتریان واکنش نشان دهد. اگر نیازهای جدیدی مطرح شود، میتوان داستانهای کاربری جدید را به MVP اضافه کرد و داستانهای غیرضروری را حذف کرد.شناسایی و حل مشکلات: با تعریف دقیق داستان‌های کاربری و ترتیب توسعه آنها، تیم می‌تواند مشکلات و شکاف‌های موجود را زودتر شناسایی و حل کند. این کار از بروز مشکلات در مراحل بعدی توسعه جلوگیری میکند.مدیریت بهتر منابع: slicing به تیم کمک میکند تا منابع خود را بهینه‌تر مدیریت کند. با تمرکز بر روی داستان‌های کاربری ضروری، تیم می‌تواند زمان و منابع خود را به بهترین شکل ممکن استفاده کند.پیش‌بینی و پیگیری پیشرفت: با استفاده از slicing، تیم میتواند پیشرفت پروژه را به صورت دقیق‌تری پیگیری کند و پیش‌بینی کند که آیا محصول در زمان و بودجه تعیین شده تحویل داده میشود یا خیراین مرحله به تیم‌های توسعه محصول کمک میکند تا با کمترین تلاش، محصولی کارا و قابل عرضه را به بازار ارائه دهند و در عین حال انعطاف‌پذیری لازم برای پاسخ به تغییرات را داشته باشند.</description>
                <category>محدثه انتظاری</category>
                <author>محدثه انتظاری</author>
                <pubDate>Fri, 19 Jul 2024 21:12:57 +0330</pubDate>
            </item>
            </channel>
</rss>