C++ проектирование

Почитай про паттерны проектирования в OOP, Александреску еще, Thinking in C++ Брюса Эккеля можно почитать.

учиться и еще раз учиться!

>В книжках такого не описывается.

Ну это ты загнул конечно.
Могу порекомендовать книги по C++ из серии "In Depth" (Александреску, 
Саттер и многие другие ответственные товарищи)

Если говорить про С++, то посмотри еще на книги Майерса, Джосаттиса, 
Вандевурда, Дьюхэрста.

Также классики - Буч, Страуструп, Фаулер, Мартин (тоже Must Have).

Не говоря уже про Design Patterns by GoF.
По паттернам есть еще книги Влиссидеса, Тротта, Фаулера.

Все это у меня есть в электронном виде (правда искать надо).
Если есть необходимость - могу выслать на мыло.
Но не обещаю, что скоро.

1. Андрей Александреску
Современное проектирование на С++: Обобщенное программирование и прикладные шаблоны проектирования

http://www.ozon.ru/context/detail/id/1224782/

2. Герб Саттер, Андрей Александреску
Стандарты программирования на С++

http://www.ozon.ru/context/detail/id/2381848/

3. Герб Саттер
Решение сложных задач на С++

http://www.ozon.ru/context/detail/id/1273200/

4. Герб Саттер
Новые сложные задачи на C++

http://www.ozon.ru/context/detail/id/2342923/

у меня все эти книжки что рекомендует Reset есть
только их и читаю
но всеравно не получается :(
Неужели так много усилий нужно :(

Практика нужна. Возьми какой-нибудь небольшой opensource C++ проект и попробуй разобраться хотя бы частично и приписать какую-нибудь фичу.

фитчи приписываю с пол пинка, а чтоб с нуля, вот тут я погибаю :)

>C++ проектирование

>У меня ну не получается.

Может просто s/С++/{C + здравый смысл}

>Все получается легко если делать статические члены в классах.

>Так же легко получается если есть глобальные обьекты.

>А тоже самое сделать в динамике и без глобальных обьектов не получается спроектировать.

Извинясь за глупость, но почему не катит

struct global_context_t { глобальные и статические объекты }

а вместо

do_someething()

прописать do_something(struct global_context_t *g);

А что хоть за задача?

>фитчи приписываю с пол пинка, а чтоб с нуля, вот тут я погибаю :)

Блин ну ты даешь! Хочу того не знаю чего :) Все получается, но что то не получается, а что именно не получается понять тоже не получается :)

> Все получается легко если делать статические члены в классах. > Так же легко получается если есть глобальные обьекты. > А тоже самое сделать в динамике и без глобальных обьектов не получается спроектировать.

А динамика нужна? Чем плохи статические члены классов?

Конкретно вводит в тупик:
Если есть класс наподобии такого:

class Type
{
public:
static Type * New() {Type * i = new Type(); i->instance = i; return i;}
static Type * Instance() {return instance};
private:
static Type * instance;
/* hide constructor and ... */
Type();
Type(Type &);
Type & operator=(const Type &);
};

Объект такого класса создается один раз. И его нет необходимости передавать через параметры другим функциям.

Можно в любой момент времени получить доступ к обьекту через Type::Instance();

Все приложение написано с учетом этого :) Например клиент связан так с сервером. Я хочу переделать чтоб клиент одновременно мог быть связан с несколькими серверами (типа закладок в Firefox).
Тогда объект соединения, который был раньше в одном екземпляре, приходится передавать как параметр всем другим объектам.

> Тогда объект соединения, который был раньше в одном екземпляре, приходится передавать как параметр всем другим объектам.

Или сделать полем нужных объектов. Или сделать ассоциативный массив, и вместо Type::Instance() вызывать get_connection_for(objptr). Да много чего можно придумать...

Только это всё - не проектирование :-P

>приходится передавать как параметр всем другим объектам. 

А что хочется взамен ?  
Может наоборот, например в него пихать ?
Может задачка выше спроектирована не так как хочется ?

> Я хочу переделать

Это уже рафакторинг.

> Тогда объект соединения, который был раньше в одном екземпляре, приходится передавать как параметр всем другим объектам.

Ну вот, ты сам определил, что должно получиться в результате. Клавиатуру в руки и вперед!

В чём проблема-то?

Watashiwa_deredeska! а если таких Singleton классов было раньше больше десятка ?

- Можно использовать виртуальное наследование.
 Тогда создаваемые классы будут использовать только
 одну копию базового.
- Можно использовать шаблоны.
 Нужный класс передается как тип и создаваемый
 настраивается. Можно извратиться сложными шаблонами.
- Можно передавать как указатель(ссылку) в 
 конструкторе, при этом использовать счетчик ссылок.
- Можно использовать встраивание - выделение 
 дополнительной памяти при создании нового класса.
- Можно запустить в отдельном потоке, процессе.
 Взаимодействие осуществлять с помощью межпроцессного
 взаимодействия.
- Можно забить болт.
 Придет время руководство начнет новый проект.

В долгоиграющих разрастающихся проектах имеющих
тенденцию к сопровождению разными людьми,
глобальные и статические объекты в проекте - 
 потенциальная смерть проекта. 
Да и не удобно их отслеживать.
Связи должны быть слабые. Если конечно не стоит 
задача производительности.
Глубокое наследование то-же не есть хорошо.
В общем все это написано в 2-3 перечисленных книжках.
Править чужой большой проект - сложная задача.
Ваша боязнь и паника - это нормально.
Нормально и то что Вы легко правите код и боитесь
писать с нуля.
В этом и есть отличие разработчика с нуля от
программиста разработчика по готовому коду.
Разработчик с нуля и должен бояться. 
Просто никто никогда Вам об этом не скажет.

Совет: хотите писать с нуля, начните с понимания
того что хотите, нарисуйте картинки, связи между ними,
выделите общее то, что пойдет в библиотеки,
Не мешало бы подумать о рашриряемости и о
масштабируемости Вашего проекта, легкости 
сопровождения другими людьми через несколько лет.
Выбрать технологию, библиотеки, статические, 
динамические, загружаемые, взаимодействие между 
модулями, процессами, нитями. Понять где разделяемые
объекты, какие блокировки и как много, синхронизация,
лог-файлы. 
Если система большая, разбить на подсистемы. 
Научить их взаимодействоать. Все это на бумаге. 
Или с помощью средств проектирования UML+софт.
И уж после понимания и представления начинать 
кодировать Ваши идеи. 
Имеет смысл почитать о нисходящем и восходящем 
проектировании.
Составить ТЗ на весь проект - описать задачи.
Составить ТЗ на каждую подзадачу.
Реализовывать строго в соответствии с ТЗ.
Постепенно расширяя ТЗ.
При разрабоке с нуля проект должен работать сразу,
собираться и работать. 
Правда за один день - это будет функция main() не
 больше, но ведь с чего-то нужно начинать. :)
Постепенно расширять и добавлять функционал.
Расширять ТЗ, ставя или углубляя задачи.
Прорабатывать модули.
Не ставить перед собой больших задачь.
Ваша система должна быть маленькой, и обязательно
 работающей - пилотный проект. 
В её архитектуру должны быть заложены основные
принципы, и возможности.
Часть модулей будут просто заглушками.
Все это конечно Вы и сами знаете, это так для
 того, чтобы Вам было не скучно одному.
Забыл про протоколы, стараться придеоживаться 
стандартов, но и не бояться самому думать.