Собственно классическая задача у нас есть некая информация ( например в простейшем случае это byte[], чуть немного более сложный — объект с полями )
и эту информацию нужно куда-то передать, возможно получив также в ответ некую информацию


Вырисовываются следюущие абстракции — SendData (информация которую отправляем), ResponseData ( информация которую получаем), DataReceiver ( куда отправляем и откуда получаем ответ )

public interface ISendData
{
}

public interface IReponseData
{
}

public interface IDataReceiver
{
   IResponseData Send( ISendData data );
}

Но не совсем понятно что есть ISendData и IResponseData, т.е. какие должны быть методы у них.

еще есть вариант отказаться от ISendData и IResponseData

public interface IDataReceiver
{
   object Send( object data );
}

или так ( но что-то в таком кейсе генерики интерфейсы мне не очень нравятся )

public interface IDataReceiver<SendDataType, ResponseDataType>
{
  ResponseDataType  Send( SendDataType data );
}

Здравствуйте, Аноним, Вы писали:

А>Собственно классическая задача у нас есть некая информация ( например в простейшем случае это byte[], чуть немного более сложный — объект с полями )
А>и эту информацию нужно куда-то передать, возможно получив также в ответ некую информацию.

Как всегда — начинаем с языка/фреймворка, затем описываем задачу на наборе типовых сценариев и под конец ищем готовые решения. Пока все три пункта не сделаны, обсуждать что-либо бессмысленно, т.к. под такие критерии подходит что угодно.

Например, для дотнета:
* wcf (если речь о передаче по сети/между процессами)
* stream (если нужен интерфейс для работы с потоком данных, в том числе и с устройств)
* любая из библиотек сериализации (тот же protobuf)
* события/IObservable (если речь о событиях в рамках процесса).

Выбирайте

Здравствуйте, Аноним, Вы писали:
А>

А>public interface IDataReceiver<SendDataType, ResponseDataType>
А>{
А>  ResponseDataType  Send( SendDataType data );
А>}
А>

Есть наверное один небольшой минус, это у вас IDataReciever одновременно знает и о сериализации объекта и о транспорте. Если рассуждать о сферических конях в вакууме, то это наверное не лучшее решение с точки зрения дизайна. Т.к. сериализацию объекта не протестить отдельно от DataReciever.
Озвучтье задачу.

Здравствуйте, Аноним, Вы писали:

А>Собственно классическая задача у нас есть некая информация ( например в простейшем случае это byte[], чуть немного более сложный — объект с полями )
А>и эту информацию нужно куда-то передать, возможно получив также в ответ некую информацию
Похоже на проектирование сферического коня в вакууме. Если точнее, то не существует классической задачи в такой формулировке — не хватает указания существенных ограничений:
1. Платформа?
2. Синхронная или асинхронная передача данных?
3. Структура передаваемых данных?
После того как определитесь с ограничениями, проведите сравнительный анализ уже существующих решений — скорее всего, вам не нужно проектировать интерфейс с нуля. В ходе анализа вы вспомните про те ограничения, о которых забыли вначале, и сможете лучше понять, что именно вам нужно. И только если существующие решения вам не подойдут, приступайте к проектированию чего-то своего. При этом отталкивайтесь в первую очередь от домена, а не от сферического передатчика вакуумных данных — обобщать нужно тогда, когда уже есть объектная модель и можно выделить сходство в интерфейсах.

Здравствуйте, Аноним, Вы писали:

А>Собственно классическая задача у нас есть некая информация ( например в простейшем случае это byte[], чуть немного более сложный — объект с полями )
А>и эту информацию нужно куда-то передать, возможно получив также в ответ некую информацию

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

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

S>Здравствуйте, Аноним, Вы писали:

А>>Собственно классическая задача у нас есть некая информация ( например в простейшем случае это byte[], чуть немного более сложный — объект с полями )
А>>и эту информацию нужно куда-то передать, возможно получив также в ответ некую информацию.

S>Как всегда — начинаем с языка/фреймворка, затем описываем задачу на наборе типовых сценариев и под конец ищем готовые решения. Пока все три пункта не сделаны, обсуждать что-либо бессмысленно, т.к. под такие критерии подходит что угодно.

Фреймворк можно уточнить .net, хотя не понятно чем аналогичное решение будет отличаться от java, c++ &mac||Linux.

Типовой сценарий — есть данные в каком-то виде, как я писал — это может быть строка, может массив байт, может объект, может стрим что еще можно нафантазировать ?
Есть что-то что умеет эти данные обрабатывать, это может быть сервер внешний ( rest, wcf, tcp/socket, http, smtp, в общем практически любая известная технология передачи данных ), это может быть даже СOM-объект или что-то иное что может принимать данные и что-то с ними делать.

Когда будет конкретный сценарий тогда и напишем реализацию например передача массива byte[] по stmp — это уже конкретика.
А наша задача — это не реализовать все все протоколы а только создать общий интерфейс, чтобы в перспективе в духе DI — можно было подменить протокол/тип данных ( примерно как это делается в wcf взял и одной настройкой http сменил на tcp ).

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



S>Например, для дотнета:
S>* wcf (если речь о передаче по сети/между процессами)
S>* stream (если нужен интерфейс для работы с потоком данных, в том числе и с устройств)
S>* любая из библиотек сериализации (тот же protobuf)
S>* события/IObservable (если речь о событиях в рамках процесса).

S>Выбирайте

Здравствуйте, Аноним, Вы писали:

А>Фреймворк можно уточнить .net, хотя не понятно чем аналогичное решение будет отличаться от java, c++ &mac||Linux.
Набором стандартных велосипедов

А>Типовой сценарий — есть данные в каком-то виде, как я писал — это может быть строка, может массив байт, может объект, может стрим что еще можно нафантазировать ?
А>Есть что-то что умеет эти данные обрабатывать, это может быть сервер внешний ( rest, wcf, tcp/socket, http, smtp, в общем практически любая известная технология передачи данных ), это может быть даже СOM-объект или что-то иное что может принимать данные и что-то с ними делать.

Я сильно сомневаюсь, что можно написать код, который спрячет за собой любой протокол и при этом будет проще в использовании, чем обычное API к этому протоколу. Особенно если нужны внезапные извраты вида "передать byte[] по stmp". Если нужно просто скрещивать ежа с ужом (перегонять из одного формата в другой), я бы смотрел на готовые решения,например на тот же BizTalk.

Пока задача выглядит как "изобрести всемогутор для произвольного набора проблем". Без конкретики всё что могу предложить — поискать фишки, которые реально нужны клиентам и на их основе построить реалистичные сценарии. Без сценариев слишком легко перезаложиться на архитектуру; получится монстр, который может почти всё, но ничего — хорошо Вам оно надо?