نوشته های sorkhemiri | سرخه میری

اندر مزایای منزوی بودن، قسمت دوم

sorkhemiri | سرخه میری — Wed, 26 Jul 2023 09:28:58 +0330

فیل‌های دور از خانه!در قسمت قبلی راجع به درجه‌ی انزوا و انزوای ایده آل صحبت کردیم. حالا میخوایم در مورد مشکلات هم‌زمانی ای که ممکنه با استفاده از این درجه‌های پایین تر انزوا دچار اون‌ها بشیم صحبت کنیم و در نهایت هم متوجه بشیم برای کاری که می‌خوایم انجام بدیم درجه‌ی انزوای مناسب رو چطوری انتخاب کنیم.ناهنجاری‌های سیستم‌های هم‌زماناستاندارد SQL درجه‌های انزوای متعددی پایین تر از درجه‌ی serializability معرفی میکنه. علاوه بر این تعدادی درجه‌ی انزوا هم به صورت معمول در دیتابیس‌های موجود در سیستم های تجاری استفاده میشه که توی استاندارد SQL تعریف نشده (یکی از معروف ترین مثال های این موارد snapshot isolation است که توی استاندارد SQL وجود نداره). اما قبل از بررسی کردن درجه‌های مختلف انزوا بیایید راجع به مشکلات شناخته شده‌ای که ممکنه توی یه سیستم هم‌زمان با درجه‌ی انزوای پایین تر از serializability پیش بیاد صحبت کنیم. بیایید این مشکلات رو با مثال بررسی کنیم.بیایید فرض کنیم وقتی یکی از محصولات فروشگاه آنلاین ما به فروش میرسه این تراکنش‌های اجرا میشه:خواندن موجودی قبلینوشتن موجودی جدید که ۱ واحد کمتر از موجودی خوانده شده توی مرحله‌ی قبلهنوشتن سفارش مربوط به خرید محصول مورد نظر در جدول سفارش‌هااگر این تراکنش‌ها به صورت سریالی اجرا بشن، همیشه مقدار موجودی اولیه قابل محاسبه است. اگر با ۴۲ محصول شروع کنیم، همیشه تعداد موجودی به علاوه‌ی تعداد سفارش‌ها برابر با ۴۲ خواهد بود. اما اگر تراکنش‌ها به صورت هم‌زمان و با درجه‌ی انزوای کم‌تر از serializability اجرا بشن چی؟برای مثال، فرض کنید دو تراکنش به صورت هم‌زمان درحال اجرا هستن و هر دو مقدار موجودی اولیه را مقدار یکسانی (۴۲) می‌خوانند. بعد هر دو تلاش می‌کنند که مقدار موجودی جدید که یکی کمتر از موجودی قبلی است (۴۱) را به عنوان موجودی جدید بنویسند و یک سفارش جدید در جدول سفارش‌ها اضافه کنند. در این صورت وضعیت جدید این خواهد بود که مقدار موجودی ۴۱ است با این حال دو سفارش جدید در جدول سفارش‌ها ثبت شده (با این وضعیت تعداد کل محصولات معادل ۴۳ عدد میشه). ما یه محصول اضافه به وجود آوردیم! خب واضحه که این یه خطاست. این خطا به lost-update anomaly معروفه.یه مثال دیگه، بیایید فرض کنیم باز هم همون دو تراکنش دارند هم زمان اجرا میشن فقط این بار تراکنش دوم وقتی تراکنش اول بین مرحله‌ی ۲ و ۳ است آغاز میشه. در این حالت، تراکنش دوم مقدار موجودی رو پس از کاهش می‌خونه. برای مثال اگه مقدار موجودی قبل از شروع تراکنش اول رو ۴۲ بگیریم تراکنش اول موجودی رو می‌خونه و بعد یک واحد ازش کم میکنه بعد تراکنش دوم موجودی رو می‌خونه و باز یک واحد کمترش میکنه (یعنی ۴۰ تا موجودی داریم الان) در همین حال تراکنش اول در مرحله‌ی ایجاد سفارش لغو میشه (مثلا به علت کمبود موجودی). در این حالت تراکنش اول در فرایند لغو تراکنش وضعیت پایگاه داده رو به حالت قبل از شروع تراکنش خودش برمی‌گردونه (یعنی موجودی ۴۲). پس در حالت نهایی ما ۴۲ تا محصول موجودی داریم و یک عدد سفارش جدید (دومین تراکنش موفقیت آمیزه و سفارش دوم با موفقیت ثبت میشه). تو این حالت باز هم میبینیم که یه محصول اضافه به وجود اومده! این خطا به dirty-write anomaly معروفه (به این علت که به تراکنش دوم اجازه داده میشه که قبل از مشخص شدن وضعیت نهایی سفارش اول مقدار موجودی رو تغییر بده).برای مثال سوم، بیایید فرض کنیم یک تراکنش برای محاسبه‌ی کل محصولات موجود و فروخته شده می‌خواد مقدار موجودی و تعداد کل سفارش‌ها رو بخونه. این تراکنش بین مرحله‌ی ۲ و ۳ از یک تراکنش خرید اجرا میشه در این حالت تراکنشی که قصد داره موجودی کل محصولات و سفارش‌ها رو بخونه با یک حالت غیر قطعی میانی رو به رو میشه که یک واحد از موجودی کم شده اما هنوز سفارشی ثبت نشده. در این حالت اینطور به نظر می‌رسه که یک محصول گم شده (یک خطای دیگه!). این خطا به dirty-write anomaly معروفه، به این علت که به تراکنشی که در حال محاسبه‌ی کل محصولات بوده اجازه داده میشه که یک حالت میانی غیر قطعی از یک تراکنش خرید رو بخونه.برای مثال چهارم، بیایید فرض کنیم یک تراکنش مستقل وجود داره که هر بار موجودی رو می‌خونه و اگر کالا های موجود کمتر از ۱۰ عدد باشن کالا های جدید سفارش میده( با دو شرط زیر):شرط اول: IF (READ(Inventory) = (10 OR 11 OR 12)) (اگر موجودی ۱۰، ۱۱ یا ۱۲ باشه):ارسال با پست معمولیشرط دوم: IF (READ(Inventory) < 10) (اگر موجودی کمتر از ۱۰ باشه):ارسال با پست پیشتازتوجه کنید که این تراکنش دوبار موجودی رو می‌خونه. اگر تراکنش خرید در زمانی که این تراکنش بین مرحله‌ی اول و دوم شرط هست اجرا بشه تراکنش برای هر شرط مقدار موجودی متفاوتی می‌خونه. اگر موجودی قبل از تراکنش خرید ۱۰ باشه این باعث میشه که درخواست ارسال دوبار فرستاده بشه یک بار با پست معمولی، یک بار با پست پیشتاز. این خطا به non-repeatable read anomaly معروفه.برای مثال پنجم، تصور کنید یک تراکنش وجود داره که روی جدول سفارشات اجرا میشه تا بیشینه (maximum) قیمت یک سفارش رو حساب کنه. سپس دوباره اجرا میشه تا میانگین سفارشات رو حساب کنه. فرض کنید بین اجرای این دو مرحله تراکنش یک تراکنش خرید اجرا بشه که قیمت اون انقدر بالا باشه که میانگین محاسبه شده در مرحله‌ی دوم از بیشینه‌ی محاسبه شده در مرحله‌ی اول بالا تر بره. این تراکنش میانگینی رو محاسبه میکنه که از بیشینه بیشتره. یک اتفاق نشدنی و یک خطا که هیچ وقت در یک سیستم serializable رخ نمیده. این خطا با خطای non-repeatable read anomaly متفاوته چون تمام مقادیر خوانده شده در هر دو تراکنش یکسانه و دلیل اتفاق افتادن خطا اضافه شدن یک سفارش جدید در بین دو مرحله تراکنشه این خطا phantom read anomaly نامیده میشه.برای مثال آخر، تصور کنید میخواهیم برنامه‌ای طراحی کنیم که قیمت را بر اساس موجودی تغییر دهد. برای مثال در بسیاری از خطوط هوایی قیمت بلیط با کاهش صندلی موجود در پرواز افزایش می‌یابد. فرض کنید برنامه از یک فرمول برای چک کردن برقراری ارتباط بین موجودی و قیمت استفاده می‌کنه ( برای مثال: 10I + P >= $500 که در آن I موجودی و P قیمت است) و این فرمول را به صورت شرط برای database تعریف میکنه. قبل از هر خرید تراکنش خرید این شرط را چک می‌کنه و اگر این شرط برقرار بود تغییری لازم برای فرایند خرید را اعمال می‌کنه.به طور مشابه، یک تراکنش مستقل که تخفیف‌های مخصوص اعمال می‌کنه هم موجودی و قیمت را چک می‌کند که اگر بعد از اعمال تخفیف همچنان شرط پا برجا باشه تخفیف رو اعمال کنه.حالا فرض کنید این دو تراکنش هم زمان در حال اجرا باشن (هر دو مقدار قدیمی موجودی و قیمت رو بخونن) و به صورت مستقل با در نظر گرفتن شرط قیمت ها رو به‌روز کنن. در این صورت متاسفانه ممکنه مقادیری از قیمت و موجودی تولید بشن که شرط رو نقض می‌کنن. اگر این تراکنش ها پشت سر هم اجرا می‌شدن با اجرا شدن تراکنش اول قیمت و موجودی تغییر می‌کرد و تراکنش دوم بعد از چک کردن شرط و عدم تطابق متوقف می‌شد. اما چون این فرایند ها به صورت مستقل عمل می‌کنن هر دو بعد از خواندن مقادیر قدیمی قیمت و موجودی تصمیم به ادامه‌ی فرایند می‌گیرن. این خطا write skew anomaly نامید میشه.

