Имею 2 варианта, оба работают. 

В первом, у меня есть класс UDPClient, в котором реализована работа с winsock, и есть класс прикладного протокола на базе UDPClient.
Второй вариант имеет расширенную объектную модель, на схеме. Он более наглядный на мой взгляд, но тут больше писанины при том же результате, зато если понадобится что-то изменить достаточно просто добавить нужные методы в нужный класс.
Хочу критику по двум направлением - объектная модель и её реализация в виде наследования а не включения. 

Например, есть ли смысл включить CSocket в CWinSocket вместо наслеования?

Если я создаю несколько экземпляров класса, каждый из которых запустит WSAStartup() это нормально? А если потом один экземпляр отработает и будет уничтожен (деструктор вызовет WSACleanup()), то повлияет ли это на работу другого экземпляра?

Создай класс, который в конструкторе делает WSAStartup, а в деструктор - WSACleanup. Реализуй его, например singleton'ом или статическим экземпляром (лучше и то и другое вместе). Дальше интерфейс для всех клиентов, от него наследуешься (реализуешь) клиенты UDP, TCP, Bluetooth,....

Добавлено через 1 минуту и 26 секунд
Потом можно использовать полиморфный указатель на базовый клиент, не заботясь о протоколе передачи

У меня это делает CWinSocket, значит его делать одиночкой, а Socket сделать его потомком? я в паттернах пока не разбираюсь, читаю потихоньку книгу "паттерны проектирования", так что не уверен что понял что имелось в виду

или например сделать класс CWinSockInit синглетоном, он будет инициализировать Winsock конструктором, убирать мусор деструктором, а от него потомком CSocket <- CUDPClient <-C<прикладной протокол>Client?

Это сообщение отредактировал(а) Apel - 21.11.2010, 20:39

от CWinSocket никаких потомков, он просто создаётся в начале программы и уничтожается в конце. Только обеспечивает инициализацию винсокетов.

Сделал синглетоном по книге, рботает. В связи с этим есть вопрос и идея. 

Вопрос, если объект должен существовать от начала и до конца работы программы, то уничтожится он автоматически при завершении? 


А если сделать так, чтобы CWinsockInit считал число вызовов своего конструктора, а при вызове деструктора учитывал бы это. Тогда можно добавить инициализацию винсокетов в CWinSocket (включением) и не надо будет специально делать инициализацию и деинициализацию winsock2.

Это сообщение отредактировал(а) Apel - 22.11.2010, 17:59

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


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