الگوهای طراحی: روش کارخانه – انجمن DEV 👩‍💻👨‍💻

معرفی

من اخیرا در حال خواندن کتابی هستم از الکساندر شوتس تماس گرفت به الگوهای طراحی شیرجه بزنید. و او این الگوهای پیچیده را به عبارات بسیار شهودی و ساده با نمودارها، کد شبه زمان استفاده از آنها، نحوه استفاده از آنها، مزایا و معایب الگوها، و همچنین نحوه ارتباط آن با سایر الگوهای طراحی تقسیم کرده است.

من خوانندگان را به خرید کتاب تشویق می کنم و بیشتر محتوای این مقاله بر اساس کتاب است. اگر کسی بخواهد کتاب را بخرد، این لینک است، همچنین دوره‌ای در دسترس است که کمی گران است، اما فکر می‌کنم ارزشش را دارد.

از بس، بیایید به الگوهای طراحی خلاقانه بپردازیم. و امروز ما الگوی Factory Method که نقطه شروع همه الگوهای ایجادی است را مورد بحث قرار خواهیم داد. بنابراین اگر شما یک کدنویس متوسط ​​هستید، کمربند ایمنی خود را ببندید، زیرا سفر فوق‌العاده‌ای خواهد بود و در پایان آن می‌توانید این الگو را در پایه کد خود اعمال کنید و یک پایه کد قابل نگهداری و کارآمد ایجاد کنید.

من سفر را با نقل قول از استادم که از برنامه نویس معروف دیگری (نام را فراموش کرده است) شروع می کنم. می گذرد “کد سند است و سند رمز است.” حداقل یه همچین چیزی

اگر می دانید چیست الگوی ایجاد روش کارخانه پس کار خوبی که می دانی اما برای آن هق هق های بیچاره که آن را نمی دانند، به هر حال فقط برای آنها توضیح می دهم زیرا من یکی از آنها هستم.

روش کارخانه/سازنده مجازی

Factory Method یک الگوی طراحی ایجادی است که رابطی را برای ایجاد اشیاء در یک سوپرکلاس فراهم می‌کند اما به کلاس‌های فرعی اجازه می‌دهد تا نوع اشیایی که ایجاد می‌شوند را تغییر دهند. (مرجع: Dive into Design Patterns اثر Alexander Shvets)

این روش مستلزم آن است که از فراخوانی مستقیم سازنده‌های شی اجتناب کنیم. و در عوض، از یک روش خاص برای ایجاد اشیاء برای ما استفاده کنید. این روش Factory Method نام دارد. از این رو نام این الگو Factory Method است.

از اینجا به بعد اشیا را فراخوانی می کنیم محصولات. و کلاسی را که متد کارخانه در آن قرار دارد، آن را صدا خواهیم کرد کلاس کارخانه. کارخانه محصولات را با رفتار خاصی تولید می کند (که روش کارخانه ما است). همچنین ما Factory Class را با نام Creator Class می نامیم. هر دوی آنها دو نوع Abstract و Concrete دارند.

کلاس Factory/Creator می تواند یک رابط باشد و انواع مختلفی از زیر کلاس ها می توانند این رابط را پیاده سازی کنند و روش تولید محصول را به روش های مختلف تعریف کنند. همچنین می‌خواهم اشاره کنم که کلاس creator نیازی به یک رابط نیست، بلکه می‌تواند یک کلاس فوق‌العاده نیز باشد. و هر اقدام قابل تکراری که برای همه محصولات قابل اجرا باشد، می تواند در کلاس فوق العاده Creator قرار گیرد. اما روش ایجاد محصولات باید روشی انتزاعی باشد که باید روی سایر زیر کلاس‌های سازنده بتن پیاده‌سازی شود و نوع برگشتی نوع کلاس محصول بتن خواهد بود.

ساختار

برای نشان دادن منظورم در اینجا یک نمودار آورده شده است:

1. محصول رابط را اعلام می کند که برای همه اشیا مشترک است و توسط زیر کلاس بتن خالق تولید می شود.

