왜 다태성을 사용하는데 신경을 써야 합니까?

다태성이 무엇인지 설명하려는 글이 많다.기본적으로 모든 프로그래머가 이해하고 존중해야 할 OOP의 지주 중 하나이다.
본문은 원인을 해석하려고 시도한다.
사용자 등록 기능을 갖춘 시스템이 있다고 가정하십시오.이해관계자는 시스템이 반드시

사용자 정보를 검증합니다.사용자가 잘못된 데이터를 입력하면 오류 페이지가 표시됩니다.

사용자 이미지 저장

사용자 정보 저장

사용자 응답

수요를 반영하는 가장 간단한 코드는 다음과 같다

class User {
  public User Register(string name, string password, stream avatar) {
    // Validate
    var user = new User(name, password);
    if (!user.valid()) throw new InvalidUserException();

    // Uploading
    var avatarPath = Uploader.upload(avatar);
    user.avatarPath = avatarPath;

    // Save
    user.save();

    // Return response
    return user;
  }
}

보시다시피 이 코드의 절차는 업무 섭외자의 수요를 반영합니다.
그래.그렇다면 인프라 수요가 있다면 어떤 일이 일어날까.우리는 공급업체의 잠금을 싫어한다.우리는 두 가지 이미지 저장 유형 사이를 전환할 수 있기를 희망한다. 구글 저장과 아마존 S3?
나로 하여금 또 다른 천진한 방식을 취하게 하다.모든 종류의 저장소에 업로드할 수 있는 uploader 클래스를 만들었습니다.

class User {
  public User Register(string name, string password, stream avatar) {
    // Validate
    var user = new User(name, password);
    if (!user.valid()) throw new InvalidUserException();

    // Upload
    String avatarPath = "";
    if (Environment.get("STORAGE") == "S3") {
      // Setup S3 Uploader
      // Setup credentials
      // Setup some more
      avatarPath = Uploader.uploadS3(avatar);
    } else {
      // Setup Google Uploader
      // Setup credentials
      // Setup some more
      avatarPath = Uploader.uploadGoogleCloud(avatar);
    }

    user.avatarPath = avatarPath;

    // Save
    user.save();
    return user;
  }
}

그러나 이 코드는 더 이상 업무 수요를 완전히 반영하지 않는다.이 코드에는 인프라 시설과 관련된 문제가 박혀 있다.각 스토리지 공급업체마다 자격 증명 설정이 다릅니다.스토리지 공급업체마다 접속 설정이 다릅니다.잠깐만요.
현재 이런 방법을 사용하고자 하는 개발자는 어느 정도에 시스템의 인프라를 이해해야 한다.
이것은 복잡하고 시간도 소모되는 것 같다.만약 우리가 개발자가 인프라 시설의 세부 사항을 이해하지 못한 상황에서 이 코드를 사용하도록 하려면 어떻게 해야 합니까?
우리는 할 수 있다.