اندر مزایای منزوی بودن، قسمت اول

sorkhemiri | سرخه میری — Fri, 17 Dec 2021 23:37:20 +0330

نزدیک ترین محتوا به انزوا که پیدا کردم :)در این مقاله می‌خوایم در مورد درجه های مختلف انزوا در دیتابیس ها صحبت کنیم. مزیت هایی که درجه‌های انزوای کمتر برای ما به همراه دارند و مشکلات هم‌زمانی ای که ممکنه با استفاده از این درجه‌های پایین تر انزوا دچار اون‌ها بشیم. در این مقاله ما بر روی حالت‌های انزوای serializable و حالت های انزوای درجه پایین تر و این که این درجه‌های پایین‌‌تر ممکنه نرم افزار ما رو دچار چه مشکلاتی کنن تمرکز می‌کنیم.سال هاست که دیتابیس ها به کاربرهای خودشون این امکان رو دادن که از بین درجه های مختلف انزوا (isolation) مورد مناسب خودشون رو از بین «serializability» که بالاترین حد اونه تا «read committed» یا «read uncommitted» که پایین ترین حد اونه انتخاب کنن. هر درجه از این درجه‌های انزوا امکان داره که نرم‌افزار رو در معرض مشکلات مشخصی در هم‌زمانی (concurrency bugs) قرار بده. اگرچه اکثر کاربرا به درجه‌ی انزوای پیش‌فرض هر دیتابیسی که از آن استفاده می‌کنن اکتفا می‌کنن و به این مساله توجه نمی‌کنن که واقعا چه درجه ای از انزوا مناسب نرم‌افزار اون‌ها است. این راهکار خطرناکه چون خیلی از دیتابیس های محبوب از جمله Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, MySQLو PostgreSQL هیچ‌گونه serializability (حالت ایده آل انزوا در شرایط هم‌زمانی) به صورت پیش‌فرض ارایه نمی‌دهند. همانطور که پایین‌تر توضیح میدیم حالت‌های انزوای کمتر از serializability ممکنه به مشکلات هم‌زمانی و ایجاد تجربه کاربری منفی منجر بشه. این خیلی مهمه که کاربر دیتابیس از درجه‌های انزوایی که دیتابیس برای اون تضمین کرده و مشکلات هم‌زمانی ای که ممکنه با استفاده از هر کدوم از این درجه‌ها ایجاد بشه آگاه باشه.درجه انزوا چیه؟انزوا در دیتابیس به معنی این قابلیت است که دیتابیس شرایط رو فراهم کنه که یک تراکنش(transaction) به شکلی اجرا بشه که انگار هیچ تراکنش دیگه‌ای به صورت هم‌زمان در حال اجرا نیست(اگرچه ممکنه در واقع تعداد زیادی تراکنش هم‌زمان درحال اجرا وجود داشته باشه). هدف اصلی جلوگیری از نوشته شدن داده های موقت، ناخواسته و غلط توسط تراکنش‌های هم‌زمان است.خوشبختانه چیزی به اسم انزوای ایده‌آل وجود داره (پایین‌تر توضیح میدیم). متاسفانه اما، ایده‌آل بودن به قیمت کاهش بازدهی تمام میشه (این کاهش بازدهی ممکنه به صورت افزایش زمان تراکنش -- زیاد شدن زمان لازم برای کامل شدن یک تراکنش -- یا کاهش بازدهی -- تعداد تراکنش در واحد زمان -- ظاهر بشه). سادگی یا پیچیده بودن دستیابی به انزوای ایده‌آل در یک سیستم بستگی به معماری اون سیستم داره. در سیستم هایی که معماری ضعیفی دارن دستیابی به انزوای ایده‌آل گرون تموم میشه و کاربرها مجبور میشن به یک سری حداقل‌ها اکتفا کنن. اگرچه حتی در سیستم هایی که از معماری خوبی برخوردار هستن اکتفا به یک سری حداقل‌ها افزایش قابل عملکرد سیستم رو به همراه داره. بنابراین درجه‌های انزوا برای این به وجود اومدن که یک توسعه دهنده‌ها توانایی این رو داشته باشن که یک موازنه بین ضمانت حدودی انزوای تراکنش‌ها و عملکرد قابل‌قبول سیستم به‌وجود بیارن.انزوای ایده‌آلبیایید بحثمون رو با این ایده شروع کنیم که اصلا انزوای ایده‌آل یعنی چی؟ ما بالاتر انزوا رو اینطور تعریف کردیم که دیتابیس شرایط رو فراهم کنه که یک تراکنش(transaction) به شکلی اجرا بشه که انگار هیچ تراکنش دیگه‌ای به صورت هم‌زمان در حال اجرا نیست(اگرچه ممکنه در واقع تعداد زیادی تراکنش هم‌زمان درحال اجرا وجود داشته باشه). معنی ایده‌آل با توجه به این تعریف چیه؟ در اولین نگاه به دست آوردن حالت ایده‌آل غیرممکن به نظر میاد. وقتی دو تراکنش به صورت هم زمان روی یک منبع به خصوص مینویسن و میخونن حتما روی هم تاثیر می‌گذارن. اگه این دو همدیگر رو نادیده بگیرن و روی همون حالت اولیه تغییر بدن هر کدوم که آخر انجام بشه قبلی رو دچار مشکل میکنه، انگار که قبلی هیچ وقت اجرا نشده.دیتابیس یکی از اولین سیستم های هم‌زمان مقیاس پذیر بود، و به عنوان یک الگوی قبلی برای سیستم های هم‌زمانی که بعدها توسعه داده شدن مورد استفاده قرار گرفت. جامعه توسعه سیستم دیتابیس ها ده‌ها سال قبل یک مکانیزم بسیار قدرتمند برای رویارویی با پیچیدگی های پیاده سازی برنامه‌های هم‌زمان توسعه داد.ایده این بود: انسان ها در تحلیل هم زمانی به شکل بنیادی مشکل دارن. این یک برنامه‌ی بدون باگ غیر هم‌زمان بنویسیم به اندازه کافی سخت هست. اما زمانی که شما هم زمانی رو به این معادله اضافه می‌کنید، تقربیا بی‌نهایت حالت، شرایط رقابت ممکنه ایجاد بشه(اگر یکی از thread‌ها به خط ۱۷ برنامه برسه قبل از این که دیگری به خط ۵ برسه، اما بعد از این که به خط ۳ رسیده، ممکنه مشکلی پیش بیاد که در هیچ حالت دیگه ای از اجرای برنامه امکان به وجود اومدنش وجود نداشته باشه). این تقربیا غیر ممکنه که تمام حالت هایی که قسمت های مختلف اجرای یک برنامه ممکنه با هم تلاقی کنن رو در نظر بگیریم، و این که حالت های مختلف این تلاقی ممکنه منجر به چه نتیجه ای بشه. در عوض دیتابیس ها یک انتزاع زیبا رو برای توسعه دهنده‌ی نرم‌افزار فراهم میکنن. تراکنش ها! تراکنش ها ممکنه شامل هر تکه کدی باشن اما نکته مهم اینه که اون ها single-thread هستن. توسعه دهنده‌نرم افزار فقط باید به کد داخل تراکنش دقت کنه (در واقع فقط لازمه چک کنه که وقتی این کد اجرا میشه و هیچ پردازش هم‌زمانی در سیستم وجود نداره کد درست اجرا میشه). دیتابیس در هر وضعیت شروعی باشه اجرا شدن کد نباید نتیجه‌ای خارج از منطق تعریف شده‌ی برنامه داشته باشه. اگرچه اطمینان از درست بودن کد کار ساده ای نیست، اما اطمینان پیاده کردن از درست بودن اون درحالی که به تنهایی داره اجرا میشه خیلی راحت تر از وقتیه که یک پردازش دیگه داره سعی میکنه منابع مشترک رو دستکاری کنه.اگر برنامه نویس بتونه اطمینان حاصل کنه که یک تکه کد در حالتی که به تنهایی در حال اجراست درست کار میکنه، انزاوی ایده‌آل تضمین میکنه که وقتی کد به صورت هم‌زمان با پردازش های دیگه که ممکنه منابع مشترک رو تغییر بدن در حال اجراست درست کار میکنه. به بیان دیگه، دیتابیس به توسعه دهنده این امکان رو میده که بدون نگرانی در مورد پیچیدگی‌های هم زمانی احتمالی کد رو توسعه بده، با این وجود کد بدون این که باگ جدیدی ایجاد بشه یا از منطق برنامه خارج بشه به صورت هم‌زمان اجرا بشه.پیاده سازی این مرحله از ایدآل بودن به نظر خیلی سخت میاد، اما در واقع سرراست و دست یافتنیه. ما از قبل مطمین شدیم که کد با در نظر گرفتن هر حالت ابتدایی‌ای که دیتابیس در اون قرار داره و با این فرض که کد به تنهایی اجرا میشه درست کار میکنه. بنابراین اگر کد تراکنش ها به صورت سریالی اجرا بشه (پشت سر هم) نتیجه‌ی نهایی بازهم درسته. بنابراین، برای این که به انزوای ایده‌آل برسیم تمام کاری که باید بکنیم اینه که مطمین بشیم تراکنش ها درست اجرا میشن، حالت نهایی معادل حالتی خواهد بود که اگر تراکنش ها به صورت هم‌زمان اجرا می‌شدن به وجود می‌اومد. راه های زیادی برای انجام این کار وجود داره (مثل قفل کردن منابع مشترک، اعتبارسنجی و multi-versioning) که مورد بحث این مطلب نیست. مساله اصلی برای ما اینه که «انزوای ایده‌آل» رو به صورت اجرای موازی تراکنش ها در سیستم تعریف می‌کنیم، اما به شکلی که انگار دارن پشت سر هم اجرا میشن. در استاندارد SQL، این انزوای ایده‌آل serializability نامیده میشه.این داستان ادامه دارد ...

