Тестове завдання.

Один раз у мене був досвід лайв-кодування. Це було жахливо. Коли тебе просять щось спроєктувати й уважно спостерігають, мовчки дивлячись, ти не можеш зосередитися та обдумати, як зробити це якісно. Ще й під час цього інтерв’ю мене часто перебивали, коли я писав код, вставляючи свої зауваження, що лише додавало дискомфорту. Відтоді, як тільки чую про лайв-кодування, одразу відмовляюся від співбесіди. Я розумію, що це не мій формат, такий підхід навіть не відповідає реальним умовам роботи.

А причем тут Арестович и что с ним не так? :)
Он обозреватель политических и военных действий. Пересказывает публичные сводки от генштаба и политические заявления тех или иных деятелей. Иногда дает мелкие инсайды. Ничего более... Какие есть мнения на этот счет? :)

Что могу сказать... Все singleton, описанные тобой выше, не имеют хранимых свойств которые можно изменить и получить какой либо конфуз в приложении. Те правильно написанный singleton не является проблемой.

Мы обсуждаем почем он является антипаттерном и какие проблемы может за собой потянуть если его написать неграмотно. Перечитай еще раз переписку. :)

ещё раз по тому же ж синглтон существует для того чтобы распределить единый объект на все точки доступа к этому объекту всё

Да, так и есть. Никто и не говорит, что у него другое предназначение. :) Распределить единый объект на все точки приложения можно по-разному. В этом и заключается его антипаттерность.

"Антипаттерн (англ. anti-pattern) — это распространённый подход к решению класса часто встречающихся проблем, являющийся неэффективным, рискованным или непродуктивным

Мы же не обсуждаем вопрос решения конкретной задачи, поэтому на вопрос «зачем моему приложению такой стейт» я отвечать не стану. Это не боевой пример а поэтому названия свойств, типы, количество свойств и суть класса могут отличатся от реальной жизни. :)

Суть этого примера показать почему Singleton является антипаттерном. Причем добавлю, что я подобных примеров в реальных проектах встречал неоднократно.

Дал ответ выше :)
Нуу чтобы «новый» не сказал бы. Singleton со своими проблемами существует уже давно.

Все верно :)

«Антипаттерн (англ. anti-pattern) — это распространённый подход к решению класса часто встречающихся проблем, являющийся неэффективным, рискованным или непродуктивным. В отличие от шаблона проектирования, рассмотрение антипаттерна включает в себя как неправильное решение проблемы с его признаками и последствиями, так и выход из ситуации.»

Singleton может быть написан во вред, либо во благо.
Например:

// Что может приводить к ошибкам:

class Singleton {

static var shared = Singleton()
private init() {}

var isShowed: Bool = false
}

// Что может работать на пользу:

class Singleton {

static var shared = Singleton()
private init() {}

var isShowed: Bool {

return //* calculate isShowed *//
}
}

Кто не знает swift, во втором примере isShowed это get свойство которое не имеет в себе setter-a, соответсвенно избегает ошибок сохранения в «isShowed» с разных точек приложения.

PS — Данный код написан как пример, чтобы передать суть :)

Нуу инкапсуляция не диктует правило что все свойства должны быть скрыты. Тут больше вопрос в правильном выбранном архитектурном подходе. Можно написать код который будет менять свойство (хранимое) в нескольких местах. Например, какой-то свойство «isShowed: Bool». Если это свойство менять в разных частях приложения и к нему же обращаться, чтобы понять «что же там лежит», то можно наткнуться на проблемы (если есть большие зависимости). Можно запутаться, потом править это, потом выяснить, что твоя правка поломала другой кусок так там нужно чтобы «isShowed» было true, а ты поставил false на пред. экран и так д.

Нужно понимать когда его можно применять, а когда лучше обойти стороной. Антипаттерн потому что «Singleton» это один объект всего жизненного цикла приложения и ты можешь изменить данные с любых точек, что может привести к разным проблемам и конфузам. Иногда он может быть очень полезен, но необходимо придерживаться определенных правил.