Обновление экземпляра Struct

Question

Я использую структуры по умолчанию, когда это возможно, так как лучше обновлять исходный экземпляр структуры, копия которого передается другой переменной. скажем, у меня есть Post struct

struct Post {
    let title: String
    let likes: Int
    let viewsCount:Int
    var comments:[Comment]
}

, и у нас есть простые экраны Master-Details. При нажатии на экран деталей мы копируем post в сцену деталей, и там могут быть данные изменен как приращения лайков, добавлены комментарии и т. д., так что при вставке This ViewController в новую модель данных обновляется исходная модель в Master ViewController. Каковы возможные решения и лучшие практики для него? при условии, что мы используем MVC или MVP

Answer 1

Это действительно не имеет ничего общего со структурами; это просто обычная проблема передачи данных в контроллер представления при создании и передачи данных обратно из , который просматривает контроллер при уничтожении. Бывает, что в вашем случае вы утверждаете, что это «те же» данные - то есть вы передаете сообщение в контроллер подробного представления и передаете сообщение обратно из контроллера подробного представления - но это просто случайный факт.

Итак, чтобы ответить на поставленный вопрос, вы должны использовать любой из обычных приемов. Контроллер подробного представления должен будет передать измененную публикацию обратно в главный контроллер представления. Он мог бы использовать Уведомление или (точнее) использовать стандартную архитектуру протокола и делегата.

---

С другой стороны, если Post является основой данных вашего приложения, это не будет неоправданно утверждать, что сама предпосылка ошибочна: это должен был быть класс, а не структура, именно для того, чтобы данные могли храниться в центральном месте, а ссылки на них могли храниться в разных местах.

Действительно, если все сложнее, данные приложения (включая Post) могут находиться в каком-то третьем месте в пространстве модели-данных, и все контроллеры представления отправляют уведомление up на данные, когда они изменяют его и имеют данные, отправляют уведомление вниз всем контроллерам представления в ответ (это то, что ответ Ральфа Эберта вполне разумно предполагает). Подобные вещи намного проще в наше время, потому что (в iOS 13) у нас есть наблюдаемые объекты и структура Combine.

Answer 2

Вы можете создать общий класс совместно используемой модели, который отвечает за хранение данных Post и который оба контроллера представления могут использовать и наблюдать.

Answer 3

В идеале классы лучше всего подходят для роли, которую вы описали как объект, поддерживающий идентичность. Каждый пост имеет индивидуальность. Согласно Apple Docs «используйте классы, когда вам нужно контролировать идентичность данных, которые вы моделируете» Когда вы делитесь экземпляром класса со своим приложением, изменения, которые вы вносите в этот экземпляр, видны для каждой части вашего кода, содержащей ссылку в этом случае. Используйте классы, когда вам нужно, чтобы ваши экземпляры имели такую ​​идентичность. Классы против распорки

Answer 4

Я бы создал вспомогательные функции и сделал бы их мутирующими. например,

mutating func incrementLikes() { 
   likes += 1 
}

Убедитесь, что ваши свойства var.