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.