Powiedz, nie pytaj o zasadę i wygaśnięcia hasła

Question

Próbując zachować pragmatyczne zasady programowania, staram się decydować o tym, jak radzić sobie ze zmianami hasła użytkownika w oparciu o zasadę "Powiedz, nie pytaj".

Mam obiekt użytkownika, którego hasło wygasa co 30 dni. Muszę być w stanie wyświetlić hasło wygasło/zmienić widok hasła, jeśli hasło wygasło. Pytanie do obiektu, jeśli hasło wygasło (jego stan), a następnie wybranie widoku, który wydaje się być naruszeniem zasady.

Jaki jest najlepszy sposób na poradzenie sobie z taką sytuacją?

Answer 1

Możesz rzucić wyjątek PasswordExpired od obiektu użytkownika po uwierzytelnieniu hasła lub jakiejkolwiek funkcji, którą wywołasz jako pierwszy użytkownik.

Answer 2

Powinieneś rozważyć, czy obiekt użytkownika ma metodę Validate(), która zapewnia wartość logiczną (jak ma to miejsce w przypadku umowy dostawcy członkostwa), lub rozważ, czy metoda Validate() zwróci pewnego rodzaju wyliczenie wskazujące wynik sprawdzania poprawności (OK, INVALID_PASSWORD, EXPIRED_PASSWORD itd.).

Istnieje wiele opcji - wyrzucenie wyjątku nie powinno być jednym z nich, jeśli hasło wygasło. Jest to zła forma, a także trafienie wydajnościowe, ponieważ środowisko wykonawcze musi rozwijać stos.

Answer 3

Osobiście nie lubię programować arround zwracanych wartości/Enum typów. Im więcej typów zwrotów masz, tym więcej ścieżek musisz przetestować/pracować. Poza tym używanie wyjątków do kontrolowania przepływu jest bardzo złą praktyką (chyba, że ​​naprawdę nie możesz znaleźć innej opcji - ale zwykle jest lepsza).

Wygasłe hasło nie jest dla mnie wyjątkowe. Jej prawidłowy stan po wszystkim (Albo chcesz zrobić coś przeciwko hasła wygaśnie w ogóle)

staram się zachować prosty i albo zwrócić bool lub coś jak Func<T> które mogą być bezpośrednio powoływane przez rozmówcę.

Prawdopodobnie coś takiego:

public class User 
    { 
     private DateTime _lastChangeDate; 
     public Action Validate() 
     { 
      if (_lastChangeDate >= DateTime.Now.AddDays(-30)) 
      { 
       return new Action(() => this.Login()); 
      } 
      else 
      { 
       return new Action(() => this.ChangePassword()); 
      } 
     } 
     private void Login() 
     { 
      Console.WriteLine("Login"); 
     } 
     private void ChangePassword() 
     { 
      Console.WriteLine("Change Password"); 
     } 
    } 

Po stronie rozmówcy:

user.Validate().Invoke(); 

Answer 4

login 
    model.validate(); 
    return model.show(self); 

passwordExpired() 
    return View("ChangePassword") 

loginSuccess() 
    return View("default") 

class User 
    show(aController) 
     if passwordExpired 
      return aContoller.passwordExpired() 
    else return aContoller.loginSuccess() 

Tell, nie pytaj, nie ma wyjątków, i przestrzega prawa Demeter

Answer 5

Jednym ze sposobów rozwiązania tego problemu jest modelowanie typu OO:

public class Login { 

private String userName; 
private String password; 
private Date expirationDate;  

public void authenticate(String password) { 
    if (this.password.equals(password) { 
     redirectoToMainOrEditPage(); 
    } else { 
     redirectToFailPage(); 
    } 
} 

private void redirectToMainOrEditPage() { 
    Date today = new Date(); 

    if (today.before(expirationDate)) { 
     redirectToMainPage(); 
    } else { 
     redirectToEditPage(); 
    } 
} 

private void redirectToMainPage() { 
    ... 
} 

private void redirectToEditPage() { 
    ... 
} 

private void redirectToFailPage() { 
    ... 
} 

public void changePassword(String newPassword) { 
    ... 
} 

public void changeExpirationDate(Date newDate) { 
    ... 
} 
} 

W ten sposób nie pytasz niczego o inne obiekty domeny, ale powiadamiasz Login o uwierzytelnieniu, ponieważ ma wszystko, co jest potrzebne, aby to zrobić.