Здравствуйте, Sinclair, Вы писали:

S>Нет, не рефакторинг. Они снаружи видны. Нужность — штука воображаемая: в вашем же примере они как будто бы были не нужны, и вдруг рраз! И стали нужны.
Еще один... Да всё, всё есть наблюдаемое состояние, если я решу за этим наблюдать. Добавил параметр в метод это изменяет расположение в памяти и, соответственно, размер, и это можно наблюдать. Заменил пузырьковую сортировку быстрой и это можно наблюдать. И даже тест сделать, который это отслеживает. Либо программа не делает ничего, либо результаты рефакторинга можно наблюдать.

PJ>>Изменил сигнатуру, делаешь что-то внутри с параметром, но тест про это вообще не в курсе. Замечательные тесты, да...
S>(facepalm). Простите, я уже расписал максимально подробно. Если вам непонятно, как именно рефакторинг взаимодействует с тестами — ну, попробуйте сами что ли.
Ну да, ты один кто пробовал тесты и понял весь дзен добавления параметра.

PJ>>Прелесть какая. Т.е. ты что-то зачем-то отдаешь клиентам, при этом ты даже не в курсе надо ли им это... А когда отдавать нечего, то просто начинаете врать выдавая фейковые данные...
S> Ну почему же фейковые — более-менее настоящие.
Угу, и чуть-чуть беременные.

S>Если задача появится — у нас есть способ её решения, который мы предложим.
Я верю в вас, генерировать очередные костыли отлично получается.

S>А вы как думали? Всеведение — опасная иллюзия. Наиболее хреновые решения в моей практике принимали люди, котрые полагали, что им всё-всё известно.
Ну да, то ли дело предположения... Наверняка принимать решения лучше всего на основе их.

S> Вы пока вообще ничего хорошего не предложили. Идея "добавить ещё один контракт" плохая настолько, что у меня нет слов, чтобы подобрать описание для этого.
Практически любой протокол умеет поддерживать возможность добавления второй версии контракта, без ломания первой. Это настолько плохая идея, но мужики не знают. Немедленно оповестите мир о вашей находке.
Предположения, фейковые данные и никогда не меняющаяся модель, потому что кто-то где-то предположительно ее использует, это свежее дыхание в индустрии.

S>Ну конечно же это проблемы дискового кэша. Вы что думаете, вы первые в мире, кто столкнулся с такой ситуацией?
Я написал, что я так думал? Или я просил помощи в решении где это?

S>Пока что вы ничего нового не рассказали. Ровно то же самое, чего я ожидал. Единственное — что решения, которые я себе представлял, опираются на упорядоченность записи. Если бывает так, что произведённая позже запись проходит, а произведённая раньше — нет, то придётся покумекать над решением подольше. Сходу ничего придумать не могу — все известные мне технологии восстановления построены на упорядочивании. Если диск ухитряется записать хвост журнала, но теряет его середину, то это сломает каждую из известных мне СУБД.
Да ладно, сообщение назад это же была задача для джуниора?!

S>Но это непринципиально: кто бы ни был виноват в потере данных, ОС или железо, при старте приложения мы наблюдаем одну и ту же картину — три типа файлов.
Два. Либо все хорошо, либо в (хотя бы в одном из них плохо) и тогда система откатывалась на дефолтное состояние. Никакой несогласованности там не было никогда.