// Different uploader
interface IUploader {
   public string Upload(Stream fileContent);
}
class S3Uploader: IUploader {
  public string Upload(Stream fileContent) { // Something }
}
class GoogleCloudUploader: IUploader {
  public string Upload(Stream fileContent) { // Something }
}

// Factory. Create uploader according to environment
class Uploader {
  public static IUploader CreateUploaderByEnvironment() {
    if (Environment.get("STORAGE") == "S3") {
      var result = new S3Uploader();
      // Setup S3 Uploader
      // Setup credentials
      // Setup some more
      return result;
    } else {
      var result = new GoogleCloudUploader();
      // Setup Google Uploader
      // Setup credentials
      // Setup some more
      return result;
    }

  }
}

이 Uploader 클래스가 같은 인터페이스를 가지도록 함으로써 사용자 클래스의 코드를

class User {
  public User Register(string name, string password, stream avatar) {
    // Validate
    var user = new User(name, password);
    if (!user.valid()) throw new InvalidUserException();

    // Uploading
    var avatarPath = Uploader.CreateByEnvironment().upload(avatar);
    user.avatarPath = avatarPath;

    // Save
    user.save();
    return user;
  }
}

현재 이 코드는 업무 수요를 다시 반영했다.
인프라 시설의 세부 사항을 알지 못하는 개발자는 인프라 시설의 요구를 위반하지 않고 코드를 작업하고 수정할 수 있다Uploader.CreateByEnvironment().
우리가 뭘 했는지 보여줘.

교환 가능한 업로드 클래스, S3Uploader와 GoogleCloudUploader를 제작했습니다.둘 다 같은 인터페이스를 따른다.이런 방법은 다태성이라고 불린다.

우리는 환경 선택 유형에 따라 실현할 수 있는 방법을 만들었다.우리는 공장 모델이라고 부른다.

이러한 실천을 통해 우리는 하나의 코드를 만들었다. 이 코드는 사용자 클래스에서 업무 수요를 신속하게 반영하고 다른 클래스에 인프라 시설의 수요를 숨긴다.
다태성은 세부 사항을 숨기고 강조 표시하는 것을 허용합니다.
예를 들어 이런 상황에서 다중성이 없는 과정 프로그래밍 범례에서 우리는 업무 수요를 신속하게 반영하는 코드를 만들 수 없다.
이런 기술은 최종적으로 당신이 다른 방식으로 코드 라이브러리를 조직할 수 있도록 허용한다.
만약에 우리가 프로그래밍 업계의 역사를 돌이켜 보면 다태성은 당시에 보급되었다. 우리는 여전히 수요에 따라 일련의 종류를 설계했고 규범을 가진 모든 종류를 한 무리의 프로그래머에게 맡겨 처리했다. 전체 시스템이 어떻게 운영되는지 모른다.
보시다시피 개발자가 상기 예시된 인프라 시설의 세부 사항을 이해하지 못한 상황에서 사용자 등록 기능을 어떻게 사용하도록 합니까?너는 이것이 완벽한 도구라는 것을 알 수 있다. 이 일은.
내가 다태성을 하는 것은 단지'대상을 대상으로 하는 디자인을 깊이 이해하고 존중하는 전문 개발자'가 되기 위해서가 아니다.
이 자체는 무의미하거나 가치가 없다.
너도 그래야지.너는 단지 모든 사람이 이렇게 말하거나 이력서에 식초를 넣었다고 해서 이렇게 해서는 안 된다.
왜 나는 OOP, 특히 다태성에 관심을 가지는가?
내가 옳을 때 이런 일들이 일어난다는 것을 알기 때문이다.
상업적으로 볼 때 나는 인프라 시설의 세부 사항을 숨길 수 있다.
인프라의 측면에서 볼 때 나는 업무의 세부 사항을 숨길 수 있다.
나는 공책을 회의실로 가지고 가서 업무 이해관계자와 함께 그들이 무슨 이야기를 하는지 들을 수 있다.내 코드는 Powerpoint 프레젠테이션에 표시된 도표와 완전히 같다.
나는 인프라 시설 팀과 함께 공책을 회의실로 가지고 갈 수 있다.다른 파일을 엽니다.벽의 도표는 나의 코드와 완벽하게 일치할 것이다.
그것은 단지 하나의 다른 파일과 하나의 다른 종류일 뿐이다.
나는 나의 코드를 진실의 원천으로 삼아 모든 관련자와 부서와 모든 것을 토론할 수 있다.나는 다른 팀과 토론할 어떠한 추가 문서도 필요 없다.
많은 프로그래머들이 시스템을 잘 모른다고 느끼게 하기 때문에 사용자와 이야기를 나누는 것을 싫어한다.그들은 서로 다른 언어로 이야기를 나누고 다른 용어를 사용하는데 실제 코드 라이브러리에서 일하는 프로그래머에게는 서로 다른 파장이 있다.
그런데 제가 코드 라이브러리에 사용자의 생각을 반영할 수 있다고 하면요.
명확한 코드 라이브러리가 있는데 이것은 사용자의 사고 시스템이 어떻게 작동하는지 반영한다(일부 세부 사항은 낮은 차원에 숨겨져 있다). 프로그래머와 사용자는 같은 이해력으로 같은 파장으로 말할 수 있다.
프로그래머는 사용자와 대화하는 것을 갈수록 좋아할 것이다.
날 믿어.네.
이것이 바로 다태성을 정확하게 완성하는 최종 게임이다.