Perso j'aime pas. Si un objet ne peut même pas être initialisé tel que l'utilisateur le désire ou si un composant qui lui est nécessaire subit le même sort, alors l'objet n'a pas de raison d'être "vivant" puisqu'il est dans un état incohérent ou "bidouillé" (p.ex. rectangle de 0x0).
Pour une raison de clarté, j'aime bien que les objets aient une seule fonction durant leur vie. On crée l'objet pour une tâche, on la fait et on détruit l'objet. Si on en a besoin à nouveau on le recrée. Le modèle du C++ permet par ailleurs de faire ça sans pénalité de performance au contraire de certains langages obligeant l'allocation sur le heap (Objective C) ou dans une moindre mesure pour les langages avec ramasse-miettes comme Java.
Bon après tout dépend du cas. Par exemple j'ai fait récemment une API graphique pour un petit jeu qu'on fait dans un cours, et on peut prendre 2 cas qui illustrent la scission.
Premièrement un rectangle (héritant de GLComponent, mettant à disposition les méthodes Move, Draw, etc.):

// La construction ne peut pas échouer; par défaut tout composant est unitaire,
// placé à (0, 0), blanc, de centre (0, 0) etc. donc l'état initial est connu et
// cohérent pour l'utilisateur
GLRectangle rect = new GLRectangle();
rect.Move(10, 10).Size(20, 20).Rotate(30).Draw();

Mais pour une image par exemple on a une relation de composition* avec GLTexture, représentant l'image chargée, relation qui est très lourde d'implications:

// La construction *peut* échouer (exception) car une image sans texture
// n'en est pas une...
GLImage img = new GLImage("test.png");
img.SetColor(Color.Green).Draw();

(* en réalité c'est une agrégation dans ma modélisation, mais dans ce petit exemple pas besoin de s'embêter avec ça)