История изменений

Вот я их с тобой и разбираю (уже второй). Для меня они выглядят резким усложнением.

Потому что нужно начинать с того какую проблему они решают.

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

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

Пока ты поддерживаешь изменения, внесённые на основании книги

Я их поддерживаю для решения конкретных проблем, а ты воспринимаешь их как бест практис которыми они не являются.

Писать код так что бы люди которые будут его поддерживать сказали спасибо это в принципе не просто, и ООП тут вообще не при чем, если бы у вас было ФП ты бы вообще повесился.

Вот я их с тобой и разбираю (уже второй). Для меня они выглядят резким усложнением.

Потому что нужно начинать с того какую проблему они решают.

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

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

Пока ты поддерживаешь изменения, внесённые на основании книги

Я их поддерживаю для решения конкретных проблем, а ты воспринимаешь их как бест практис которыми они не являются.

Писать код так что бы люди которые будут его поддерживать сказали спасибо это в принципе не просто, и ООП тут вообще не при чем, ели бы у вас было ФП ты бы вообще повесился.

Вот я их с тобой и разбираю (уже второй). Для меня они выглядят резким усложнением.

Потому что нужно начинать с того какую проблему они решают.

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

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

Пока ты поддерживаешь изменения, внесённые на основании книги

Я их поддерживаю для решения конкретных проблем, а ты воспринимаешь их как бест практис которыми они не являются.

Писать код так что бы люди которые будут его поддерживать это в принципе не просто, и ООП тут вообще не при чем, ели бы у вас было ФП ты бы вообще повесился.

Вот я их с тобой и разбираю (уже второй). Для меня они выглядят резким усложнением.

Потому что нужно начинать с того какую проблему они решают.

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

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

Пока ты поддерживаешь изменения, внесённые на основании книги

Я их поддерживают для решения конкретных проблем, а ты воспринимаешь их как бест практис которыми они не являются.

Писать код так что бы люди которые будут его поддерживать это в принципе не просто, и ООП тут вообще не при чем, ели бы у вас было ФП ты бы вообще повесился.

Вот я их с тобой и разбираю (уже второй). Для меня они выглядят резким усложнением.

Потому что нужно начинать с того какую проблему они решают.

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

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

Пока ты поддерживаешь изменения, внесённые на основании книги

Я их поддерживают для решения конкретных проблем, а ты воспринимаешь их как бест практис которыми они не являются.

Писать код так что бы люди которые будут его поддерживать это в принципе не просто, и ООП тут вообще не при чем, ели бы у вас было ФП ты бы вообще повесился.