هر کسی را بهر کاری ساختند!

sorkhemiri | سرخه میری — Mon, 27 Sep 2021 23:31:14 +0330

توضیح کوتاهی در‌مورد single responsibility principleاگر با دنیای مهندسی نرم‌افزار آشنا هستید احتمالا اسم اصول SOLID به گوش‌تون آشناست. SOLID مخفف پنج قانون پایه‌ی مهندسی نرم‌افزار در پارادایم Object-Oriented است. که رعایت اونها کد شما رو توسعه پذیرتر و خوانا تر می‌کنه. در این مطلب توضیح کوتاهی در مورد S یا همون Single Responsibility Principle میدهم و امیدوارم مورد توجه‌تون قرار بگیره.چرا باید از هر کسی تو حوزه تخصصی خودش استفاده کنیم؟وقتی کسی رو برای یک حوزه تخصصی مشخص استخدام می‌کنیم و برای کار دیگه ای از او استفاده می‌کنیم دو اتفاق مهم می افته. اول این که اون فرد به احتمال زیاد دیگه نمی‌تونه اون کار تخصصی خودش رو به خوبی انجام بده. چون مشغول کار دیگه ای شده که در اون کار تخصص نداره و مجبوره زمان و هزینه خرج کنه تا اون کار رو یاد بگیره و انجام بده. دوم این که چون توی کار غیر تخصصی هم دانش کافی نداره احتمالا اون کار رو هم نمیتونه به خوبی انجام بده. حالا ما اینجا دو تا کار داریم که هر دو دارن به شیوه غلطی انجام میشن به جای این که یک کار به شیوه‌ی درستی انجام بشه.کلاس ها متخصص می‌شوند!نکته جالب اینجاست که چیزی که بالا گفتم محدود به آدم ها نمیشه و کلاس ها هم متخصص میشن. وقتی ما کلاسی رو برای انجام یک کار مشخص و به خصوص می‌نویسیم اون کار تبدیل میشه به تخصص اون کلاس. حالا اگر بعد از گذشتن یه مدت زمان بخوایم کدی بنویسیم که کاری متفاوت ولی تا حدودی شبیه به کار این کلاس رو انجام میده دو تا انتخاب داریم. اول این که بزاریم این کلاس که از قبل وجود داشته به کار تخصصی خودش ادامه بده و یک کلاس دیگه برای کار جدید ایجاد کنیم. دوم این که کلاسی که از قبل وجود داشته رو طوری تغییر بدیم که هر دو کار رو با هم انجام بده. اگه روش دوم رو انتخاب کنیم احتمال خراب شدن کار تخصصی کلاس ما وجود داره و حتی شاید کار جدید رو هم به خوبی انجام نده. پس بهتره برای کار های جدید کلاس های جدید بسازیم.کلاس ها رو با سواد کنیم!در زمان نوشتن یک کلاس حتما دقت داشته باشید که کلاس شما یک کار بیشتر انجام نده. یک مسولیت بیشتر نداشته باشه و توی یک کار خاص متخصص باشه. این باعث میشه اون کلاس این کار خاص رو به بهترین شکل انجام بده. چون یک کار، یک مسولیت و یک هدف بیشتر نداشته باشه.یک مثال کوتاهما در حال ساختن یک فروشگاه اینترنتی لوازم خانگی هستیم. یکی از نیاز هایی که وجود داره اینه که کلاس یا متدی بوجود بیاد که قیمت تمام شده‌ی محصول بعد از اعمال تخفیف و کوپن رو به خریدار نمایش بده. ما یک کلاس می‌سازیم که هدفش برگردوندن قیمت نهایی محصول به خریداره. بعد از یک مدت و در مسیر توسعه یک داشبورد برای فروشنده طراحی میکنیم و میخوایم قیمت کالا به اون هم نمایش داده بشه. برای این که این نیاز رو برطرف کنیم از همون کلاسی که قیمت رو به خریدار نمایش میده استفاده می‌کنیم. بعد از مدتی فروشنده ها شاکی میشن! اونا نمی‌خوان قیمت تمام شده محصول بعد از تخفیف و اعمال کوپن رو ببینن. قیمت اصلی کالا براشون مهمه. حالا چیکار باید بکنیم. برای این که نیاز فروشنده ها برطرف بشه باید کلاس رو تغییر بدیم و اگر کلاس رو تغییر بدیم دیگه قیمت تمام شده به درستی به خریدار ها نمایش داده نمیشه. با این که به ظاهر این دوتا کار شبیه هم بودن ولی چون مسولیت های متفاوتی داشتن و در دو حوزه متفاوت تعریف شده بودن باید دو کلاس تخصصی برای اونها تعریف می‌شد.خوشحال می‌شم نظرتون رو راجع به این مطلب و مطالب گذشته بدونم و نقص های موجود در متنم رو با نظر شما اصلاح کنم.

