보안 조항 해석

보호 조항은 무엇입니까?
guard 자구는 fail-fast 방법에서 파생된 기술로 그 목적은
한 가지 조건을 검증하는 거예요.
프로그램에서 벗어나서 더 깊고 의미가 적은 오류를 던지는 것이 아니라 오류입니다.내가 너에게 예를 하나 들겠다.

public User GetUser(string userName)
{
  if (userName == null) throw new NullArgumentException(nameof(userName));
  // Continue if the condition is fulfilled...
}

이전 예시에서 if 블록은 보호GetUser 방법을 통해null의 영향을 받지 않고 보호 서브문장으로 충당한다userName 논점.이렇게 하면, 우리는 방법의 나머지 부분을 자유롭게 작성할 수 있으며, 검사를 걱정할 필요가 없다userName가 비어 있습니다.

보호 조항을 왜 사용합니까?
Guard 자문은 쓸모없는 플러그인 조건을 삭제하고 의미 있는 오류를 되돌려줌으로써 코드를 간소화합니다.
보호 약관 이전:

public void CreateUser(string userName, string password)
{
  if (userName == null)
  {
    // Do something...
  }
  else
  {
    // Do something else...
    if (password == null)
    {
      // Do something...
    }
    else
    {
      // Do something else...
    }
  }
}

보호 약관 이후:

public void CreateUser(string userName, string password)
{
  if (userName == null)
    throw new NullArgumentException(nameof(userName));
  if (password == null)
    throw new NullArgumentException(nameof(password));
  // Do something...
}

무엇을 예방합니까?

전제 조건
선결 조건은 방법이 집행되기 전에 반드시 만족해야 하는 조건이다.기본적으로 이 방법의 전제 조건은
항상 메소드 매개변수에 의존합니다.방법 전제 조건의 좋은 예는 비공식 매개 변수이다.

public User GetUser(string userName)
{
  // Requires a non null `userName` argument.
  if (userName == null) throw new NullArgumentException(nameof(userName));
  // Execute the method purpose...
}

후면 조건
후치 조건은 방법이 집행된 후에 반드시 만족해야 하는 조건이다.기본적으로 방법 후 조건은
항상 방법이 되돌아오는 값에 의존합니다.방법post조건의 좋은 예
빈 문자열.

public User GetUsers()
{
  // Execute the method purpose:
  var users = this._repository.GetUsers();
  // Ensures `UserRepository.GetUsers()` returns no null users.
  if (users.Any(user => user == null))
    throw new Exception("UserRepository.GetResult() a null user.");
  return users;
}

