<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های سجاد داداشی</title>
        <link>https://virgool.io/feed/@seed</link>
        <description>مهندس برقی که برنامه نویسی میکنه.</description>
        <language>fa</language>
        <pubDate>2026-06-07 08:39:54</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/64379/avatar/avatar.png?height=120&amp;width=120</url>
            <title>سجاد داداشی</title>
            <link>https://virgool.io/@seed</link>
        </image>

                    <item>
                <title>الگو طراحی یا Design Pattern</title>
                <link>https://virgool.io/DesignersCommunity/%D8%A7%D9%84%DA%AF%D9%88-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%DB%8C%D8%A7-design-pattern-kiajfiias1x6</link>
                <description>در دنیای برنامه نویسی Design Pattern ها اختراع شدن برای پاسخ گویی به یک سری مسایل و مشکلاتی که در برنامه نویسی رایج هستند. مانند دنیای روزانه ما که برای تولید ماشین (در واقع تولید ماشین یک مساله هست که باید حل بشه ) دیگه کسی چرخ ( در واقع چرخ یک مساله رایج هست که برای تولید هر ماشینی باید چرخ را نیز تولید کرد ) رو از اول اختراع نمیکنه. در برنامه نویسی هم بعضی مسایل پیش می ایند که مسایل رایجی هستند  که قبلا به آن مسایل فکر شده و یک سری الگو های طراحی (Design Pattern)  برای آن مسایل اختراع شده است.متن پایین رو از ویکی پدیا گذاشتم:در مهندسی نرم‌افزار، الگوی طراحی (به انگلیسی: Design Pattern) یک راه‌حل عمومی قابل تکرار برای مشکلات متداول در زمینه طراحی نرم‌افزار است. الگوی طراحی، یک طراحی تمام‌شده نیست که به صورت مستقیم بتواند تبدیل به کد منبع یا ماشین شود؛ بلکه، یک توضیح یا قالب برای حل یک مسئله در شرایط مختلف است. الگوها در واقع بهترین روش ممکن هستند که یک برنامه‌نویس می‌تواند در هنگام طراحی یک برنامه برای حل  مشکلاتش از آن‌ها استفاده کند. الگوهای طراحی شیءگرا نوعاً نشان‌دهندۀ  روابط و تعامل‌ها بین کلاس‌ها و شیء‌ها هستند، بدون این‌که کلاس‌ها یا اشیا نهایی برنامه را مشخص کند.چیز  مهمی که برای یادگیری Design Pattern ها بنظرم اهمیت داره اینه که یادبگیریم هر الگو طراحی (Design Pattern) برای حل کردن چه مساله ای به  وجود اومده. الگوهای طراحی یک نوع نگاه کردن به حل مسایل هست و مهمه اینه در برنامه های خودمون بتونیم تشخیص بدیم که کجا از چه الگو طراحی استفاده  کنیم. برای این موضوع ابتدا باید بدونید که یک الگو طراحی برای چه هدفی به  وجود امده است یعنی چه مساله ای در دنیای برنامه نویسی رو قراره حل کنه و  بعد به چه شکلی این مساله رو حل میکنه.کلا برای الگوهای طراحی مهمه که بعد از یادگیری اون حتما داخل مسایل روزمره برنامه نویسی ازشون استفاده کنیم. اولش ممکنه بنظر برسه که داره کار رو یکم پیچیده تر میکنه ولی اگر قرار باشه برنامون یکم گسترش پیدا کنه و بزرگ بشه بهترین راه برای تمیز و قابل گسترش نگه داشتن برنامه استفاده از الگوهای طراحی هستش. پس بنظرم هر الگو طراحی که یاد گرفتید سعی کنید از اون روز به بعد داخل هر برنامه ای که مینویسد اگه دیدید میشه از الگو طراحی استفاده کرد حتما اونو به کار بگیرید.( صرفا خوندن و دونستن یک سری الگو طراحی هیچ کمکی بهتون نمیکنه.)الگوهای طراحی به زبان برنامه نویسی خاصی وابسته نیستند و با هر زبانی که برنامه نویسی میکنید میتونید از الگوهای طراحی استفاده کنید.(من خودم تو زبان های cpp و java و c# دیدم که از الگوهای طراحی میشه استفاده کرد.)من خودم اولش الگوهای طراحی رو یاد گرفتم بعدا دیدم که الگوهای طراحی دسته بندی خاصی دارند (بنظرم دسته بندی در وهله اول یادگیریش زیاد مهم نیست) که در زیر براتون بعضی هاشو معرفی میکنم(زیاد کامل نیست و صرفا به اشاره کردن اسمشون اکتفا کردم) ولی بنظرم از همه مهمتر اینه که یاد بگیرید توی برنامتون کجا و از چه الگو طراحی میتونید استفاده کنید.الگوهای طراحی سازنده (Creational Design Patterns)SingletoneBuilderFactory Methodالگوهای طراحی ساختاری(Structural Design Patterns)الگوهای طراحی رفتاری (Behavioral Design Patterns)</description>
                <category>سجاد داداشی</category>
                <author>سجاد داداشی</author>
                <pubDate>Wed, 04 Sep 2019 23:05:08 +0430</pubDate>
            </item>
                    <item>
                <title>Repository Pattern</title>
                <link>https://virgool.io/@seed/repository-pattern-axcaocaulvrb</link>
                <description>اگه براتون سواله که چرا باید از الگوهای طراحی استفاده کنیم بهتون پیشنهاد میکنم ابتدا ی پستی که در مورد الگوهای طراحی توضیح دادم رو بخونید بعدش این پست رو مطالعه کنید.با توجه به صحبت های پست الگوهای طراحی ابتدا باید ببینیم که چه مشکل و مساله ای در دنیای برنامه نویسی به وجود اومده که الگو طراحی Repository برای حل اون مساله اختراع شده.فرض کنید ما یک برنامه سمت سرور داریم که قرار است روی یک سری دیتا پردازشی انجام بدهد و خروجی را در یک فایل ذخیره کنه. دیتای مورد نیاز برنامه میتونه داخل همون سروری باشه که برنامه ما داخلش اجرا میشه یا میتونه به صورت محلی داخل خود برنامه ذخیره شده باشه یا میتونه داخل یک فایل نوشته شده باشه و برنامه ما باید دیتای خودش رو از اون فایل بره بخونه یا میتونه دیتا رو از یک سرور خارجی دیگه به وسیله اینترنت بگیره. همون جور که میبینیم اماده کردن دیتا برای برنامه ما میتونه از روش های مختلفی صورت بگیره در صورتی که برنامه ما اهمیتی براش نداره که این دیتا از کجا و به چه شکلی به دستش میرسه. در واقع مساله اصلی اینه که برنامه ما دوست داره یک برنامه ی جداگانه ای باشه که دیتا رو به دستش برسونه تا بتونه پردازش لازم رو روی اون دیتا انجام بده و تمرکزی رو این مساله نداشته باشد که دیتا از کجا قراره به دست ما برسه. همچنین برای به دست اوردن دیتا ما باید تحت پروتکل خاصی که اون دیتا ذخیره شده صحبت کنیم. یعنی فرض کنید دیتای ما روی یک فایل با فرمت خاص و به صورتی محلی داخل سرور ذخیره شده. برای استخراج داده ها باید بدونیم که فرمت خاص به چه شکلی هست و درگیر پیچیدگی مربوط به ان فرمت خاص بشیم. حالا ممکنه بعد از یک مدت برنامه ما نیاز داشته باشه یک سری فرمت خاص دیگه ای رو هم بتونه از روی فایل بخونه. یا مثلا فرض کنید برای ارتباط به یک سرور خارجی که بخواهیم دیتا بگیریم از لایبراری های مختلف برای ارتباط به اون سرور استفاده کنیم که مسایل مربوط به خودشون رو دارند. در واقع برای برنامه ما مهم نیست که دیتا به چه شکلی ذخیره شده و قراره به دست ما برسه همانطور که مهم نیست دیتا کجا ذخیره شده باشه. برنامه ما فقط میخاد دیتا بدستش برسه تا پردازش های لازم رو انجام بده.به طور خلاصه برنامه ما نیاز نداره بدونه که دیتا از کجا و به چه شکلی قراره به دستش برسه.یک مثال دیگه میتونه اپلیکیشن های موبایل باشه. فرض کنید در اپلیکیشن موبایل ما می خواهیم یک سری داده رو به کاربر نمایش دهیم ولی ممکنه این داده ها رو از resource های مختلفی ( سمت سرور یا از دیتابیس خود موبایل و یا یک داده ای باشه که قبلا از سرور گرفتیم و اون رو ذخیره داریم (Cache) ) بگیریم همچنین ممکنه برای ارتباط با سرور از لایبراری های مختلفی استفاده کنیم ( مانند Volley یا Retrofit).در اصل برنامه ما از دو قسمت کلی تشکیل شده یکی نحوه گرفتن داده ها و یکی دیگه نحوه نمایش داده ها هست. برای اینکه بتونیم این دو قسمت رو از هم جدا کنیم و سعی کنیم پیاده سازی و پیچیدگی های مربوط به هر قسمت تاثیری روی قسمت دیگه نذاره از الگو طراحی Repository استفاده میکنیم. به طور خلاصه میتونیم بگیم بهتره پیچیدگی های اینکه دیتا قراره از کجا و به چه شکلی به برنامه ما برسه رو از قسمت های دیگه اپلیکیشن جدا کنیم تا بتونیم راحت تر این موضوع رو مدیریت کنیم.حال برای حل کردن مساله ( که همان الگو طراحی Repository می باشد) ما یک کلاس ( یا برنامه) طراحی میکنیم که وظیفه اصلی این کلاس اماده کردن دیتا می باشد. یعنی پیچیدگی های مربوط به فراهم کردن دیتا رو به این کلاس میسپریم و ما صرفا متد های این کلاس رو صدا میزنیم و کار نداریم که داده ی مورد نیاز ما از کجا ( سرور محلی - سرور خارجی - فایل محلی ...) و به چه شکلی ( به وسیله چه لایبراری) به دست ما میرسه.در ادامه سعی میکنم این الگو طراحی را در غالب یک مثال توضیح بدم. میتونید این کد رو از github دانلود کنید.مثالی که زدم خیلی خیلی ساده هست و از چند خط کد بیشتر تشکیل نشده. بیشتر سعی کردم مفهوم رو برسونم به جای اینکه درگیر پیچیدگی های مربوط به پیاده سازی دیتابیس یا ارتباط با سرور بشم.در این قسمت برنامه ما از الگو طراحی Repository استفاده نکرده. برای دیدن کد های این قسمت داخل github بر روی تگ wo-repository کلیک کنید تا کدهای مربوط به این قسمت رو بتونید ببینید.این تگ مخفف without repository هستش.داخل عکس زیر نشون دادم که به چه صورتی باید اینکارو انجام بدید.tag wo-repositoryبرای این مثال ما دوتا Resource برای به دست اوردن دیتا داریم. یکی دیتابیس یکی دیگه هم سرور.این دوتا کلاس در برنامه های اصلی کارشون ارتباط با دیتابیس و یا سرور خارجی برای بازیابی اطلاعات هست ولی چون من نمیخاستم درگیر پیاده سازی های این دو کلاس بشم داده هارو به صورت محلی از داخل متود همون کلاس ها بازیابی کردم.Database Classکلاس دیتابیس اطلاعات یک یوزر را در غالب string برمیگرداند.Server Classکلاس سرور هم اطلاعات یک یوزر را در غالب byte[] برمیگرداند.با این دوتا کلاس و متود صرفا میخواستم نشون بدم که ممکنه دیتا از جاهای (Resources) مختلف و به شکل های مختلف برای برنامه اصلی ما اماده بشه.حالا برای اینکه از این دیتا ها داخل برنامه اصلی (Main.java) استفاده کنیم باید از هرکدام از این کلاس ها یک نمونه بسازیم و به وسیله دو تابعی که دارن داده ها را بازیابی کنیم.Main Classمشکل اصلی برنامه ساده بالا اینه که برنامه اصلی (Main) ما نیاز داره بدونه اطلاعات  هر یوزر از کجا ( یکی از یوزر ها داخل دیتابیس ذخیره شده و یکی دیگه از سرور اطلاعاتش میاد) و به چه شکلی (دیتابیس اطلاعات یوزر رو به شکل string برمیگرداند و سرور به شکل byte[]) بازیابی میشه.حالا میخایم به کمک الگو طراحی Repository این مسایل پیش اومده رو برطرف کنیم.برای این قسمت داخل github بر روی تگ w-repository کلیک کنید. این تگ مخفف with repository هستش.برای حل کردن این مشکل یک کلاس به اسم RepositoryPattern.java درست میکنیم که وظیفه این کلاس مخفی کردن پیچیدگی های مربوط به بازیابی اطلاعات از برنامه اصلی میباشد.RepositoryPattern Classهمونطور که میبینیم این کلاس دوتا متود داره که اطلاعات مربوط به یوزر ۱ و یوزر ۲ را برای ما بازیابی میکند.حال برنامه اصلی ما (Main) فقط کافیه از این دوتا متود کلاس RepositoryPattern استفاده کند بدون اینکه درگیر پیچیدگی های (‌از کجا و به چه شکلی) بازیابی اطلاعات بشود.Main class wiht repository pattern</description>
                <category>سجاد داداشی</category>
                <author>سجاد داداشی</author>
                <pubDate>Mon, 26 Aug 2019 10:58:05 +0430</pubDate>
            </item>
            </channel>
</rss>