You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/chapter 9/creational patterns/9.1.6-builder.md
+45-23Lines changed: 45 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,8 @@ title: '9.1.6 الگو Builder'
3
3
slug: go-builder-pattern
4
4
weight: 172006
5
5
---
6
-
### مقدمه
6
+
7
+
### توضیحات
7
8
8
9
در دنیای طراحی نرمافزار، یکی از چالشهای رایج، **ساخت{{< tooltip text="اشیاء" note="Objects" >}} پیچیده با پارامترهای متعدد و متنوع** است. فرض کنید قصد دارید یک شیء پیکربندی برای اتصال به {{< tooltip text="پایگاه داده" note="Database" >}} بسازید. بسته به نوع پایگاه داده ای که می خواهید (MySQL، PostgreSQL، SQLite و …)، ممکن است به مجموعهای متفاوت از پارامترها نیاز داشته باشید: نام کاربری و گذرواژه، میزبان و پورت، نام پایگاه داده یا حتی مسیر فایل. اگر بخواهیم همهی این موارد را با یک {{< tooltip text="سازنده" note="Constructor" >}} ساده مدیریت کنیم، به زودی با توابعی پر از پارامترهای اختیاری و ترتیبهای گیجکننده مواجه خواهیم شد.
9
10
@@ -13,30 +14,12 @@ weight: 172006
13
14
الگوی بیلدر وقتی کمک کننده است که بخواهید یک شیء پیچیده با پارامترهای زیاد را مرحله به مرحله و خواناتر بسازید، بدون اینکه درگیر سازندههای طولانی و گیجکننده بشوید.
14
15
{{< /hint >}}
15
16
16
-
### چه زمانی نباید از الگوی Builder استفاده کنیم؟
17
-
18
-
1.**ساخت اشیاء ساده**
19
-
20
-
+ اگر شیء شما تنها چند پارامتر ساده دارد و ساخت آن راحت است، Builder پیچیدگی را زیاد میکند.
21
-
22
-
2.**ملاحظات عملکردی**
23
-
24
-
+ در برنامههایی که {{< tooltip text="کارایی" note="Performance" >}} مهم است، فراخوانیهای اضافی و ایجاد آبجکتهای موقت در Builder ممکن است باعث کاهش کارایی شود، بهویژه وقتی ساخت شیء مکرر است.
25
-
26
-
3.**اشیاء immutable و ساده**
27
-
28
-
+ اگر شیء ثابت و با فیلدهای نهایی است و ساخت آن ساده است، میتوان از سازندههای معمولی یا factory method استفاده کرد.
+ ایجاد یک Builder برای هر شیء پیچیده ممکن است کد را طولانی و پیچیده کند.
33
-
+ اگر شیء نیاز به ساخت مرحلهای ندارد، Builder میتواند اضافه باشد.
21
+
### نمونه کد: ساخت پیکربندی پایگاه داده با Builder
34
22
35
-
5.**وابستگی زیاد به محصول**
36
-
37
-
+ اگر Builder و محصول خیلی به هم وابسته باشند، تغییر در محصول نیازمند تغییر در Builder است و انعطافپذیری کاهش مییابد.
38
-
39
-
**مثال: ساخت پیکربندی پایگاه داده با Builder**
40
23
وقتش رسیده که یک نمونهی واقعی را ببینیم. در کدی که در ادامه میآید، ما یک ساختار `DBConfig` داریم که تنظیمات اتصال به پایگاه داده را نگه میدارد. یک **Builder** به نام `DBBuilder` ایجاد کردهایم که به ما اجازه میدهد با استفاده از متدهای زنجیرهای (`SetUser`, `SetHost`, …) تنها فیلدهای مورد نیاز خود را مقداردهی کنیم و در پایان با فراخوانی `Build()` شیء نهایی را تحویل بگیریم.
41
24
42
25
<!-- markdownlint-disable MD010 MD037 MD012 -->
@@ -163,5 +146,44 @@ func main() {
163
146
fmt.Printf("SQLite config: %+v\n", sqliteCfg)
164
147
}
165
148
}
149
+
166
150
{{< /play >}}
167
-
<!-- markdownlint-enable MD010 MD037 MD012 -->
151
+
<!-- markdownlint-enable MD010 MD037 MD012 -->
152
+
153
+
این کد، مفهوم الگوی بیلدر را در Go به شکلی بسیار ساده و شفاف پیادهسازی کرده است.
154
+
ساختار `DBConfig` شامل تمام فیلدهای لازم اتصال به پایگاه داده مثل نوع درایور، نام کاربری، رمز عبور، هاست، پورت، نام پایگاه داده، مسیر فایل (برای SQLite) و SSLMode است. `DBBuilder` یک سازنده مرحلهای است که این فیلدها را به صورت زنجیروار مقداردهی میکند.
155
+
156
+
متدهای `SetUser`، `SetPassword`، `SetHost` و بقیه، امکان پر کردن فیلدها به شکل خوانا و زنجیروار را فراهم میکنند. متد `Build` در پایان پیکربندی را اعتبارسنجی میکند، برای SQL فیلدهای `User` و `DBName` باید پر شوند، برای SQLite مسیر فایل الزامی است و پورت باید بین ۱ تا ۶۵۵۳۵ باشد. اگر خطایی باشد، ارور باز میگردد و در غیر این صورت پیکربندی معتبر تحویل داده میشود.
157
+
158
+
در تابع `main` دو مثال واقعی وجود دارد: یکی برای MySQL که تمام فیلدهای مرتبط پر شده و دیگری برای SQLite که تنها مسیر فایل مشخص شده است. این روش باعث میشود کد خوانا، قابل گسترش و ایمن باشد و ساخت پیکربندیهای مختلف پایگاه داده ساده و منعطف انجام شود. این پیادهسازی در عین سادگی نشان میدهد که چگونه میتوان با استفاده از الگوی Builder از پیچیدگیهای ایجاد اشیای بزرگ و متنوع کاست.
159
+
160
+
### کاربرد ها
161
+
162
+
در مواردی که اشیاء ما پارامترهای زیادی دارند و پیچیده هستند، استفاده از الگوی سازنده به کمک ما میآید. در مواردی مثل:
163
+
164
+
1. کانکشن های دیتابیس
165
+
2. فرم یا UIهای پیچیده
166
+
3. {{< tooltip text="لاگر" note="Logger" >}}
167
+
168
+
### چه زمانی نباید از الگوی Builder استفاده کنیم؟
169
+
170
+
1.**ساخت اشیاء ساده**
171
+
172
+
+ اگر شیء شما تنها چند پارامتر ساده دارد و ساخت آن راحت است، Builder پیچیدگی را زیاد میکند.
173
+
174
+
2.**ملاحظات عملکردی**
175
+
176
+
+ در برنامههایی که {{< tooltip text="کارایی" note="Performance" >}} مهم است، فراخوانیهای اضافی و ایجاد آبجکتهای موقت در Builder ممکن است باعث کاهش کارایی شود، بهویژه وقتی ساخت شیء مکرر است.
177
+
178
+
3.**اشیاء immutable و ساده**
179
+
180
+
+ اگر شیء ثابت و با فیلدهای نهایی است و ساخت آن ساده است، میتوان از سازندههای معمولی یا factory method استفاده کرد.
181
+
182
+
4.**افزایش پیچیدگی کد**
183
+
184
+
+ ایجاد یک Builder برای هر شیء پیچیده ممکن است کد را طولانی و پیچیده کند.
185
+
+ اگر شیء نیاز به ساخت مرحلهای ندارد، Builder میتواند اضافه باشد.
186
+
187
+
5.**وابستگی زیاد به محصول**
188
+
189
+
+ اگر Builder و محصول خیلی به هم وابسته باشند، تغییر در محصول نیازمند تغییر در Builder است و انعطافپذیری کاهش مییابد.
0 commit comments