จากสถานะมุมมองสู่คลาสโมเดล

When a screen has many @State values, your view starts juggling data and UI at once. That mix gets messy fast as the screen grows. 🤔

A model is a plain object that holds your data and the rules around it, kept separate from how things look on screen.

Start by moving related values into one class so they live together in a single, tidy place.

Put behaviour next to the data with methods, so the view just asks the model to act instead of doing the work itself.

A class is a reference type, so every view sharing the same instance sees the exact same data, not its own private copy.

With logic in the model, your view body shrinks to mostly layout. A thin view is far easier to read and change later.

Keeping data in the model gives you one source of truth, so screens never disagree about the current value.

Because the model is independent of any view, you can reuse it across several screens or even in tests.

A view can create and hold a model instance as a property, ready to read its values and call its methods.

So far the view can read the model, but it will not yet refresh when the data changes. We will fix that with observation next.

This split is called separation of concerns: the view shows, the model decides. Each part has one clear job.

You learned to lift data and logic out of a view into a model class, keeping views thin and giving your app one source of truth. ✨