راهنمای تنبل بودن در مهندسی نرم‌ افزار!

sorkhemiri | سرخه میری — Wed, 22 Sep 2021 09:51:25 +0330

توضیح کوتاهی در‌مورد interface segregation principle و این که چه کمی به ما میکنه؟درخت ها نمونه ای از ساختار درختی!اگر با دنیای مهندسی نرم‌افزار آشنا هستید احتمالا اسم اصول SOLID به گوش‌تون آشناست. SOLID مخفف پنج قانون پایه‌ی مهندسی نرم‌افزار در پارادایم Object-Oriented است. که رعایت اونها کد شما رو توسعه پذیرتر و خوانا تر می‌کنه. در این مطلب توضیح کوتاهی در مورد I یا همون Interface Segregation Principle میدهم و امیدوارم مورد توجه‌تون قرار بگیره.تنبل بودن بهتره!در راستای تنبل بودن :)دنیای نرم افزار همیشه در حال پیشرفت و توسعه است. پروژه ای که شما روش کار میکنید هم همین طور پس لطفا اشتباه برداشت. تنبل بودن یا Lazy بودن در مهندسی نرم افزار یعنی تا چیزی رو لازم نداریم بیانش نکنیم. اگر چیزی رو هنوز لازم نداری صداش نزن. پیاده سازیش نکن. حالا چرا؟دلیل خوب بودن این تنبلی اینه که چون پروژه‌ی شما و تکنولوژی هر دو در حال پیشرفت هستن و تو نمیدونی در آینده قراره چی پیش بیاد و چه ویژگی جدیدی به پروژه اضافه بشه هر چی بیشتر کلی گویی کنی و کمتر حرف بزنی. هر چقدر کمتر پیاده سازی کنی برای آینده ی مبهم و نامعلوم بهتره.چطوری تو توسعه تنبل باشیم؟تنبلی در جنگل توسعه نرم افزار!بهترین راه برای تنبل بودن در مهندسی نرم‌افزار استفاده از Interface هاست. Interface ها به ما اجازه میدن کلاسی رو بسازیم براش متد تعریف بکنیم و همه جا معرفیش کنیم بدون این که پیاده سازیش کنیم. این عالیه! توسعه بدون توسعه. بیان کلی اون چیزی که توی ذهن‌مونه بدون این که مجبور به پیاده سازیش باشیم این اجازه رو بهمون میده که تا زمانی که مجبور نشدیم پیاده سازیش نکنیم.حالا interface segregation principle چی میگه؟این اصل خیلی ساده بیان میکنه هر وقت خواستی کلاسی تعریف کنی اول interface تعریف کن. و بعد که خواستی بیشتر توضیح بدی از اون interface اولیه ارث ببر و یک interface دیگه تعریف کن با جزییات بیشتر! اونقدر این کار رو انجام بده تا بالاخره مجبور به پیاده سازی اون کلاس بشی. کلاس های بعدی که تعریف میکنی یا زیر مجوعه یکی از این interface ها هستن یا باید براشون یک interface دیگه تعریف کنی. اگه به این شکل دقت کنی یک ساختار درختی تو پروژه به وجود میاره که خیلی در توسعه نرم افزار در آینده بهت کمک میکنه.خوشحال می‌شم نظرتون رو راجع به این مطلب و مطالب گذشته بدونم و نقص های موجود در متنم رو با نظر شما اصلاح کنم.

