Здравствуйте, igna, Вы писали:
I>А чтобы не было лени по реализации специального класса?
Не изобретать велосипеды при разработке. А на поддержке не мучаться такими заоблачными проблемами, как создавать или не создавать пустые файлы. Вспоминая объемный список кейсов по системе, которую поддерживаем, ужасаюсь, какую дурную, оказывается, систему поддерживаю: вон-те, у людей самая ужасная бага в программе — создание пустых файлов, а у тебя, посмотри, какие болезни???!!!
Здравствуйте, rsn81, Вы писали:
R>А на поддержке не мучаться такими заоблачными проблемами, как создавать или не создавать пустые файлы.
Если ты прочитал пост, на который ответил, то знаешь, что что дело не в этом. Я баги пофиксил, поведения программы при этом не изменил, она как не создавала пустых файлов (точнее файлов только с заголовком и footer-ом), так и не создает. Но обратил внимание, что приведшие к появлению этих багов изменения программы, не привели бы к их появлению, если бы с самого начала не было решено предотвращать создание пустых файлов.
Здравствуйте, igna, Вы писали:
I>Мнение программиста: Если пустой файл никому не мешает, нечего и избыточную логику в программе городить.
Что за синематограф? Раз просят, значит — мешает.
А с файлом просто: создавать по первому запросу, закрывать по достижении некоего логического конца фазы работы. Ну, или в конце работы программы.
Что за спор?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Отлаживая это подумал, вот если бы с самого начала не пытались избежать создания файла с пустым содержанием, все добавления прошли бы как по маслу. Но оба мнения, которые я привел в первом посте (пользователя и программиста) мои; как пользователю пустые файлы мне тоже не нужны. Хотя отсутствие багов важнее.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Да. В этом конкретном случае возможно не стоило предпринимать даже минимальные усилия для того, чтобы избежать создания бессодержательного файла. Или обобщая, не стоит обрабатывать какой-то частный случай, если поведение программы для общего случая удовлетворительно.
, получается, нужно считать темой беседы?
I>Да. В этом конкретном случае возможно не стоило предпринимать даже минимальные усилия для того, чтобы избежать создания бессодержательного файла. Или обобщая, не стоит обрабатывать какой-то частный случай, если поведение программы для общего случая удовлетворительно.
Унутреннее противоречие. "Общий случай" — такого вообще не бывает в технике. Это философская абстракция, обобщение. Все случаи — конкретны и, следовательно, частны. Однако, вполне возможно, что для некоторого частного случая поведение программы не определено или определено не корректно.
Короче, это всё очень просто.
Введём несколько утверждений:
P — истина, когда работает программа.
D — истина, когда есть входной поток данных, преобразуемый в выходной файл.
W — истина, когда входные данные могут быть выведены в файл, т.е. процесс их обработки проходит (прошёл) успешно.
F — истина, когда появляется выходной файл.
P -> D (Запустили программу, можем принимать данные)
D -> W (Приняли данные, можем их обрабатывать)
W -> F (Обработали — выталкиваем в файл)
(1)
В точке (1): F = P & D & W. Это то, как обычно понимают процесс вывода программой некоторых данных: программа запущена (P), есть входные данные (D) и есть повод что-то в выходной файл записать (W).
У тебя получилось:
P -> F' (Запустили программу, создали "подготовленный файл")
F' -> D (Создали файл — готовы принять данные)
D -> W (Приняли данные, можем их обрабатывать)
W -> F'' (Обработали — выталкиваем в файл)
// А потом вам добавили ещё:
We -> F''' (We — конец обработки, F''' — завершающая последовательность)
F''' -> F (Наконец-то!)
То есть первоначальное выражение, описывающее процесс, усложнилось: F = P & F' & D & W & F'' & We & F'''.
И где здесь общий и частный случай? ИМХО, просто не стоило ставить телегу впереди лошади и писать заголовок до получения результата обработки первых порций данных. Как пить дать, выиграли один if. Зато влепили ограничение на структуру файла, это я о заголовке. Описание же того, как связывали запись footer с выводом "второй" последовательности, чтобы поправить положение дел, может служить почти классической иллюстрацией к тому, как не надо такие вещи делать.
Собственно, это я к чему? Если программа спроектирована без глупых допущений, перемешиваний выхлопной трубы и карданного вала и неуместных оптимизаций, то и вопросов, подобных твоему не возникает. Поэтому здесь надо не гадать относительно "общности" и "частности" случаев (подобными рассуждениями в таких ситуациях пущай манагеры балуются, всё равно не им программы писать), а просто исправить это хозяйство и всё. Что ты, судя по всему и сделал. И это и есть единственно правильный подход.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> ИМХО, просто не стоило ставить телегу впереди лошади и писать заголовок до получения результата обработки первых порций данных.
Не совсем так. Там данные уже были, просто вместо того чтобы написать:
if (!(первая_последовательность.Empty() && вторая_последовательность.Empty())) {
header.Write(stream);
первая_последовательность.Write(stream);
вторая_последовательность.Write(stream);
footer.Write(stream);
}
, а вывод header-а и footer-а засунули в методы Write первой и второй последовательности.
Почему сделали такое безобразие? Там были две как бы причины, во-первых на самом деле программа пишет несколько файлов, причем во всех остальных случаях только одну последовательность в файл, потому каждый Write свой файл сам и создает; во-вторых Write принимал file_name, а не stream, а Empty последовательностей вовсе отсутсвовали. У программиста в голове случилось то ли замыкание, то ли наоборот, и он нашел "простое решение".
Не хочу о(б)суждать то как это было сделано, написал, чтобы было ясно о чем идет речь.
ГВ>Собственно, это я к чему? Если программа спроектирована без глупых допущений, перемешиваний выхлопной трубы и карданного вала и неуместных оптимизаций, то и вопросов, подобных твоему не возникает.
Представим себе, что программа спроектирована правильно и запись в файл производит специальный класс, причем класс этот создает файл лишь в том случае, если есть данные для записи. Немаловероятно, что когда-либо в заголовок файла будет добавлена некая инфомация предназначенная для использования другой программой. Все будет работать нормально, пока последовательность как-нибудь не окажется пустой. Баг конечно пофиксят. Например добавлением в последовательность специального неким образом невидимого элемента. Паранойя? Но ведь нечто похожее уже случилось.
Здравствуйте, igna, Вы писали:
I>Ситуация: Функция/метод создает файл, пишет в него некий заголовок и передает его дескриптор или связанный с ним поток другим функциям/методам, которые тоже иногда пишут кое-что в этот файл. А иногда не пишут.
I>Запрос пользователя (change request): Если никакой информации кроме заголовка в файле нет, нечего и файл создавать.
I>Мнение программиста: Если пустой файл никому не мешает, нечего и избыточную логику в программе городить.
I>А вы что скажете?
А в чем проблема передавать другим ф-ия не дескриптор, а некоторый класс-обертку? Эта обертка будет отвечать за запись заголовока и footer.
Здравствуйте, darkker, Вы писали:
D>А в чем проблема передавать другим ф-ия не дескриптор, а некоторый класс-обертку? Эта обертка будет отвечать за запись заголовока и footer.
Согласен, так и нужно поступать, если действительно необходимо избежать создания "пустого" файла. Но я все больше склоняюсь к тому, что в данном случае этого делать не стоило (хотя открывая тему я был скорее другого мнения). Настоящей необходимости не было, было — скажем так — необоснованное желание пользователя, который сам же в конце концов и пострадал.
PS. Пользователь в данном случае не заказчик, программист и пользователь от заказчика равноудалены.
Раз просят, значит — мешает.
ИМХО, просто не стоило ставить телегу впереди лошади и писать заголовок до получения результата обработки первых порций данных. Как пить дать, выиграли один if. Зато влепили ограничение на структуру файла, это я о заголовке. Описание же того, как связывали запись footer с выводом "второй" последовательности, чтобы поправить положение дел, может служить почти классической иллюстрацией к тому, как не надо такие вещи делать.
