اگر از جاوا یا سیشارپ به Go آمدهاید، اینترفیس اولین جایی است که عادتهای قبلی به هم میریزد. آنجا معمولاً کلاس را صریح به اینترفیس وصل میکنید؛ در Go مسیر وارونه است. اگر این تفاوت را ندانید، انتزاعهای زائد و کد سختنگهداری مینویسید.
اینترفیس در Go یعنی چه؟
اینترفیس فقط مجموعهای از امضای متدهاست. نوع داده لازم نیست نام اینترفیس را در تعریفش بیاورد — اگر همهٔ متدها را با همان نام و امضا داشته باشد، کامپایلر آن را منطبق میداند. به این میگویند پیادهسازی ضمنی.
نتیجه: تمرکز روی رفتار است نه هویت نوع. وابستگی پکیجها کم میشود و تستپذیری بالا میرود.
مثال اجرایی
فرض کنید پیام را به کانالهای مختلف میفرستید. بهجای چسبیدن به یک سرویس خاص، رفتار «ارسالکننده» را تعریف میکنید:
gopackage main
import "fmt"
type Notifier interface {
Notify(message string) string
}
type EmailService struct {
EmailAddress string
}
func (e EmailService) Notify(message string) string {
return fmt.Sprintf("ایمیل به %s: %s", e.EmailAddress, message)
}
func SendAlert(n Notifier, msg string) {
fmt.Println(n.Notify(msg))
}
func main() {
service := EmailService{EmailAddress: "[email protected]"}
SendAlert(service, "سرور دوباره در دسترس است.")
}
خروجی:
textایمیل به [email protected]: سرور دوباره در دسترس است.
SendAlert از جزئیات EmailService خبر ندارد؛ فقط میداند ورودی متد Notify دارد.
چه زمانی اینترفیس بنویسیم؟
قاعدهٔ رایج Go: اینترفیس را سمت مصرفکننده تعریف کنید، نه سمت ارائهدهنده — و وقتی واقعاً نیاز دارید، نه «شاید بعداً».
زمانهای درست:
- دو یا چند نوع، رفتار یکسان دارند (مثلاً خواندن از فایل یا حافظه).
- برای تست واحد به شبیهساز دیتابیس/API نیاز دارید.
- قرارداد کوچک و متمرکز میخواهید — مثل
io.Readerیاfmt.Stringer(اغلب یک متد).
اشتباه رایج
ساخت اینترفیس قبل از پیادهسازی واقعی: برای هر struct یک اینترفیس همنام با ده متد. بدون فایدهٔ تست، خوانایی پایین میآید. اگر فقط یک پیادهسازی دارید و تست به mock نیاز ندارد، مستقیم با همان نوع کار کنید.
قدم بعدی
برای تمرین گامبهگام Go با داور زنده در مرورگر، دورهٔ گو از صفر تا برنامهنویس در دینا کد را ببینید.
نظرها
اولین نفری باشید که نظر میدهدسؤالتان را بپرسید یا تجربهتان را بنویسید تا نویسندهی مطلب پاسخ بدهد.