Ridenominazione del metodo con nome lungo in C # [chiuso]

Mi aspetto che questo metodo richiami altri tre metodi:

public string ValidateNewPasswordExpireCurrentPasswordAndCreateNewPassword(string password)
{
    AccountManager.ValidatePassword(password);
    AccountManager.ExpirePasswordForAccount(this.CurrentAccount);
    AccountManager.AssignPasswordToAccount(this.CurrentAccount, password);
}

Quando un metodo aggrega cose diverse, è fatto perché:

1. O è troppo ingombrante chiamare queste cose diverse in ordine ogni volta che ne hai bisogno , ovvero il chiamante non vuole ricordare che la password deve essere convalidata, quindi la vecchia dovrebbe essere scaduta e solo allora dovrebbe essere assegnato il nuovo.

   Probabilmente il chiamante deve sapere cosa sta succedendo sotto il cofano, poiché lo stesso chiamante può chiamare separatamente questi tre metodi. Puoi provare ad abbreviare il nome del metodo, ma non troppo: purtroppo, devi comunque essere molto specifico e dettagliato.

   Puoi anche spostare il suggerimento che la password sia convalidata sull'argomento della password stesso.

   public string ExpireAndReplacePassword(string passwordToValidate)
   {
       AccountManager.ValidatePassword(passwordToValidate);
       AccountManager.ExpirePasswordForAccount(this.CurrentAccount);
       AccountManager.AssignPasswordToAccount(this.CurrentAccount, passwordToValidate);
   }
   

2. O non ti fidi del chiamante : cosa succede se il chiamante assegna semplicemente una password non valida?

   In questo caso, il chiamante non deve conoscere gli interni, quindi sii breve. Non è necessario specificare che è in corso la convalida dell'input: ci si aspetta che convalidi gli input da un chiamante non affidabile.

   public void ReplacePassword(string newPassword)
   {
       Contract.Requires(AccountManager.IsPasswordValid(newPassword));
   
       AccountManager.ExpirePasswordForAccount(this.CurrentAccount);
       AccountManager.AssignPasswordToAccount(this.CurrentAccount, newPassword);
   }
   

   o, se c'è ancora un motivo per dire che la vecchia password scadrà:

   public string ExpireAndReplacePassword(string newPassword)
   {
       Contract.Requires(AccountManager.IsPasswordValid(newPassword));
   
       AccountManager.ExpirePasswordForAccount(this.CurrentAccount);
       AccountManager.AssignPasswordToAccount(this.CurrentAccount, newPassword);
   }
   

3. O dal punto di vista del business, separatamente, quelle azioni non hanno senso .

   Nel terzo caso, se solo l'aggregazione ha senso per il business, puoi semplicemente usare il verbo usato in questo dominio. Ad esempio, se gli utenti non scadono le loro password, né le convalidano, né le assegna, ma semplicemente le modificano, la modifica che implica la convalida, la scadenza e l'assegnazione, chiama semplicemente il metodo:

   public string ChangePassword(string password)
   {
       Contract.Requires(AccountManager.IsPasswordValid(password));
   
       AccountManager.ExpirePasswordForAccount(this.CurrentAccount);
       AccountManager.AssignPasswordToAccount(this.CurrentAccount, password);
   }
   

string ChangePassword(...)
{
    if(ValidateNewPassword(...))
    {
        ExpireCurrentPassword();
        CreateNewPassword();
        return ... //Method signature is string?
    }
    else
    {
        //Handle invalid password
    }
}

IMO molto più pulito!

Come accennato da altri vorrei andare con UpdatePassword o RenewPassword poiché entrambi implicano che una password deve esistere e che vengono eseguite azioni su di essa che potrebbero o meno cambiarlo. L'approccio migliore per me personalmente in tali situazioni è stato quello di rinominare la funzione, quindi avvolgere la funzione nel vecchio nome, lasciando la compatibilità legacy in atto per un po 'e avendo un messaggio di registro che emette il nuovo nome della funzione modernizzata. In questo modo puoi consentire ai programmatori di abituarsi al nuovo nome senza rompere la base di codici e, in modo casuale, salvando di dover apportare molte modifiche al codice di refactoring da solo.