Собственно есть некоторое устройство, через которое передаются данны(само устройство тоже принемает данные).
Хотелось бы иметь следующую возможность.

SomeDevice device;

Sender  *sender = device.MakeSender(SomeID);

send->send(data);

Класс Sender можно создавать только в SomeDevice.

Пока как вариант вижу сделать у Sender приватный конструктор, а SomeDevice сделать дружественным к Sender, тоже надо делать дружественным и SomeDevice так-как нужен доступ из Sender к приватным полям.

Или вот такое использование

device.SendTo(SomeID)->send(data); Только вот это сделать.

Да и device.SendTo(SomeID,data) неподходит, так как у Sender и SomeDevice будет много функции(некоторые будут похожи) и будет просто свалка всего в одном классе.

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

virtual уже отменили?

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

UA>Здравствуйте, a1ien.n3t, Вы писали:

UA>virtual уже отменили?

И чем нам тут это поможет. Нам надо грубо говоря разделить один класс на 2 притом чтобы возможности доступа ко второму была через первый(Либо путем создания, либо еще как-нибудь).

Здравствуйте, a1ien.n3t, Вы писали:
AN>Собственно есть некоторое устройство, через которое передаются данны(само устройство тоже принемает данные).
AN>Хотелось бы иметь следующую возможность.
AN>

AN>SomeDevice device;
AN>Sender  *sender = device.MakeSender(SomeID);
send->>send(data);
AN>

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

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

Чем обычная фабрика не подходит? Сделай Sender абстрактным (ака интерфейсом). Соответственно SomeDevice создаст какую-то SenderImpl скрытую в его недрах.

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

AN>И чем нам тут это поможет. Нам надо грубо говоря разделить один класс на 2 притом чтобы возможности доступа ко второму была через первый(Либо путем создания, либо еще как-нибудь).
Зачем делить? Возвращай базовый который имеет virtual send

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

AN>Пока как вариант вижу сделать у Sender приватный конструктор, а SomeDevice сделать дружественным к Sender, тоже надо делать дружественным и SomeDevice так-как нужен доступ из Sender к приватным полям.
Сделать Sender чистым интерфейсом и реализовывать его в SomeDevice. Мотивация: слишком сильная связанность Sender и SomeDevice. Если не хочешь делать интерфейс открытым, то можно использовать подход "грань", сделать интерфейс защищённым и определить оператор преобразования, хотя толку от такого в жанном случаее мало.
Ну а вообще, попробуй просто разобраться что должен делать/хранить sender, а что some device. Может стоит подумать про использование потоков ввода/вывода из stl.

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

AN>Собственно есть некоторое устройство, через которое передаются данны(само устройство тоже принемает данные).
AN>Хотелось бы иметь следующую возможность.

[код убран]

Я бы перед реализацией подумал сначала об архитектуре: кто за что отвечает и как объекты взаимодействуют между собой. Обычно взаимодействие с устройствами идет по некоторому протоколу, в режиме запрос-ответ.

Из собственного опыта могу посоветовать такую схему:

• Device — класс устройства, может быть базовым абстрактным для разных типов устройств (если придется работать с разными типами или модификациями устройства)
  
• Protocol — протокол обмена с устройством, какие команды может выполнить устройство (например чтение/запись данных). Бывает что устройство поддерживает разные протоколы.
  
• Communication Link — канал обмена с устройством по некоторому протоколу, например последовательный порт, или TCP сокет.

Пример взаимодействия:

typedef std::vector<unsigned char> buffer;

class Link
{
public:
    virtual ~Link() {}
    virtual buffer read_bytes() = 0;
    virtual void write_bytes(buffer const& bytes) = 0;
};

class Protocol
{
public:
   explicit Protocol(Link& link) : link_(link) {}

   unsigned read_register(unsigned number);

   void read_memory(unsigned mem_address, void* buffer, size_t size);
   {
        buffer request = make_read_request(mem_address);
        link_.write_bytes(request);
        buffer response = link.read_bytes();
        //decode response, put payload in buffer
   }

   void write_memory(unsigned device_address, buffer const& buf);

private:
   Link& link_;
};

class Device
{
public:
   explicit Device(Protocol& protocol) : protocol_(protocol) {}

   void send_value(float v)
   {
       protocol_.write_memory(0x123, v);
   }

   std::vector<char> recieve_status()
   {
      size_t status_size = protocol_.read_register(STATUS_SIZE_REGISTER);
      std::vector<char> status(status_size);
      protocol_.read_memory(STATUS_DATA, status);
   }
};

std::unique_ptr<Link> link = make_serial_link("COM1", 38400, ONE_STOP_BIT, NO_PARITY);
//std::unique_ptr<Link> link = make_tcp_link("192.168.0.99");

Protocol protocol(*link); // тоже может создаваться фабрикой
Device device(protocol);

device.send_value(0.5);
device.recieve_status();

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

K>Здравствуйте, a1ien.n3t, Вы писали:

AN>>Пока как вариант вижу сделать у Sender приватный конструктор, а SomeDevice сделать дружественным к Sender, тоже надо делать дружественным и SomeDevice так-как нужен доступ из Sender к приватным полям.
K>Сделать Sender чистым интерфейсом и реализовывать его в SomeDevice. Мотивация: слишком сильная связанность Sender и SomeDevice. Если не хочешь делать интерфейс открытым, то можно использовать подход "грань", сделать интерфейс ...

ММ идея неплохая спасибо.

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

AN>ММ идея неплохая спасибо.
Взята из книги Джеффа Элджера "C++ For Real Programmers" если что.