Один из вариантов "правильного вопроса" в этой ситуации - а с какого, собственно, при наличии "своего сервака" так уж не желателен VPN, для таких задач, в принципе, и предназначенный? Любой P2P потребует для начала соединить эти P между собой, а их обоих в общем случае можно с уверенностью считать находящимися за NAT.
Если валидируются не файлы - выделить из формы ту часть, которая валидируется, и второй формой предлагать прикрепить к ней файлы (уже имея ID заполненных данных).
Не создавая сложных конструкций на ровном месте.
lz961, были прецеденты съезжания того форматирования при открытии того же docx на другом компьютере. Офисные форматы и гарантии сохранения форматирования есть вещи несовместные.
Евгений Шатунов, ну, я как бы и возражаю по первому пункту: совершенно не факт, что этот объект знает слишком много.
В Вики определение, как в российском законодательстве - многозначительно и предельно неконкретно... а проблема GO, как таковая - в размытии областей ответственности и высокой связности такого кода, с которой можно и нужно бороться декомпозицией. Здесь, похоже, декомпозиция тоже показана, но на этом сходство с GO, вполне возможно, и заканчивается.
pfedorov031090, есть готовое решение - забыть о существовании MS Office и сгенерировать банальный HTML. Сохранить его с расширением .docx - и, внезапно, Ворд ничего даже не заметит...
Евгений Шатунов, GO, как я его понимаю - это не про объем и разделение, а про грубое нарушение инкапсуляции. Там, где должны быть интерфейсы и разделение логики - GO хватает что хочет откуда хочет и влезает в любой процесс в любом месте.
А тут - вполне возможно, что вся работа с этим классом идет через один-единственный метод, и ничего лишнего, кроме необходимого, он об окружающем коде не знает. Просто сама его работа достаточно развесиста и может быть вынесена в подклассы.
Виктор, это ничего не меняет.
Логично СНАЧАЛА собрать данные, а ПОТОМ из них уже делать запрос, ЕСЛИ он вообще имеет смысл. Это позволит через год, разбираясь в этом коде, не крыть трехэтажно того, кто такого наворотил. Стыдливо вспоминая, что сам же и обосрался.
Вообще-то ничто в вопросе не указывает, что это именно God Object, а не просто, скажем, замороченный калькулятор для четырех разных расчетов, в котором не удосужились грамотно выделить подклассы.
Если в коде уже известно, что поле не нужно будет менять - логично в коде же и предусмотреть ветку, не вставляющую в запрос это изменение. Или не делающее запрос вовсе, если в этом нет смысла. А сбегать в базу, чтобы ничего не сделать - это говнокод.
Никита, собственно, ваш пример - яркий симптом архитектуры, нарушающей S в SOLID. Поэтому обсуждение того, как лучше с этим работать, не имеет особенного смысла. Лучше - переделать грамотно, тогда и подобные вопросы отпадут сами собой.
Никита, смотря что вы с ними работаете. Чтобы посмотреть реализацию нужного метода, в IDE достаточно одного щелчка. Какой длины файл, в котором он находится - вообще некритично. А вот если придется искать, в каком из пяти файлов разложено нужное - тут и IDE может начать глючить.
Продумывание того, в чем все равно не разбираешься - это разновидность прокрастинации.
Если понятно, что будет работать при любой разметке - нечего городить огород без необходимости. Самому же потом разгребать косяки, и уж лучше пусть они будут из тех, с которыми сталкиваются 90% админов, чем модно-молодежными-хрен-найдешь-спеца.
Вообще-то тот же Яндекс, вполне возможно, станет вас обижать в поиске за такое решение.
С его точки зрения, правильное решение - два разных домена для разного контента.
Заменить монитор, раскурочив устройство, которое стоит дороже того монитора, и заменить его все равно не может - это даже не "стоя в гамаке", это "знает толк в извращениях"
xotkot, "вызывающе" не подходит тем более. Я вообще не любитель мериться и набрасываться. Просто пытаюсь понять людей. И насколько я понял ТС, для него ваш комментарий - китайская грамота. Впрочем, это ему судить.
