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