دنیا وارونه نیست عینکتو عوض کن!

sorkhemiri | سرخه میری — Sun, 12 Sep 2021 23:02:12 +0430

نحوه ی نگاه ما تاثیر دارهمیخواستم مطلبی راجع به پارادایم برنامه نویسی شی گرا بنویسم. فکر کردم بدون توضیح کلمه پارادایم نمیشه توضیح کاملی ارایه کرد. برای همین این مطلب رو به توضیح این که پارادایم اساسا چیه و چطوری کار می‌کنه اختصاص دادم. امیدوارم بتونه چیزی به شما که اونو می‌خونید و به من که از نظراتتون استفاده می‌کنم اضافه کنه. قبل از شروع این مطلب لازم می‌دونم از محمد حسن بشری همکار و استادم تشکر کنم که بدون اون این مطلب هم احتمالا وجود نداشت. در ضمن فکر میکنم مطالعه‌ی دوباره‌ی مطالبی که راجع به انتزاع و مدل سازی نوشتم شاید به فهم این مطلب کمک کنه.پارادایم چیه؟آیا دیدن الگوی خاصی داره؟اکثر جاهایی که نگاه کردم Object-Oriented Paradigm (همون OOP) رو الگوی برنامه نویسی شی گرا ترجمه کردن. کلمه‌ی الگو شاید بهترین برگردان فارسی کلمه Paradigm نباشه. نزدیک ترین معنایی که میشه برای کلمه پارادایم پیشنهاد کرد چهارچوب فکری یا جهان بینیه. یه توضیح کوتاه، ما آدم ها برای دیدن غیر از چشم به چیز دیگه ای هم نیاز داریم. چشم ما نگاه میکنه اما این عقل ماست که میبینه. برای همینه که با وجود این که همه ما آدم ها چشم های شبیه به هم داریم یک چیز رو به شکل های متفاوتی میبینیم. دید یک فیزیک دان به یک سیب در حال سقوط با دید یک نقاش یا یک سیاست مدار متفاوته. در واقع آدم های مختلف ویژگی های متفاوتی رو از یک پدیده‌ی بخصوص انتزاع میکنن. اما ریشه این مساله کجاست؟ما چطوری فکر می‌کنیم؟فکر کردن یک علامت سوال بزرگ!فرایند فکر کردن و تصمیم گیری یکی از راز های بزرگ جهانه که هنوز کسی نتونسته درست متوجه بشه دقیقا چطور کار میکنه. اما چیزی که براساس تجربه ثابت شده اینه که با وجود این که هر آدمی طرز تفکر خاص خودش رو داره. اهل یک تخصص یا یک چهارچوب فکری(کسانی که از یک زبان مشترک برای مدل سازی استفاده میکنن) معمولا طرز تفکر و انتزاعشون از پدیده های مختلف تا حدودی مشابه میشه. شاید بشه این طور تعبیر کرد که به مرور و با استفاده مداوم از یک مدل خاص برای انتزاع و مدل سازی ذهن ما یاد میگیره که با اون الگوی خاص فکر بکنه. یا به بیان دیگه ذهن شما یاد میگیره که به وسیله ی اون پارادایم خاص به مساله نگاه کنه و حلش کنه.آیا ما می‌تونیم با چند پارادایم فکر کنیم؟فکر کردن با چند زبان!این سوال مثل اینه که بپرسیم آیا می‌شه به چند زبان صحبت کرد؟ بله می‌شه اما یادگیری زبان های دیگه سختی خاص خودش رو داره اما همه می‌دونیم یادگیری زبان سوم همیشه راحت تر از یادگیری زبان دومه. در پارادایم ها هم دقیقا همین اتفاق میفته همیشه یادگیری پارادایم دوم برای تفکر سخت تر از یادگیری سومیه.فکر کردن با چند پارادایم به چه دردی میخوره؟جاهایی رو ببین که کسی ندیده!همه میدونیم که خلاقیت اکثر اوقات کلید حل کردن مشکلاته. خلاقیت یعنی چی؟ از زاویه ای نگاه کن که کسی نگاه نکرده. چیزی رو ببین که کسی ندیده! گفتیم که افرادی که با یک پارادایم خاص فکر میکنن معمولا نحوه‌ی انتزاع، تفکر و مدل سازی شون مشابه میشه. حالا اگر بخوایم توی یک موضوع مربوط به یک حوزه تخصصی خاص خلاقیت به خرج بدیم و مساله ای رو حل کنیم یا چیزی رو ببینیم که کسی ندیده احتمالا تغییر پارادایم تفکر یکی از بهترین راه‌ها است. شاید کلید حل یک مشکل تو حوزه مکانیک پارادایم تفکر یک هنرمند باشه. شاید یک معادله ریاضی که سال‌ها حل نشده به دست یک فیزیک‌دان حل بشه. کی میدونه راه‌حل مساله‌ی ما کجا پنهان شده؟خوشحال می‌شم نظرتون رو راجع به این مطلب و مطالب گذشته بدونم و نقص های موجود در متنم رو با نظر شما اصلاح کنم.

