@ObservedObject: چیست، مشاهده اشیاء و به‌روزرسانی View

@ObservedObject در SwiftUI چیست

@ObservedObject — یک property wrapper است که View را در تغییرات ObservableObject مشترک می‌کند. وقتی شیء مشخص شده با @ObservedObject هر یک از ویژگی‌های خود که با @Published اعلام شده‌اند را تغییر می‌دهد، SwiftUI به طور خودکار View را دوباره ترسیم می‌کند. @ObservedObject شیء ایجاد نمی‌کند — فقط بین یک نمونه موجود ObservableObject و View که باید به تغییرات آن واکنش نشان دهد، ارتباط برقرار می‌کند.

تفاوت کلیدی بین @ObservedObject و @StateObject — مالکیت است. @ObservedObject فرض می‌کند که شیء در جایی بالاتر در سلسله‌مراتب View ایجاد و ذخیره شده است. View فرزند یک ارجاع به این شیء را از طریق مقداردهنده اولیه دریافت می‌کند و صرفاً آن را مشاهده می‌کند. اگر View فرزند دوباره ایجاد شود، همان ارجاع را از والد دریافت می‌کند — داده‌ها از دست نخواهند رفت.

به گفته Apple Developer Documentation — SwiftUI (2025)، @ObservedObject از iOS 13 در دسترس است، که آن را تنها گزینه برای مشاهده ObservableObject در پروژه‌هایی می‌کند که از نسخه‌های قدیمی iOS پشتیبانی می‌کنند. در iOS 14+ برای ایجاد اشیاء @StateObject ترجیح داده می‌شود، اما @ObservedObject برای انتقال اشیاء موجود همچنان مرتبط است.

@ObservedObject چگونه کار می‌کند

مکانیزم @ObservedObject بر اساس پروتکل ObservableObject از framework Combine است. هر کلاسی که با ObservableObject مطابقت دارد، به طور خودکار یک publisher objectWillChange دریافت می‌کند که قبل از تغییر هر ویژگی @Published سیگنال ارسال می‌کند. SwiftUI از طریق @ObservedObject در این publisher مشترک می‌شود و پس از دریافت سیگنال، View را به عنوان نیازمند ترسیم مجدد علامت‌گذاری می‌کند.

class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var isLoading = false
    
    func loadTasks() async {
        isLoading = true
        // واکشی داده‌ها
        isLoading = false
    }
}

struct TaskListView: View {
    @ObservedObject var viewModel: TaskViewModel
    
    var body: some View {
        List(viewModel.tasks) { task in
            Text(task.title)
        }
        .task { await viewModel.loadTasks() }
    }
}

وقتی View والد viewModel را از طریق مقداردهنده اولیه به TaskListView منتقل می‌کند، SwiftUI بین شیء و View ارتباط برقرار می‌کند. با تغییر آرایه tasks یا پرچم isLoading، SwiftUI TaskListView را دوباره ترسیم می‌کند. شیء در این میان بدون تغییر می‌ماند — در View والد از طریق @StateObject ذخیره می‌شود.

@ObservedObject در مقابل @StateObject: چه زمانی از کدام استفاده کنیم

تفاوت بین @ObservedObject و @StateObject — تفاوت بین ناظر و مالک است. @StateObject شیء ایجاد می‌کند و چرخه حیات آن را مدیریت می‌کند. @ObservedObject فقط شیئی را مشاهده می‌کند که در جای دیگری ایجاد و ذخیره شده است. انتخاب بین آنها با مسئولیت View نسبت به داده‌ها تعیین می‌شود.

قانون اصلی: اگر View شیء ایجاد می‌کند — @StateObject. اگر View شیء دریافت می‌کند — @ObservedObject. نقض این قانون به سمت @ObservedObject برای ایجاد شیء منجر به از دست رفتن داده در بازسازی View می‌شود. نقض به سمت @StateObject برای دریافت شیء یک نمونه تکراری مستقل از والد ایجاد می‌کند.

نمونه‌های استفاده از @ObservedObject

