hVosttЕвгенийВЧто тут то не так? Чем плох старина Stream?

Тем, что требуется вынужденно наследоваться от класса, ты не можешь просто взять и реализовать интерфейс IStream, тебе придётся как минимум реализовать лишний адаптер.

Чаще всего потоки используются только на чтение или только на запись, а клиентам теперь приходится лишний раз проверять Stream, умеет ли он то, что от него требуется (CanRead, CanWrite, CanSeek), вместо того, чтобы выяснить это ещё на стадии компиляции (IReadStream / IWriteStream / ISeekStream).

Зелено ещё. Так делать точно не надо.
Почитай "Entity interface anti-pattern".

Во первых - возвращаясь к теме топика "ИЧитатПоток" странное имя. Логичнее уж IInputStream/IOutputStream

Во вторых, продолжу "Архитектуру".
Добавим для примера "способность" асинхронного чтения: IAsyncReadStream, IAsyncWriteStream.
Теперь добавим для примера "способность" прерывать асинхронное чтение: IInterruptableStream.

Вот насоздавали кучу интерфайсов. Попробуем их использоват.
Пусть у нас метод, который получает как параметр поток, который одновременно IAsyncReadStream, IInterruptableStream, ISeekStream.
Описать его одним интерфейсом не получится. Значит создадим комбинации:
I[Random | Sequential][Async | Interruptable | Blocking] [Read | Write] Stream.

Теперь можно описать параметр метода одним интерфейсом IRandomInterruptableAsyncReadStream. Вспотел?

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

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

Но заметь, реализация у нас будет только одна FileStream.

hVosttmikronВо первых - возвращаясь к теме топика "ИЧитатПоток" странное имя. Логичнее уж IInputStream/IOutputStream

Логичнее, согласен, мне просто лень было набирать IReadableStream, так что придирка мимо.

vHost, скажи, как можно вести с тобой разумную полемику если ты просто из упёртости отрицаеш даже те аргументы с кототрыми сам соглашаешся?

Судя по твоим ответам ты не понял.


hVosttmikronЗначит создадим комбинации:
I[Random | Sequential][Async | Interruptable | Blocking] [Read | Write] Stream.

И в чём проблема оставить базовый класс Stream, наследующий все интерфейсы? И нашим и вашим. Такой подход активно практикуется Microsoft, посмотри на фильтры ASP.NET MVC.

Вот именно это и проблема "Entity interface anti-pattern". Куча интерфеийсов и только одна реализация.
Твой аргумент - ссылка на авторитеты говорит так-же против - МС не сделала ненужные интерфейсы.

hVosttНет, не вспотел. Серебряной пули не существует, но это не значит, что невозможно найти разумный компромисс.
mikronПроблема дизайна очевидна: создавая для каждого "свойства" свой интерфейс мы будем каждый раз умножать кол-во интерфейсов
Это не проблема, это расширяемость. Видеть в расширяемости проблему, это гениально.

Это не расширяемость а пустая трата ресурсов человеческих (на написание) и машинных (при выполнении).
Что даст специално для под кокнретный набор своиств заточенный интерфеис? Ведь всегда можно использовать надмножество.


hVosttmikronи при этом писать кучу "невыполняемого" бесполезного кода в угоду "архитектуре", при этом полностью теряя из вида что архитектура является не самоцелью а только методом.
Как раз таки наоборот. Если мне нужен поток только для чтения, я реализую такой поток, за каким хреном мне надо реализовывать +100500 доп. методов бросая NotImplementedException? Нахрена мне этот мусорный балласт?

Это экономически обоснованно:
В 99.99 % случаев потоки не преопределяются. И значит болшинство не тянет ненужный баласт в виде интерфейсов.
А в 0.01% случаев если потребуется реализовывать свой "поток" эти расходы приемлемы и оправданы.

hVosttmikronИрония так же в том, что в итоге мы всё это просто выкинем, просто потому что некоторые свойства которые мы описали интерфейсами динамические и зависят от времени выполнения. К примеру тот-же поток. Под одним и тем же путём может быть и файл и канал.
Если я принимаю поток только для чтения, мне всё равно что там, файл или канал, или ещё что-то. Главное чтобы он мог читать. Что мне даст во времени выполнения возможность файла ещё и писать, а канала только читать, если мне нужно только чтение изначально? Тут ты за уши притянул лишнего :)

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

hVosttЕвгенийВОграничение отписать легко, а вот кто и когда реализует TStream?

Реализует поставщик стримов. Реализует именно те интерфейсы, которые имеют смысл. Остальные нет.
Для чтения потока данных из сети, очевидно не будет Seek и Write.

Попробуй реализовать обычный фаил ма диске.
Какие интерфесы он будет реализовывать? И каие будут всегда работать?

Ещё раз: контрактами на этапе компиляции невозможно гарантировать доступность интерфейса время выполнения.

hVosttmikronТвой аргумент - ссылка на авторитеты говорит так-же против - МС не сделала ненужные интерфейсы.

Ничего подобного не наблюдаю, что бы подтверждало твой тезис.

Так посмотри же на класс Stream и FileStream.

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

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


Вот ты исползуеш FileStream как реализуюший класс. Никаких проверок в коде. Компилируется.
Но во время работы программы создаётс FileStream для пути по которому находится файл/пайп в кототрый можно только писать. Очевидно что весь код болле не рабочий и твой "архитектурные" испражнения ни к чему не видут. Нужна всё та же проверка в коде IsReadable.

hVosttmikronВот ты исползуеш FileStream как реализуюший класс. Никаких проверок в коде. Компилируется.
Но во время работы программы создаётс FileStream для пути по которому находится файл/пайп в кототрый можно только писать. Очевидно что весь код болле не рабочий и твой "архитектурные" испражнения ни к чему не видут. Нужна всё та же проверка в коде IsReadable.

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

В общем, пример никак не аргументирует и не защищает твою позицию.

откудого у тебя возникнет эксепшен? Может кто то всё-же будет делать проверки?

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

Значит всё-таки твой интерфейс ничего не гарантирует. Значит нет в нём ползы. Исползуй базовый класс Stream.

hVosttmikron,

Возьмём вот этот метод WebClient.OpenRead . Возвращает поток для чтения. Будешь проверять CanRead? Или сразу будешь читать? А если CanRead вернул false? А писать в поток будешь?
Ответ на твой вопрос не однозначен, но в обшем случае я не буду делать никаких проверок.
Это только подчёркивает что нет смысла плодить интерфейсы IReadStream. Базового класса Stream kak это делает МС достаточно.

hVosttЧаще всего потоки используются только на чтение или только на запись, а клиентам теперь приходится лишний раз проверять Stream, умеет ли он то, что от него требуется (CanRead, CanWrite, CanSeek), вместо того, чтобы выяснить это ещё на стадии компиляции (IReadStream / IWriteStream / ISeekStream).

Надеёсь мы прояснили, что на этапе компиляции этого нелзя выяснит?