Денормализацию БД тоже делают иногда, хотя аналогии - зло... Если ты уверен, что спецификации не поменяются, а продукт делается на один раз и изменений не будет то лепи один большой пельмень, бери на себя ответственность. Особенно если этот пельмень весь в полном объеме может быстро понять новый человек

Это, по большей части, моральный императив.

А если не на один раз? Но это архитектурное решение меняться не будет никогда.

Можно делать как угодно, об архитектуре проектов начинают думать замучившись поддерживать лапшу.

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

Ну так паттерны головного мозга на ровном месте — другая крайность, нужно искать золотую середину.

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

Хорошая архитектура не может появиться потом — это уже больше тянет на переписывание продукта в процессе масштабного рефакторинга.

Никогда не говори никогда

У тебя весь проект переврётся, инфа 100%. Вопрос в том, сколько головной боли ты поимеешь, перевирая сначала 1% проекта, потом 10%, потом 40%, потом 80%, потом 100% проекта. Если проект не дохлый, то это вопрос времени.

А как вы делаете?

Знаю, что мой код попадёт к маньяку, который узнает, где я живу

Делаю чтобы отдавать отчёт в том, что через стопицот лет другой человек за короткий промежуток раскурит логику и без напрягов перемутит одно в другое.

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

Почему все книги учат, что нужно отделять гуй, usecase, бизнес сущности и т.д.

Потому что сложность системы определяется количеством связей между ее компонентами. Когда всё отделено - связей меньше и их проще контролировать. Вообще, модульность - это основа SE.

Будут меняться требования. То, что думал заказчик, ты, пользователи и прочие будет меняться потому сокращай число зависящих компонентов. Проще менять мелкие и не зависящие компоненты чем большой слипшийся пельмень препарировать. Закрывай все взаимодействие интерфейсами ибо не знаешь, что готовит завтрашний день

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

Можешь. Если пишешь hello world.

Нарушать правила - это для умных и сильных. То есть, для единиц, для очень немногих. А простой тупой заедушник должен тупо следовать правилам, пусть даже и тупым, потому что нарушить правила по-умному он не осилит.

Потому что ты можешь уволиться, а людям пришедшим после тебя, придётся разбираться в коде

Почему все книги учат, что нужно отделять гуй, usecase, бизнес сущности и т.д.

А почему родители учат детей чистить зубы, мыть руки и не жрать все конфеты зараз? Да потому, что НЕ чистить зубы, НЕ мыть руки, жрать все конфеты зараз и быдлокодить любой ребенок умеет изначально.

Но если, например, у меня Android проект, и там для сохранения в базу я могу юзать только sqlite, зачем придумывать какие-то абстракции и усложнять себе жизнь?

А когда сохранение захочется сделать не sqlite, а в облачное хранилище с поддержкой снапшотов, версионности, решения коллизий, то вы вспомните об абстракциях.

Дело не в расширяемости. Просто смешивать разные слои в одном коде плохо - читабельность хуже в разы. Не получается «чистого кода». Впрочем это имеет значение только если над кодом несколько человек работает. Если работаешь один, складывай все вместе на здоровье, скорее всего никаких последствий от этого не будет

Потому что сложность системы определяется количеством связей между ее компонентами. Когда всё отделено - связей меньше и их проще контролировать

ничего подобного. Сложность системы форсится неконсистентностью, грубо говоря, когда на каждую сущность свой протокол и своя специфика, сильно ограничивается возможность построения абстракций. А именно это и получается, если все разделять ради самого разделения. Контролировать проще именно связанные абстракции, другой вопрос, как именно их связывать, это как раз и есть искусство проектирования.

Но если, например, у меня Android проект, и там для сохранения в базу я могу юзать только sqlite, зачем придумывать какие-то абстракции и усложнять себе жизнь?

Уверен что через 5 лет ситуация будет точно такой же и что тебе не захочется портировать твой проект на ямобилко?

Зачем я должен отделять sql код от бизнес сущности если, исходя из требований, никогда не будет меняться метод сохранения в бд? Почему я должен вносить не оправданную сложность?

Структура БД вообще не надежная штука и меняется достаточно часто.

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

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

Но вообще многое зависит от выбранной модели разработки ПО.

Сложность системы форсится неконсистентностью

А, окей.

