> Дяденька, а зачем вы диспатчите типы через enum, как будто у вас
> algebraic data types вместо классов?

Я вообще не понял вашего словосочетания. Что значит, что я диспатчу? enum - это как раз реализация через их перечисление в switch {case..}?
А как правильней?  

> А это вам как зайдёт, вот вы изобрели в пхп типы данных
> из хаскеля - осваивайте, укладывая мысль в них.

С хаскелем не знаком кроме как слышал название этого языка. Можете пожалуйста пояснить, что я изобрёл и во что мне надо укладывать мысль?

> А это вам как зайдёт, вот вы изобрели в пхп типы данных
> из хаскеля - осваивайте, укладывая мысль в них.

С хаскелем не знаком кроме как слышал название этого языка. Можете пожалуйста пояснить, что я изобрёл и во что мне надо укладывать мысль?

> сделай обычный class Document. От него наследуются class Dogovor и class Pismo
> (еще обзови их class DoroBop и class nuCbMo, раз так фанатеешь
> от русских названий - сарказм на всякий случай). Класс Document при
> этом не должен знать о существовании своих подклассов и никак их
> не упоминать. Далее создай в совершенно отдельном месте функцию, которая принимает
> $typeFromDb и делает по нему return new КонкретныйКласс, можно через switch.

Если что, на самом деле эти Документы, Договора и Письма - чистая выдумка для иллюстрации. С моей текущей задачей конкретно такие сущности никак не связаны.

По поводу организации функцией, а не в родительском классе - в чём у такого подхода принципиальная выгода или "правильность"?

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

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

Есть такая сущность, как Статья. Это сущность из которой будет формироваться условно страница с самой этой Статьёй:

//Отображение её в БД
TABLE Article (
    id     SERIAL PRIMARY KEY,
    title  CHAR(20) NOT NULL
)

Статья состоит из кусков разных типов объектов - Частей Статьи.

//Отображение Частей Статьи в БД
TABLE ArticleParts (
    id     SERIAL PRIMARY KEY,
 artID     BIGINT UNSIGNED NOT NULL,
partType   TINYINT UNSIGNED NOT NULL,
partOrder  TINYINT UNSIGNED NOT NULL,
    FK(artID) => Article(id)
)

Так вот поле partType - это как раз тот самый objTypeID по которому мы понимаем Часть Статьи какого типа это:

//Общий предок Частей Статьи
Class ArticlePart {
    const PART_TEXT;        //Чисто текстовый блок
    const PART_IMG_GALLERY; //Набор картинок в блоке
    const PAT_POLL;         //Блок с голосованием
    .......
    //Получить объект нужного типа
    static public & getPartObjByType($objType){
        $objItem = false;
        switch($objType){
             case ...:
                 $objItem = ....;
                 break;
             .... ......
        }
    }
}
//Классы самих Частей Статьи
Class ArticlePart_TEXT extends ArticlePart {
    static const OBJ_TYPE = ArticlePart::PART_TEXT;
    //У каждого вида Части Статьи свой способ оформления в БД, 
    //со своими таблицами и связями и пр.
    public function DB_Save(){
        .....
    }
    //Тут к примеру у каждого вида Части Статьи своя генерация HTML под него
    public function getHTML(){
        .....
    }
}

И условно статью предполагается создавать из таких вот блоков разных типов. Они могут быть интерактивными, каждый из блоков, со своей связанной с пользователем информацией и пр.
А уже как у статьи в общем может быть там пагинация и прочая херня. Короче велосипед, но мой и хочу чтобы колёса сразу квадратными не выбирались :)

> Надо не играть в бабу Вангу и чётко спросить:
>>Я тут пишу свои всякие поделки
> В чём смысол поделки, самопальная ORM?

Нет, смысл самой поделки не ORM, смысл того что я спрашиваю - некое подобие ORM, но оно не самоцель, а лишь часть в моей общей замути. Спрашиваю, чтобы на этапе пока не накодил много объектов выбранным (и опробованным) способом который в вопросе и описал, и не пришлось потом всё перелопачивать из-за того, что выбранный способ унылый.