مخزن: https://github.com/carolrochafloro/designpatternspoc/tee/main/designpatternspoc
درباره الگوی
الگوی سازنده به ما امکان می دهد بدون نیاز به ایجاد زیر کلاسهای مختلف از کلاس اصلی و بدون بارگذاری بیش از حد سازنده کلاس با پارامترهای بی شماری ، اشیاء پیچیده ای بسازیم.
باید در هنگام ساخت شیء از قسمت های این شیء جدا شود یا هنگامی که فرآیند ساخت و ساز نیاز به بازنمایی های مختلف از یک شیء دارد ، استفاده شود.
ساختار
رابط سازنده
یک رابط انتزاعی برای ایجاد بخش هایی از محصول (شی) مشخص می کند.
سازنده بتن
این قطعات را با اجرای رابط کاربری ساخته شده ، بازنمایی شی را تعریف می کند ، رابط کاربری را برای به دست آوردن محصول ارائه می دهد.
کارگردان
برای ساخت شی با رابط ساخته شده تماس بگیرید.
محصول
این شیء ایجاد شده توسط سازنده است. این ممکن است شامل کلاس هایی باشد که قسمت هایی را که آن را تشکیل می دهند تعریف می کنند.
چگونه کار می کند
مشتری کلاس کارگردان را نمونه می کند و با ساخته شده برای شیء مورد نظر پیکربندی می کند.
کلاس کارگردان هنگام ساخت بخشی از سازنده به سازنده اطلاع می دهد.
BuiltAder با اضافه کردن قسمت های محصول ، با پر کردن مجدد سروکار دارد.
مشتری محصول را از سازنده دریافت می کند.
مزایا
- این امکان را به ما می دهد تا نمایش داخلی یک شی را تغییر دهیم: همانطور که شی از طریق یک رابط عمومی ساخته می شود ، برای تغییر نمایندگی داخلی آن فقط یک نوع جدید از سازنده باید تعریف شود.
- کدهای ساخت و بازنمایی را جدا می کند ، بهبود مدولار کد.
- این کنترل بیشتر از فرآیند ساخت و ساز را ارائه می دهد: امکان تعریف یک ترتیب خاص برای ساخت و ساز را فراهم می کند و فقط به مشتری اجازه می دهد تا در پایان فرآیند ساخت و ساز به شی دسترسی داشته باشد.
ملاحظات
- رابط سازنده باید به اندازه کافی عمومی باشد تا امکان ساخت محصولات برای انواع سازندگان بتونی فراهم شود.
- ممکن است شما قبل از پایان ساخت و ساز به بخش هایی از محصول دسترسی پیدا کنید ، اگرچه بیشتر اوقات در این مورد نیست.
- در بیشتر موارد ، محصولات چنان با یکدیگر متفاوت خواهند بود که ایجاد یک کلاس انتزاعی برای همه و ارث نیست. مشتری کلاس کارگردان را با سازنده بتونی لازم پیکربندی می کند.
من چگونه انجام دادم
اکنون گام به گام خود را برای ایجاد یک شخصیت شخصیت RPG شرح خواهم داد. موضوع به طور اتفاقی انتخاب نشده بود ، پسرم به جدول RPG علاقه مند است و انتخاب فکر کردن در مورد او بود که به من در برخی جزئیات کمک کرد.
من یک نسخه گام به گام سازنده را انتخاب کردم ، و یک دستور درست را برای عدم تنظیم ویژگی توسط کاربر تعریف نکردم. برای انجام این کار ، من برای هر مرحله از رابط ها استفاده کردم ، با این که روش مربوطه به رابط بعدی بازگشت. اجرای آن بسیار ساده است ، هرچند تکراری.
کلاس شخصیت را ایجاد کردم ، من سازنده را برای دریافت نمونه ای از شخصیت Builder تعریف کردم و خواص را با توجه به مبالغ دریافت شده در سازنده تنظیم کردم.
من همچنین رابط های هر مرحله از فرآیند ایجاد شخصیت را ایجاد کردم ، همیشه پارامتر مربوطه را دریافت می کنم و به رابط بعدی برمی گردم.
پس از ایجاد موجودیت و رابط ها ، من با اجرای تمام رابط های مرحله -مرحله ای ، با همان خواص موجود ، سازنده خصوصی و روش شروع ، سازنده را ایجاد کردم ، به طوری که فقط با این کار امکان ساخت و ساز امکان پذیر بود روش ، که نمونه ای از خود سازنده را برمی گرداند.
سرانجام ، من تمام رابط ها را پیاده سازی کردم تا اینکه به آخرین روشی رسیدم که در آن من شخصیت سازنده را که از کلاس سازنده خود به عنوان یک پارامتر عبور می کند ، خواندم و آن را برگرداندم.
از آنجا که من یک تجربه اخیر در کار داشتم که در آن نیاز به ساختن یک شیء پیچیده برای توسعه تست های ادغام داشتم ، وقتی این اجرای سازنده را با مراحل تعریف شده مطالعه کردم ، یک ایده عالی پیدا کردم ، زیرا وقتی خواص زیادی وجود دارد ، این است ممکن است که به ما اجازه دهیم برخی را پشت سر بگذاریم و اشتباهات بیشتری پیدا کنیم.
منابع
refactoring.guru
الگوهای طراحی: عناصر نرم افزار شی گرا قابل استفاده مجدد