예상한 바와 같이post조건은 강제적이지 않습니다. 왜냐하면 이 방법이 어떤 결과를 가져올지 정확히 알고 있기 때문입니다.유일하다
신뢰할 수 없는 호출 (즉 외부 방법 또는
상술한 방법의 결과를 얻다.

공공과 개인
이 두 가지 상황에서 사유 방법의 전치 조건과 후치 조건을 검사해서는 안 된다. 왜냐하면 유형 자체는
이 방법들을 호출할 때, 입력과 출력을 믿을 수 있습니다.그러니까 검증할 필요 없어.

보호 조항의 예외를 어떻게 처리합니까?
자, 보호 조항에 관한 매우 중요한 규칙을 소개할 때가 되었습니다.

Guard clauses exceptions should never be caught.

이것은 대다수 상황에서 호출자가 이러한 이상을 클릭하도록 해야 한다는 것을 의미한다. 왜냐하면 대다수 상황에서 당신은 경계해야 하기 때문이다
자구는 빈 파라미터와 같은 상황이 발생하는 것을 방지할 것이다.빈 매개 변수는 무슨 뜻입니까?대개
현재 빈 파라미터가 버그입니다. 버그를 잡고 영원히 발견하지 못할 기회를 잡아야 합니까?아니요!반대로 우리
응용 프로그램이 즉시 실패하기를 바랍니다. 그러면 우리는 그것을 생산 과정에 배치하기 전에 오류를 발견할 수 있습니다
개발 과정.
하지만 버그에 의존하지 않는 전제조건이 있다면?만약 우리가 약간의 선결 조건이 있다면, 예를 들면
비즈니스 논리적 전제 조건?해결책은 당신의 보호 조항을 폭로하는 것입니다!

왜 보호 조항을 폭로해야 합니까?
때로는 비즈니스 논리를 경계해야 합니다. 이것은 이 조건이 존중을 받지 못할 수도 있고, 존중을 받지 못할 수도 있다는 것을 의미합니다
벌레일 거야.이러한 상황에서 공공 블라인드 방법의 관련 보호 자구를 공개할 수 있다
호출자에게 이 브리 방법을 돌려보내라.
구현:

public bool CanCreateUser(string userName, string password)
{
  return !this.UserNameExists(userName) && this.IsStrongPassword(password);
}

public void CreateUser(string userName, string password)
{
  if (!this.CanCreateUser(userName, password))
    throw new Exception("The user can't be created.");
  // Create the user...
}

사용법:

if (!CanCreateUser(userName, password))
{
  Console.WriteLine("Invalid username or password.");
  return;
}
CreateUser(userName, password);
Console.WriteLine("The user has been successfully created.");

왜 수위류를 만들었는지
우리의 보호 조항을 전문적으로 보호 조항을 제공하는 유형에 봉하는 것은 좋은 실천이다. 그러면 우리는
논리를 다시 사용하고 더 읽을 수 있는 보호 자구를 작성합니다.이러한 과정의 예는 다음과 같습니다.

public static Guard
{
  public static void Requires(Func<bool> predicate, string message)
  {
    if (predicate()) return;
    Debug.Fail(message);
    throw new GuardClauseException(message);
  }

  [Conditional("DEBUG")]
  public static void Ensures(Func<bool> predicate, string message)
  {
    Debug.Assert(predicate(), message);
  }
}

이 실현에서 Requires 방법은 검증 전제조건에 사용되고 Ensuresmetd는 검증에 사용된다
후조건.이 실현의 흥미로운 점은 사용이Debug명칭공간.System.Diagnostics 클래스의 요점은 디버깅 모드에서만 실행되며 실행할 수 없다는 것이다
전화한 사람에게 잡혔기 때문에 이것은'영원히 잡지 않는다'는 규칙을 존중하는 것이다.또한 Debug 방법으로 사용Ensures C# 속성으로 디버깅 시에만 코드가 실행되도록 하여 성능 향상
생산 과정에서 영향을 받지 않습니다. 왜냐하면 배치되기 전에 빈틈이 검출된다는 것을 명심하세요.
만들다하면, 만약, 만약...
그 다음 코드가 실패하거나 우리가 원하지 않는 데이터가 일치하지 않을 수도 있기 때문에 전제 조건이 충족되지 않는다.
다음과 같은 경우Conditional 클래스는 다음과 같습니다.

public User GetUserRange(int from, int to)
{
  Guard.Requires(() => from >= 0, "Received negative from.");
  Guard.Requires(() => to >= 0, "Received negative to.");

  var users = this._repository.GetUsers();
  foreach (user in result)
    Guard.Ensures(
      () => user != null,
      "UserRepository.GetResult() a null user.");

  return users;
}

요약
본고에서 우리는guard자구가 어떻게 우리가 생산 환경에 배치하기 전에 버그를 발견하고
우리의 코드는 더욱 가독성을 갖추고 있다.
보호 조항의 예외를 처리하지 말아야 하는 이유와 보호 조항을 어떻게 공개하는지
그들은 업무 논리에 의존할 때 움츠러든다.
마지막으로 우리는 GuardClauseException류에서 자신의guard자구를 만드는 방법을 배웠다.