la prog objet tel qu'on peut la voir par cet exemple :
class user{....}
class user_type1 extends user{....}
class user_type2 extends user{....}
 
 
lorsque l'on fiat de l'heritage de classe, il s'agit simplement de definir un type "plus precis" d'objet. -> peut ont passer d'une instance User à une instance User_type1
 
ex:
si je veux pour un site, fiare une class user et des methode pour valider ou non une identification :
 
U = new user()
...
if( U->IsValid( $login, $password )
{  
   /* login valide */
   if( U->GetType() == type_1 )
   {
     //comment faire a ce niveau pour transformer U en une
     //instance de la classe : user_type1 ?????
   }
   else if( U->GetType() == type_2 )
   {
     
   }
}
 
 
 
 

non. m'est avis que tu te poses les mauvaises questions ... tu veux faire quoi en fait ?

un login pour des "user",
 
on identifie le "user"
et suivant son type, on veut pouvoir acceder à des pptes/methode + spécifique. (enfin on veut le representer par un objet plus précis)
 
ex:
on a un login commun a toutes les catégories, donc on peut identifer : soit un membre normal, soit un admin.  
une fois que la personne est identifée, on veut qu'elle ait des pptés en +.

ok. alors pourquoi vouloir créer l'objet user ? tu pourrais avoir un objet admin auquel tu passes le login & le password. cet objet regarde les permissions de l'utilisateur & ressort soit un user_type1 soit un user_type2.
 
ou tu peux avoir un autre objet dans user, userActions. si c'est un utilisateur standard, l'objet instancié est un stdUserActions (extends userActions), si c'est un modo, l'objet instancié est un modoActions.  
 
bref, t'as le choix. mais dans tous les cas, faut séparer. dans ton cas, un user ne devrait pas pouvoir checker s'il est valide et ensuite qu'un code extérieur (ton if) décide de le changer ...

euh, je comprends pas tout, donc j'ai du bien m'exprimer :
 
voila, comment j'ai posé le pb :
 
la class la plus général c'est user:
(dedans, y a mot de pass/login/nom/prenom/etc...+ un type(admin,norma, type1,type2..))
 
la methode d identification se trouve donc aussi dans la class "user",
et quand je check au login, je cree un user avec le login/pass que j'ai recu du formulaire(user= new User(login, password)) , si c est ok  ( user->IsValid() ), alors je regarde le type de l'user et la je peux lui associé les ptté + précise (ex: admin aura une methode admin->DeleteAllUser()  -au hasard- )
 

donc c est a ce niveau la, que j'ai pu besoin de l objet user du debut, mais au contraire d 'un objet + grand
comme admin, normal, type1, type2
 
(avec class admin extends user{} et pareil pour les autres)

en utilisant "admin", je voulais dire "administratION", pas administrateur.
 
>> class admin extends user
 
donc non. admin ne dériverait de rien du tout. tu lui passes un login et un password (admin->getUser("jojo", "eI4Rf8" ); ) elle teste si l'utilisateur existe, si non elle renvoit null. si oui, elle teste ses permissions. utilisateur standard : return new user_type1, modo : return new user_type2.  
 
par exemple.
 
l'objet ce n'est pas tout dériver d'une classe de base. une classe admin me semble le moyen le + simple de régler ton problème de "transformation d'user" : un objet qui contrôle la création.
 
mais avec les 10 petites lignes que tu montres, ça peut aussi s'avérer complètement faux.
 
pour résumer :  
* sépare  
* ne cherche pas à dériver à tout prix

oky, sauf que dans la class "administration" il n'y aurait aucune "propriété" en plus, donc autant faire la fonction de login (retourne un objet) dans la class user.