سناریوی معمول استفاده از @ObservedObject — یک لیست وظایف، که در آن View ریشه یک view model ایجاد می‌کند و سلول لیست آن را از طریق @ObservedObject دریافت می‌کند. هر سلول می‌تواند متدهای view model را فراخوانی کند و تغییرات به طور خودکار در کل لیست نمایش داده می‌شوند، زیرا همه سلول‌ها یک شیء را مشاهده می‌کنند.

struct TaskRow: View {
    @ObservedObject var viewModel: TaskViewModel
    let task: Task
    
    var body: some View {
        HStack {
            Text(task.title)
            Spacer()
            Button("انجام شد") {
                viewModel.completeTask(task)
            }
        }
    }
}

struct TaskListContainer: View {
    @StateObject var viewModel = TaskViewModel()
    
    var body: some View {
        List(viewModel.tasks) { task in
            TaskRow(viewModel: viewModel, task: task)
        }
    }
}

در این مثال TaskListContainer viewModel را از طریق @StateObject ایجاد می‌کند و هر TaskRow آن را از طریق @ObservedObject دریافت می‌کند. وقتی کاربر “Done” را در هر سطری کلیک می‌کند، viewModel.completeTask ویژگی published را تغییر می‌دهد و همه View‌هایی که این شیء را مشاهده می‌کنند به طور خودکار به‌روز می‌شوند.

خطاهای معمول با @ObservedObject

رایج‌ترین خطا — استفاده از @ObservedObject برای ایجاد شیء در داخل View است. وقتی View بازسازی می‌شود (مثلاً با تغییر state)، SwiftUI یک نمونه جدید ObservableObject ایجاد می‌کند که منجر به از دست رفتن تمام داده‌های جمع‌آوری شده می‌شود. این خطا به خصوص در NavigationStack دردناک است، جایی که کاربر می‌تواند فرمی را پر کند و هنگام بازگشت داده‌ها را از دست بدهد.

خطا: @ObservedObject به جای @StateObject

// ❌ از دست رفتن داده: @ObservedObject شیء را نگه نمی‌دارد
struct FormView: View {
    @ObservedObject var formVM = FormViewModel()
    // فرم VM جدید در هر بازسازی View ایجاد می‌شود!
}

// ✅ درست: @StateObject شیء را نگه می‌دارد
struct FormView: View {
    @StateObject var formVM = FormViewModel()
    // شیء یک بار در طول عمر View ایجاد شد
}

خطا: انتقال @StateObject جایی که @ObservedObject نیاز است

اگر View فرزند همان ObservableObject را از طریق @StateObject اعلام کند، یک کپی مستقل ایجاد می‌کند. تغییرات در شیء والد در فرزند دیده نخواهد شد و بالعکس. همیشه برای Viewهای فرزندی که شیء را از خارج دریافت می‌کنند از @ObservedObject استفاده کنید.

جایگزین‌های @ObservedObject در SwiftUI

در SwiftUI مدرن چندین جایگزین برای @ObservedObject وجود دارد، هر کدام با مزایای خود. انتخاب به معماری برنامه، نسخه iOS و سناریوی استفاده خاص بستگی دارد.

• @EnvironmentObject — به شما امکان می‌دهد شیء را از محیط SwiftUI بدون انتقال صریح از طریق مقداردهنده اولیه دریافت کنید. برای اشیایی که در بسیاری از صفحه‌ها نیاز هستند مناسب است، اما نیاز به تزریق صریح از طریق .environmentObject() دارد.
• @State + @Binding — برای انواع مقدار ساده به ObservableObject نیازی نیست. برای ذخیره از @State و برای انتقال به Viewهای فرزند از @Binding استفاده کنید.
• @AppStorage — برای مقادیر UserDefaults که باید به طور خودکار با View همگام شوند.
• @SceneStorage — برای ذخیره وضعیت موقت بین راه‌اندازی مجدد صحنه (مثلاً موقعیت در لیست).

انتخاب بین @ObservedObject و @EnvironmentObject — یک مسئله سبک و معماری است. @ObservedObject وابستگی‌های View را از طریق مقداردهنده اولیه به وضوح نشان می‌دهد که کد را قابل پیش‌بینی‌تر می‌کند. @EnvironmentObject برای سلسله‌مراتب عمیق مناسب است، اما وابستگی‌ها را پنهان می‌کند که می‌تواند اشکال‌زدایی را دشوار کند.