пусть есть банки, которые выдают кредиты, и у каждого процентная ставка своя, но рассчитывается в зависимости от ставки центробанка. Если мы связываем ставку ЦБ с этими банками, нам нужно всего лишь скорректировать ставку ЦБ, и все банки сами все пересчитают. Если же ты их отделил, тебе вручную придется передрачивать каждый банк в отдельности. А если мы сюда включаем не только банки, но и другие кредитные организации, становится совсем печально. Вот и думай, в одном случае, ты все связал, и все что тебе надо, подправить процентную ставку ЦБ, а в другом, стая обезьян начинает все переписывать, и делает еще ошибки при этом. Какой код сложней в поддержке?

Практика показывает, что если клиент говорит - никогда не будет меняться, значит максимум на пару лет. Придумают некие новые фичи, которые кровь из носа надо внедрить... У нас вот парни сейчас плюхаются с клубной системой, которая была спроектирована именно исходя из «всегда будет именно так». А разного рода главные менеджеры понапридумывали акций для покупателей, которые логически не состыковываются с архитектурой клубной системы. Клиенты ресторанов естественно недовольны.

Обычно я мучаюсь, когда нахерачу 100500 классов в угоду архитектуре

Вот я не понимаю одного, почему нахерачить 100500 классов называют «в угоду архитектуре», если архитектура от этого только страдает? Зачем тогда наследование нужно? Совместное, повторное использование кода уже к архитектуре не относится? Тогда причем тут ООП вообще?

Вот я не понимаю одного, почему нахерачить 100500 классов называют «в угоду архитектуре», если архитектура от этого только страдает?

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

И что? Использовать 5 классов там где достаточно одного свитча — признак хорошей архитектуры? Или к чему это было сказанно?

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

Насколько я понимаю, там вообще не об этом речь шла. Сейчас бытует баззворд, который как бы говорит, что лучше нахреначить множество классов, чем использовать наследование, это называется «слабое связывание», чтоли, или хз. То есть, если в ООП принято делать иерархию, использовать наследование, чтобы сделать систему проще и гибче, декларируется прямо противоположное, вопреки здравому смыслу, и это почему то называется «тоже ООП».

Круг нарисуй, потом уже о банковских системах будешь фантазировать.

То есть ты вот так просто слился? Сильно.

То есть ты вот так просто слился?

Ну не спорить же мне с тобой.

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

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

что через стопицот лет

Да ты оптимист если считаешь что твой код еще будет кому-то нужен через N лет)

А когда сохранение захочется сделать не sqlite, а в облачное хранилище с поддержкой снапшотов, версионности, решения коллизий, то вы вспомните об абстракциях.

А когда окажется что приложение должно быть не только мобильным, но еще и десктопным и браузерным о чем вспоминать? Границы разумного тоже должны быть.

Завтра фирма разработчик дропнет поддержку твоего графического фреймворка и будет очень весело.

Завтра линус и все-все-все перестанут поддерживать ядро. Ты правда обо всем этом заботишься?

Клиенты ресторанов естественно недовольны

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

Да, пишу софт, который не привязан к ядру, если есть такая возможность. А ты во всякой программе дергаешь abi и api ядра Linux-а?

парень, ты уверен, что точно читал книги по тому языку, который тебе нужен?

Почему нельзя? Можно. Пока программа не переросла 50 строк, можно и из виджета запрос посылать.

А зачем это делать, если ты точно знаешь, что кроме как на линуксе твое ПО работать не будет?

Ты никому ничего не должен, дружище

Я не пишу ПО только для Linux-а. )

Не должен. Проблема в том что если проект предполагается развивать и поддерживать, то требования о постоянстве метода сохранения сущности в бд идут лесом. А виджет очень скоро кроме отправки запросов будет отвечать за половину базовой логики.

А когда окажется что приложение должно быть не только мобильным, но еще и десктопным и браузерным о чем вспоминать?

Об абстракциях и архитектуре приложения.

Границы разумного тоже должны быть.

А к то с этим спорит?

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

Об абстракциях и архитектуре приложения.

И много ты видел абстракций и архитектур которым удавалась многоплатформенность? Я почему-то встречал только вариант с отдельными разработчиками под каждую - веб, андроид, ios и тд.

И много ты видел абстракций и архитектур которым удавалась многоплатформенность?

Игровые движки, физические движки.

Я почему-то встречал только вариант с отдельными разработчиками под каждую - веб, андроид, ios и тд.

Если я суслика не вижу, значит он не существует?

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

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

И вообще, почему деление именно Model-View-Controller? Почему не «выбор предмета из базы» / «работа (редактирование/просмотр) с элементом» / «формирование отчёта», например?

P.S. Stable API is nonsense