TStream

← →
Suntechnic (2001-12-24 04:54) [8]

>Sour © (23.12.01 22:49)
>Сохранение чего-либо не большого, много меньшего 2 Gb, в файл, целесообразно реализация потоком?

Понимаешь в чём вся суть... написать можно чего угодно и как угодно... например структурный поход в программировании работает иногда даже быстрее ООП, но почему то все стараются его избежать... дело абсолютно не в размерах, дело в подходе. Если ты хочешь написать что то действительно гибкое и расширяемое то тебе надо мыслить именно этими мерками... Приведу тебе тогда другой пример использования потока, где размер не играет никакой роли.
Представь себе ты решаешь задачу обмена данными через сокеты(чат например). Имеется объект сообщение, который помимо текстовой информации может нести в себе ещё и ID отсылаемого и ID получателя, а также картинки и т.д. и т.п. На самом деле размер такого сообщения редко когда превысит 1Kb. Так вот один из подходов предполагает написание ф-ции которая будет принимать параметрами информацию о сокете и об объекте и посылать эту информацию адресату. Вроде всё красиво. Но завтра приходит заказчик и говорит я хочу эти сообщения ещё и в файл писать... а после завтра говорит я ещё хочу пересылать эти сообщения между процессами на одной машине... в итоге появляется 3 ф-ции: SendMessageToSocket, SaveMessageToFile, SendMessageToProcess в каждой из них будут происходить одни и те же действия: объект будет "раскладываться" по-байтно и отсылаться. А ещё через день придёт опять заказчик и скажет я хочу переслать ещё "пару байт" и ты вынужден будешь переписать все эти методы по отсылке(и столько же по приёму объекта)... Но возможно другое архитектурное решение. Где все необходимые "объекты передачи"(сокет, файл и т.д.) будут "уметь" работать с одним базовым объектом "Поток". Ведь всё равно всё придёт к необходимости отсылки цепочки байт. Поэтому пишем у нашего объекта "Message" два метода "SaveToStream", "LoadFromStream". Проще говоря объект сам знает как себя записать и как себя считать из потока. В результате если тебя кто-нибудь попросит пререслать ещё пару "лишних" байт ты просто переписываешь два метода "SaveToStream", "LoadFromStream" вместо 6. Более того ты можешь присвоить "версию" потоку. Грубо говоря один поток умеет пересылать картинки, а другой нет. И анализ опять же будет происходить в методах "SaveToStream", "LoadFromStream".

...вообщем много я тут наговорил. Повторяю ещё раз: написать можно и так и так. В результате конечный пользователь всё равно ничего не увидит :). Но дело в подходе. Если ты присмотришься поблжиже к VCL, она именно так и устроена и мне этот подход ближе, а ты сам выбирай...

TStream Найти похожие ветки