терминология!

есть чисто виртуальные методы (pure virtual method).

есть абстрактные классы.

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

Это сообщение отредактировал(а) blackofe - 19.1.2006, 20:08

что-то не совсем понял

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

STL вообще не предназначена для того, чтобы на ее основе строить свои иерархии. большей частью это инструментальная библиотека. организовать коллекцию своих объектов, воспользоваться эффективным алгоритмом, использовать удобные типы данных вроде строк и потоков - вот основные ее назначения. но STL - не объектно-ориентированная библиотека! читайте форум.

Примерно так

А вообще, если для одного класса требуется доступ к приватным членов двух другиз классов, я бы задумался над правильностью дизайна
Добавлено @ 12:29

ООП зиждится на понятиях класса и объекта, а также трех основных парадигмах - наследование, инкапсуляция, полиморфизм. В STL есть классы, на основе которых создаются объекты, есть наследование и инкапсуляция. Неужели только из-за того, что там не использованы виртуальные деструкторы, Вы отказываете ей в объектно-ориентированности?

А также есть статический полиморфизм ...

во-первых, отказываю не только я. я уже приводил ссылки на этом форуме по этому поводу. ищите и обрящете.

а если в библиотеке используются слова class и конструкции типа class A : public B {};, то это еще не делает эту библиотеку объектно-ориентированной.

цитата из dr.dobb's journal за 1995 год:

While the STL is powerful, it has its limitations, the biggest being that it is not very object oriented. Object orientation depends on data and algorithms being combined under one interface. The whole premise of the STL is at odds with this: The STL separates data and algorithms, allowing their recombination in novel and useful ways.

краткий перевод:

"STL - это круто, но не объектно-ориентировано. и хотя это не объектно-ориентировано, это все-равно круто."

если вы подписаны на ddj, то там (мартовский номер 1995 года) можно найти статью - интервью с александром степановым ("Alexander Stepanov and STL"). в ней степанов если не противопоставляет stl объектно-ориентированному программированию, то, по крайней мере, четко разделяет.

STL is an important addition to the evolution of Standard C++, not only for the rich library of container classes that it provides, but also for its insight into "generic programming," a different approach to designing and developing code.

сам степанов вот чего говорит:

Object-oriented programming aficionados think that everything is an object. When I was working on the Ada generic library, I realized that this wasn't so. There are things that are objects: Things that have state and change their state are objects. And then there are things that are not objects. A binary search is not an object. It is an algorithm. Moreover, I realized that by decomposing the component space into several orthogonal dimensions, we can reduce the number of components, and, more importantly, we can provide a conceptual framework of how to design things.

так что STL - это красиво, эффективно, но не объектно-ориентировано в строгом смысле этого слова.

За 10 лет, прошедших с 1995 года представление об ООП тоже весьма изменилось.
Например, в одной из своих книг Мейерс показывает, что в интерфейс класса входят не только его методы, но и внешние функции, предоставляющие дополнительный сервис и определенные в некотором смысле "рядом" с этим классом. В этом смысле STL можно считать библиотекой контейнеров, снабженную дополнительными сервисами в виде алгоритмов.

И где в цитате Степанова написано, что STL - не объектно-ориентированная? Там написано, что она не только объектно-ориентированная. И что generic programming - методология, которая позволяет учлучшить чистую ООП-архитектуру.
Кроме того, именно STL стирает разницу между функциями и объектами: функтор - он тебе и объект и функция одновременно. Я бы сказала, что STL пропагандирует еще большую инкапсуляцию, чем принципы раннего ООП.

Но в одном ты прав: использование слова class и наследования не делает код объектно-ориентированным. Только это не про STL.

Тупик...

Я не знаю как быть.
Мой класс имеет вектор объектов, которые имеют собственные очереди и в собственных потока заполняют их.

Изначально я хотел передовать в этот класс, класс, который будет заниматься обработкой.
Но это приводит к усилению связей и раздутию класса

Нужен опытный совет

1. Можно в основном классе все очериди слить в одну (не приведет ли это к издержкам и замедлению работы - скорости довольно большие)
2. можно не передовать класс обработки, но тогда нужен будет интерфейс к каждому внутреннему объекту, что не хотелось бы делать из-за неуниверсальности


Как лучше и правильнее поступить ?