2. محصولات بتن پیاده سازی سفارشی رابط محصول هستند.

3. کلاس abstract/super creator متد کارخانه را به صورت انتزاعی تعریف می کند و نوع بازگشتی باید رابط محصول باشد.

4. Concrete Creators کلاس کارخانه پایه را نادیده می گیرد بنابراین نوع متفاوتی از محصولات را برمی گرداند.

موارد استفاده:

1. زمانی که از قبل اطلاعی ندارید از روش کارخانه استفاده کنید
   انواع دقیق و وابستگی اشیایی که کد شما باید داشته باشد
   کار با.

2. زمانی که می خواهید به کاربران ارائه دهید از روش Factory استفاده کنید
   کتابخانه یا چارچوب شما با راهی برای گسترش داخلی آن
   اجزاء.

3. زمانی که می خواهید سیستم را ذخیره کنید، از روش Factory استفاده کنید
   منابع با استفاده مجدد از اشیاء موجود به جای بازسازی
   آنها را هر بار

نحوه پیاده سازی:

1. کاری کنید که همه محصولات از یک رابط استفاده کنند. این رابط باید روش‌هایی را که در هر محصول معنادار هستند را بیان کند.

2. یک متد خالی کارخانه داخل کلاس creator اضافه کنید. این
   نوع بازگشت روش باید با محصول رایج مطابقت داشته باشد
   رابط.

3. در کد سازنده همه ارجاعات به سازنده های محصول را بیابید. یک به یک آنها را با فراخوانی به روش کارخانه جایگزین کنید، در حالی که کد ایجاد محصول را به روش کارخانه استخراج کنید.

4. اکنون، مجموعه ای از زیر کلاس های سازنده برای هر نوع محصول فهرست شده در روش کارخانه ایجاد کنید. روش کارخانه را در کلاس‌های فرعی لغو کنید و بیت‌های کد ساخت مناسب را از روش پایه استخراج کنید.

5. اگر انواع محصول بسیار زیاد است و ایجاد کلاس های فرعی برای همه آنها منطقی نیست، می توانید از پارامتر کنترل از کلاس پایه در کلاس های فرعی استفاده مجدد کنید.

6. اگر بعد از تمام استخراج ها، روش کارخانه پایه خالی شد، می توانید آن را انتزاعی کنید. اگر چیزی باقی مانده است، می‌توانید آن را به‌عنوان یک رفتار پیش‌فرض متد تبدیل کنید.

طرفداران:

1. شما از اتصال محکم بین خالق و محصولات بتنی اجتناب می کنید.

2. اصل مسئولیت واحد می‌توانید کد ایجاد محصول را به یک مکان در برنامه منتقل کنید تا پشتیبانی از کد آسان‌تر شود.

3. اصل باز/بسته شما می توانید انواع جدیدی از محصولات را بدون شکستن کد مشتری موجود به برنامه معرفی کنید.

معایب:

1. ممکن است کد پیچیده‌تر شود زیرا برای پیاده‌سازی الگو نیاز به معرفی بسیاری از کلاس‌های فرعی جدید دارید. بهترین حالت زمانی است که شما الگو را در یک سلسله مراتب موجود از کلاس های سازنده معرفی می کنید.

نتیجه

در این مقاله سعی کردم الگوهای طراحی Factory Method را تجزیه کنم. و همچنین در مورد اینکه چیست و چگونه انجام می شود و چه زمانی مفید است بحث شد. یکی از چیزهایی که می‌خواهم به خوانندگان اطلاع دهم اگر پایه کد بسیار کوچکی دارید، این الگو ممکن است پیچیدگی خاصی ایجاد کند که باید نادیده گرفته شود، اما برای پروژه‌های بزرگ تا اندازه متوسط، اگر می‌خواهید کد شما قابل نگهداری و مستند باشد (نقل قول را به خاطر دارید؟ ) می تواند در زمان زیادی صرفه جویی کند و خوانایی کد و توسعه پذیری محصول شما را بهبود بخشد.