چرا باید کد تمیز بنویسیم؟

sorkhemiri | سرخه میری — Sun, 12 Sep 2021 01:08:13 +0430

کدتو تمیز کن!واقعیت اینه که خیلی مواقع میشه کد هایی رو مثال زد که طبق هیچ قاعده ای تمیز نیستن ولی خیلی عالی کار میکنن و از لحاظ کارایی یا همون performance هیچ مشکلی ندارن. پس چرا همش میشنویم که باید کد تمیز نوشت. نوشتن کد تمیز به چه دردی میخوره و اصلا کد مون چقدر باید تمیز باشه؟ اینا سوال هاییه که سعی میکنیم در ادامه بهشون جواب بدیم.برنامه نویسی گروهیچرا کد تمیز ؟اگه برای کد تمیز نوشتن دنبال بهانه ای از جنس performance میگردید احتمالا نمیتونید بهانه ای پیدا کنید که خودتون یا دیگران رو متقاعد کنه که کد تمیز نوشتن لازمه. اتفاقا یک جایی مطلبی میخوندم که نوشته بود برنامه نویس ها اون اوایل کد هاشون رو طوری مینوشتن که اونقدر پیچیده و کثیف باشه که هیچ کس غیر از خودشون قادر نباشه اونها رو بخونه در حالی که از لحاظ کارکرد هیچ مشکلی نداشتن. اما با گسترش بازار IT و تخصصی شدن حوزه های مختلف توسعه نرم افزار برنامه نویس ها متوجه شدن که نمیتونن به تنهایی از پس توسعه پروژه ها بربیان و این نیاز وجود داره که به صورت گروهی کار کنن. اینجا بود که برنامه نویس ها مجبور شدن کد های همدیگر رو بخونن و روی کد هایی که یک نفر دیگه نوشته تغییر انجام بدن. اینجا بود که این نیاز احساس شد که کد باید تمیز باشه. دلیلش هم این بود که سطح تخصص و توانایی کد خوانی و فهم کد افراد مختلف متفاوته و اگر قراره همه با هم کدی رو بخونیم و همه روش تغییر انجام بدیم باید سعی کنیم کد رو طوری بنویسیم که تا جایی که ممکنه برای همه قابل فهم باشه. در واقع کد تمیز روی کارکرد نرم افزار تاثیر نمیگذاره بلکه روی قابلیت دیگه ای که maintainability یا قابلیت نگهداری نرم افزار است تاثیر میگذاره. maintainability وقتی بالا هست که کد اون قدر ساده و تمیز نوشته شده باشه که تعداد زیادی از برنامه نویس ها بتونن بیان کد رو بخونن و بدون مشکل بفهمن و تغییر بدن و وقتی در کمترین حالت خودش هست که فقط کسی که کد رو نوشته بتونه بفهمه چی نوشته و فقط خودش هم بتونه تغییرش بده.برنامه نویس تنها :)چقدر تمیز کد بنویسیم؟واقعیت اینه که توی استارتاپ ها و کسب و کار های اینترنتی نو پا اسم clean code رو آوردن هم نوعی آرمان گرایی محسوب میشه. چون توی این کسب و کار ها بخش زیادی از تمرکز کل تیم خرج توسعه بیزینس و گرفتن بازار هدف میشه و سرعت توسعه نرم افزار در اولویته (یکی از دلایل اصلی محبوبیت زبان های مفسری مثل پایتون و جاوا اسکریپت هم همین سرعت و سادگی توسعه با اون هاست و کسی ادعا نمیکنه چون مثلا پایتون مزیت performance داره من اون رو انتخاب کردم). پس چیکار کنیم ؟ تمیز کد زدن رو بیخیال شیم؟ نه. ما وظیفه مونه تا جایی که ممکنه و به کسب و کار آسیب جدی نمیرسه قواعد کد نویسی تمیز رو رعایت کنیم. البته باید حواسمون به بدهی فنی ای که اینجا ایجاد میشه هم باشه. چون چیز هایی که بلد نبودیم یا یادمون رفته رعایت کنیم یا بخاطر سرعت توسعه بیخیالشون شدیم از بین نمیرن بلکه تبدیل میشن به بدهی ما به نرم افزارمون.در مورد این که بدهی فنی چیه میتونید اینجا و اینجا بخونید.خوشحال میشم نظرتون رو راجع به این مطلب و مطالب آینده بدونم و نقص های موجود در متنم رو با نظر شما اصلاح کنم.

مدل سازی و اشتراک تجربیات

sorkhemiri | سرخه میری — Sat, 11 Sep 2021 00:26:09 +0430

