Предположим мы хотим реализовать некую фабрику классов, строим абстрактное "ядро":
class AbstractObject
{
public:
   virtual void Test() =0
};

class AbstractFactory
{
public:
   virtual AbstractObject CreateObject() const =0;  //какой тип вернуть?
};
и тут же натыкаемся проблему какой тип должен возвращать метод
virtual AbstractObject CreateObject() const
Варианты:
1. Объект AbstractObject вернуть нельзя, ибо он содержит абстрактный метод Test(), но даже если сделать пустую реализацию {} у него, то полиморфизм теряется
2. Ссылку AbstractObject& вернуть нельзя, ибо в конкретной реализации это будет ссылка на временный объект, что запрещено компилятором
3. Константная ссылка const AbstractObject&. Но тут же накладывается условие на константность методов результата Test() const. Не всегда приемлемо.
4. Единственно приемлемый вариант указатель: AbstractObject*. Минус этого подхода состоит в том, что мы обязаны самостоятельно следить за уничтожением объектов.
5. Альтернативный вариант. Создать обертку
class WrapObject
{
private:
   AbstractObject* object;
public:
   WrapObject(AbstractObject* obj)
   {
       object = obj;
   }
   ~WrapObject()
   {
       delete object;
   }
   void Test() const
   {
       object->Test();
   }
};
Соответственно реализация
class AbstractFactory
{
public:
   virtual WrapObject CreateObject() const =0;
};

Прошу комментировать, возможно я сильно заблуждаюсь

копай в сторону "чисто виртуальных" функций pure virtual func1().
Нужно сделать чисто виртуальный класс

(1) какой класс сделать чисто виртуальным?

(0) А что компилятор пишет при попытке вернуть тип объект?

(3) пишет, что нельзя, ибо тип содержит абстрактный метод
если метод сделать неабстрактным, то ошибок нет, но тип "обрезается" и полиморфизма нет

все разобрался, я заново "открыл" умные указатели ))

class WrapObject
{
private:
   AbstractObject* object;
public:
   WrapObject(AbstractObject* obj)
   {
       object = obj;
   }
   ~WrapObject()
   {
       delete object;
   }
   AbstractObject* operator->()
   {
       return object;
   }
};

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

+6 Объяснить нужно почему вредный?

(6) да задача просто несколько другая, если б нужен был бы именно он, то взял бы готовый

(4) Для реализации полимормфизма класс не обязан быть абстрактным. Виртуальных функций достаточно.

(9) да, но полиморфизм теряется, если присваивать именно объекты

(10)Возвращайся ссылку на объект.

(11) посмотри внимательно (0), там описаны различные варианты и дальнейшее их развитие

Полиморфизм работает на указателях + виртуальность.

(13) на ссылках оно тоже работает, только ссылки ограниченны, как видим, в использовании

virtual void Test() {} решит твою проблему.

(14)ээ, создание объекта CreateObject в куче и возврат на него константной ссылки??

+16 ну и в догонку: спорить влом - указатели только.

(15) не решит, я писал почему
(17) здесь да, но надо следит за их уничтожением

(18)всегда указатели для работы полиморфизма.

class AbstractObject
{
public:
  virtual void Test() =0
};

class AbstractFactory
{
public:
  virtual AbstractObject& CreateObject() const =0;  
};

+ Возврат ссылки не обязательно означает возврат временного объекта.

(20) ты пробовал это компилировать?

(21)ты реализацию CreateObject покажи тогда.

AbstractObject& RealFactory::CreateObject()const
{
RealObject* probj = new RealObject;
return *probj;
}

(22) Да, компилируется. Стандарту С++ соответствует.

(24)горцев рождаем чтоли? :)

(26) Поясни свою мысль.

(27) кто его уничтожит то? пока вижу никто

(28) Когда ты вдоволь наиграешься с объектом, вызовешь  delete &pRealObj;

(29) спасибо, тогда лучше указатели

(30) На самом деле, разница невелика. В любом случае, если твоя фабрика создаёт полиморфные объекты, которые будут использоваться вне функции, вызвавшей фабрику, тебе нужно будет или самому заботиться о времени их жизни, или использовать умные указатели (например, shared_ptr из boost).

(27)ну мысль уже пояснили и тему раскрыли.

Все-таки полиморфизм, я думаю, ТС подразумевался в таком виде:

class A {}; // подразумеваем виртуальный деструктор
class B : public A {};

A* a = new B;

(32) ТС, я думаю, хотел определить обобщённую стратегию создания объектов достаточно произвольного вида и манипулирования ими, для чего ему и понадобились абстрактные классы фабрик и объектов. Поскольку классы абстрактные,  то создать объекты этих классов невозможно, им можно только наследовать. Это - часть формального определения системы, создаваемой ТС.
Полиморфизм возникает как естественное следствие различной реализации классов-потомков (реальных фабрик и объектов) при единой спецификации наследуемых  интерфейсов базовых (абстрактных в данном случае) классов. При этом, говоря вообще, без виртуальных функций получаем статический полиморфизм.
Ссылка обозначает объект, на который она ссылается, а следовательно имеет в этом отношении семантику указателя. Более того, их реализация и представляет собой указатель.

А вот кто такие "горцы", которых зачем-то кто-то собирается "рождать", мне не понятно :)