نوعی مدل سازی هنری این بار میخوایم در مورد مدل ها و فرایند مدل سازی صحبت بکنیم. برای فهم بهتر این موضوع شاید بهتر باشه به مطلب قبل راجع به انتزاع یا Abstraction سری بزنید.اصلا مدل چیهبیایید از اینجا شروع کنیم که اصلا مدل چیه و چرا به وجود اومده. متاسفانه ما آدم ها همون طور که در دریافت کامل مفاهیم از اشیا عاجزیم از انتقال کامل اون چیزی که بلدیم و یا تجربه کردیم با تمام جزییات و ویژگی های اون هم عاجزیم. تا حالا شده حسی داشته باشید که نتونید با جمله ها و حتی اشاره و حرکت دست یا هر چیز دیگه ای انتقالش بدید؟ یا چیزی که یاد گرفتید و بلد هستید رو نتونید به کسی انتقال بدید؟ نگران نباشید شما تنها نیستید. ما آدم ها از ابتدای تاریخ با این مشکل دسته و پنجه نرم میکنیم. یکی از راه هایی که پیشینیان ما برای این مشکل پیدا کردن مدل سازیه.مجسمه ها نمونه ای از مدل های هنریمدل ها برای چه کاری استفاده میشن؟مدل ها استفاده های متعددی دارن. از مدل ها میشه برای انتقال احساسات استفاده کرد. نقاشی ها، مجسمه ها و بعضی آثار هنری از این جنس هستن. از مدل ها میشه برای انتقال دانش استفاده کرد. نقشه ها و نقاشی های غار ها از نمونه های اولیه ی مدل ها هستن. به طور کلی میشه گفت انسان برای انتقال تجربیات خودش از مدل ها استفاده میکنه.نقاشی سبک اکسپرسیونیسم نمونه ای از مدل ساده انتقال تجربیاتآیا میشه با نگاه کردن به یک مدل اون رو فهمید؟میشه گفت هم آره هم نه. مدل ها از لحاظ انتقال اطلاعات به دو دسته ی ساده و پیچیده تقسیم میشن. در مدل های ساده خالق مدل سعی داره بدون واسطه و دانش قبلی احساسات و تجربیات خودش رو به بیننده منتقل کنه. نقاشی های سبک اکسپرسیونیسم از این جنس هستن. در مدل های پیچیده خالق مدل از یک سری نماد ها و سمبل ها برای انتقال اطلاعات مدل خودش استفاده میکنه و کسی که از اون نماد ها و سمبل ها اطلاع درستی نداشته باشه نمیتونه اون مدل رو به درستی درک کنه و اطلاعات درونش رو متوجه بشه. برای مثال در هنر دایره نماد آسمان و مربع نماد زمینه برای همین محراب های مساجد رو به شکل مربعی که با دایره پیوند خورده میسازن. نماد پیوند میان زمین و آسمان. برای فهمیدن مدل های پیچیده نیازه که زبان مربوط به اون مدل ها رو بلد باشید. همین مساله باعث شد به مرور متخصصین هر حوزه برای خلق و به اشتراک گذاری مدل هاشون یک زبان مشترک به وجود بیارن و همه از اون زبان برای انتقال تجربیات حوزه خودشون استفاده کنن.نمونه یک مدل تخصصی حوزه مهندسی برقبه عنوان یک مهندس نرم افزار مدل ها کجا به درد من میخورن؟اکثر نرم افزار هایی که مینویسیم یا توسعه میدیم مربوط به حوزه هاییه که ما تخصصی توی اونها نداریم. برای مثال نرم افزار های حساب داری ای که توسط مهندس های نرم افزار توسعه داده میشن یا نرم افزار هایی که برای ویرایش تصویر یا ترسیم مدار های الکتریکی توسعه داده میشن. خیلی پیش میاد که ما مجبور میشیم نرم افزار های تخصصی ای تو حوزه غیر تخصصی خودمون توسعه بدیم. مثلا فرض کنید من بخوام یک نرم افزار حساب داری توسعه بدم. آیا بدون اطلاع از مفاهیم تخصصی حوزه حسابداری میتونم یه نرم افزار تخصصی حسابداری توسعه بدم؟ معلومه که نه. آیا زمان دارم برای توسعه نرم افزار تخصصی حسابداری یک فوق لیسانس حسابداری بگیرم؟ اونم نه. اینجاست که مدل سازی به کارم میاد. من در کنار کسی که متخصص حسابداری هست قرار میگیرم و هر چیزی که برای توسعه ی اون نرم افزار نیاز دارم رو از اون میپرسم. اما چون زبان تخصصی من و اون متفاوته باید یه زبان مشترک بین من و اون به وجود بیاد که از طریق اون سوال هایی که دارم بپرسم و جوابم رو بگیرم و بر اساس دانش منتقل شده مدل سازی کنم و از طریق مدل به وجود اومده نرم افزارم رو توسعه بدم.خوشحال میشم نظرتون رو راجع به این مطلب و مطالب آینده بدونم و نقص های موجود در متنم رو با نظر شما اصلاح کنم.

ماجراجویی در دنیای مفاهیم انتزاعی

sorkhemiri | سرخه میری — Fri, 10 Sep 2021 01:13:03 +0430

رویای انتزاعییادم میاد در ابتدای کاوش و یادگیری توی حوزه نرم افزار همیشه به فهوم انتزاع یا همون "abstraction" علاقه مند بودم و دوست داشتم در موردش بیشتر بدونم. عجیب بود، با وجود این که همه جای مهندسی نرم افزار مثال هایی ازش بود اما هیچ جا توضیح دقیق و واضحی براش پیدا نمیکردم تا این که با نگاه کردن از زوایای مختلف این مفهوم توی ذهنم شکل گرفت. توی این مطلب سعی میکنم این مفهوم رو با شما به اشتراک بگذارم.نقشه نمونه ای از انتزاعاول لازمه یک توضیح کوتاه در مورد خود کلمه ی انتزاع بدم که تا حدودی به فهم موضوع کمک میکنه. نزع یا انتزاع کردن به معنای درآوردن یا جدا کردن یک چیز از چیز دیگه است.حالا داستان ما از اونجا شروع میشه که انسان فهمید نمیتونه یک چیز رو از همه زوایای ممکنه و با توجه به همه ویژگی های خودش مورد مطالعه قرار بده و بفهمه. مثلا اگر ما یک تکه پنیر توی اتاق داشته باشیم هر کسی به یک شکلی به اون نگاه میکنه، شیمی دان اون رو به شکل یک جسم تشکیل شده از ذرات بسیار کوچیک با فرمول شیمیایی مشخص میبینه که روی هم قرار گرفتن و این شکل رو تشکیل دادن. متخصص تغذیه اون رو به شکل یک ماده غذایی میبینه که مقدار مشخصی کالری داره و هنگام هضم شدن تاثیرات به خصوصی روی بدن می گذاره. یک هنرمند اما ممکنه اون رو تکه ای از آسمان صبح ببینه که روی زمین افتاده و الان جاش توی آسمان خالیه. اون تکه پنیر یک چیز به خصوص هست و تغییری نمیکنه اما در دید انسان های متفاوت به دید های متفاوت نمود متفاوتی داره.سوال: آیا میشه هر جنبه ای که ممکنه از یک چیز (مثل اون تکه پنیر) رو مورد مطالعه قرار بدیم و بتونیم ادعا کنیم که هیچ دیدگاهی در مورد اون چیز نیست که ما بهش فکر نکرده باشیم؟بررسی کردن و محدودیت های آنواقعیت اینه که هر چقدر تعداد آدم هایی که توی اتاق هستند بیشتر باشه دیدگاه و نظر های متفاوت و بیشتری راجع به اون چیز به ذهن میرسه و دید ما کامل تر میشه اما هیچ وقت نمیتونیم ادعا کنیم هیچ زاویه ای نیست که ما ندیدیم و مورد بررسی قرار ندادیم.به بیان دیگه ما هیچ وقت نمیتونیم یک چیز رو همون طور که هست توی ذهنمون تصور کنیم. کاری که ما میکنیم اینه که یک سری ویژگی ها و خاصیت ها از اون چیز رو توی ذهن خودمون نگه میداریم. برای مثال سفید بودن یک ويژگی از پنیره وقتی به من میگن پنیر من یک چیز سفید جامد رو تصور میکنم. ولی آیا سفید بودن و جامد بودن تنها ویژگی هاییه که پنیر داره؟ معلومه که نه پنیر بوی خاصی هم داره و یک فرمول شیمیایه مخصوص به خودش اما ویژگی هایی که ذهن من از پنیر جدا کرده سفید بودن و جامد بودنه. در واقع ذهن من سفید بودن و جامد بودن رو از پنیر انتزاع میکنه. این ویژگی جالب مغز انسانه که چون نمیتونه یک چیز رو به طور کامل تو خودش هضم کنه یک سری ویژگی های خاص رو از اون چیز انتزاع میکنه و مساله رو برای خودش ساده میکنه تا بتونه اون رو بفهمه.در مطلبی که در آینده قرار میدم قصد دارم از abstraction در دنیای نرم افزار و فرایند مدل سازی بگم. خوشحال میشم نظرتون رو راجع به این مطلب و مطالب آینده بدونم و نقص های موجود در متنم رو با نظر شما اصلاح کنم.

تاریخچه ی الگو ها

sorkhemiri | سرخه میری — Tue, 11 Aug 2020 17:29:48 +0430

نوشته ی مرتبط قبلی الگوی طراحی چیست و چراالگو های طراحی کی کشف شدن؟این سوال یک سوال خوب ولی نه چندان دقیق است. الگو های طراحی مفاهیم مبهم و مشکلی نیستن در واقع بر عکس. الگو های طراحی راه حل های معمول برای حل مشکلات رایج در طراحی شیءگرا هستن. وقتی یک راه حل بارها و بارها در پروژه های مختلف تکرار میشه بالاخره یک نفر پیدا میشه و یک اسم روش میزاره و اون راه حل رو با جزییات توضیح میده. اینطور میشه که یک الگوی طراحی کشف میشه.مفهوم الگوی طراحی اولین بار توسط کریستوفر الکساندر در کتاب زبان الگو ها توضیح داده شد. این کتاب یک «زبان» برای طراحی محیط های شهری توصیف میکند. بخش های این زبان الگو ها هستن. اون الگو ها ممکنه بیان کننده ارتفاع لازم پنجره ها، تعداد طبقات یک ساختمان، میزان فضای سبز مورد نیاز برای یک محله و چیز های از این دست باشن.این ایده توسط چهار نویسنده به نام های اریک گاما، جان ولیسایدز،‌ رالف جانسون و ریچارد هلم دریافت شد. اون ها در سال 1994 کتاب الگو های طراحی : عناصر تکرار پذیر برنامه نویسی شیءگرا رو منتشر کردن و در اون ایده ی الگو های طراحی رو به برنامه نویسی وارد کردن. اونها در کتاب طراحی الگوها 23 الگوی طراحی رو توضیح داده بودن که مشکلات زیادی رو توی طراحی شیءگرا حل میکرد و به سرعت جزو کتاب های پر فروش شد. کتاب بخاطر اسم طولانیش بعد از مدتی میان مردم به «کتاب gang of four» و بعد ها به «کتاب GoF» معروف شد.از اون زمان ده ها الگوی طراحی دیگه در برنامه نویسی شیءگرا گشف شد. ایده الگو ها در تمام حوزه های برنامه نویسی محبوب شد و بخاطر همین در حال حاضر الگو های طراحی زیادی خارج از طراحی شیءگرا وجود دارن.منبع: refactoring guru

الگوی طراحی چیست و چرا؟

sorkhemiri | سرخه میری — Tue, 28 Jul 2020 13:21:43 +0430

Alexander Shvets کتاب drive into Design Patterns اثر الگو های طراحی (Design Patterns) راه حل های معمول برای حل مشکلات رایج موجود در طراحی نرم افزار هستن. در واقع هر الگوی طراحی مثل یک نقشه هست که به شما نشون میده چطور یک مشکل که به صورت مکرر در طراحی نرم افزار اتفاق میفته رو حل کنید.الگو های طراحی مثل توابع و کتابخانه ها نیستن که بتونید توی کدتون کپی شون کنید. یک الگو یک تکه کد نیست بلکه یک مفهوم کلی از راه حل برای یک مشکل هست. شما میتونید با دنبال کردن جزییات و نحوه پیاده سازی الگو با روشی که مناسب موقعیت و شرایط شماست مشکلتون رو حل کنید.الگو ها گاهی با الگوریتم ها اشتباه گرفته میشن، چون هردو راه حل های معمولی برای مشکلات شناخته شده ارایه میدن. یک الگوریتم همیشه یک مجموعه از قدم های مشخص برای رسیدن به یک هدف تعریف میکنه در حالی که یک الگو راه حل کلی تر برای حل مشکل ارایه میده. کد های پیاده سازی یک الگو برای دو برنامه متفاوت ممکنه با هم تفاوت داشته باشه.یک الگوریتم مثل یک دستور آشپزی هست: هر دو شامل قدم های مشخصی برای رسیدن به یک هدف هستن. در حالی که الگو ها مثل یک طرح اولیه هستن میتونید نتیجه کار و ویژگی هاش رو ببینید اما مراحل دقیق پیاده سازی به عهده خودتونه.الگو های طراحی از چه قسمت هایی تشکیل شدن؟الگو های طراحی معمولا با یک ساختار رسمی معرفی میشن که بشه اون ها رو تو بستر های مختلف باز تولید کرد. اینجا به بخش هایی که معمولا برای توضیح یک الگوی طراحی وجود داره اشاره میکنیم.خلاصه (Intent) : یک توضیح کوتاه در مورد مشکل و راه حل اونانگیزه (Motivation): یک توضیح مفصل تر از مشکل و راه حلی که این الگوی طراحی برای حل مشکل ارایه میدهساختار (Structure): ساختار کلاس های مختلف یک الگو و نوع ارتباط اون ها با همنمونه کد (Code example): نمونه کدی به یکی از زبان های شناخته شده که به فهم بهتر ایده ی پشت یک الگو کمک میکنه.گاهی یک سری ویژگی های دیگه مثل قابل استفاده بودن در موارد مختلف یا یک سری مراحل پیاده سازی یا ارتباط اون الگوی طراحی با الگو های طراحی دیگه هم در توضیحات قید میشه.تو قسمت های اینده در مورد انواع الگو های طراحی و توضیحات هر کدوم صحبت میکنیم.منبع: refactoring guru