TypeScript의 인터페이스 및 클래스 코딩 가이드라인에 대해 혼란

TypeScript의 인터페이스 및 클래스 코딩 가이드라인에 대해 혼란

TypeScript Coding 가이드라인을 읽었습니다.

그리고 나는 이 말이 다소 곤혹스럽다는 것을 알았다.

인터페이스 이름의 접두사로 "I"를 사용하지 마십시오.

'I' 접두사가 없으면 이런 건 말이 안 돼요

class Engine implements IEngine

제가 뭔가 놓치고 있는 건가요?

제가 잘 이해하지 못한 또 다른 점은 다음과 같습니다.

반

일관성을 유지하기 위해 코어 컴파일러 파이프라인에서는 클래스를 사용하지 마십시오.대신 함수 폐쇄를 사용하십시오.

그럼 수업을 전혀 사용하지 말라는 건가요?

누군가 설명해 주셨으면 합니다:)

팀/회사가 프레임워크/컴파일러/툴셋을 출하할 때 이미 경험이나 베스트 프랙티스 세트가 있습니다.그들은 그것을 지침으로 공유한다.가이드라인은 권장사항입니다.마음에 안 들면 무시해도 돼요.컴파일러는 여전히 코드를 컴파일합니다.로마에 있을 땐...

이 TypeScript를 하지 않는 입니다.I- 터 - - - - - - - 。

이유 #1 헝가리 표기법의 시대는 지났다.

의 I타입이 인터페이스인지 아닌지에 관계없이 프레픽스가 즉시 grokkking(싱킹)에 도움이 되는 것은 인터페이스 서포터입니다.프레픽스가 즉시 grokkking(피킹)에 도움이 된다는 문장은 헝가리 표기법에 호소합니다. I, 「」, 「」,C경우 ★★★★A에서는, 「추상 클래스」의 경우,svariable, string variable,cvariable의 경우 const 'const'는iinteger variable.이러한 이름 장식이 식별자 위에 마우스를 올리거나 단축키를 통해 유형 정의로 이동하지 않고도 유형 정보를 제공할 수 있다는 데 동의합니다.이 작은 장점은 헝가리 표기법의 단점이나 아래에 언급된 다른 이유보다 더 중요합니다.헝가리 표기법은 현대 프레임워크에서는 사용되지 않습니다.C#에는Iprefix(및 이것은 C#의 유일한 prefix)로, Historical Reasons(COM; 이력 이유)에 의한 인터페이스에 사용됩니다.소급하면 중1개입니다NET 아키텍트(Brad Abrams)는 프리픽스를 사용하지 않는 것이 좋다고 생각하고 있습니다.TypeScript는 COM-legacy-free이며, 따라서 TypeScript에는I- - 인터페이스 규칙. - 인터페이스 규칙.

★★#2I됩니다.

블랙박스가 있다고 가정해봅시다.이 박스와 상호 작용할 수 있는 몇 가지 유형 참조가 있습니다.인터페이스인지 클래스인지 신경 쓰지 마십시오.인터페이스 부분만 사용하면 됩니다.그것이 무엇인지(인터페이스, 특정 실장 또는 추상 클래스) 알기를 요구하는 것은 캡슐화 위반입니다.

예: API 설계 신화: Interface as Contract (계약으로서의 인터페이스)를 코드 내에서 수정해야 한다고 가정해 보겠습니다.예를 들어 삭제 등ICar및 use 「」를 사용합니다.Car이치노그런 다음 모든 소비자에게 이러한 교환을 수행해야 합니다. I- 의 구현 세부 사항에 의 암묵적 - 블랙박스의 구현 세부 사항으로 이어지다.

이유 #3 잘못된 이름 지정으로부터 보호

개발자들은 이름에 대해 제대로 생각하는 것을 게을리 한다.이름은 컴퓨터 공학에서 두 가지 어려운 것 중 하나입니다.개발자가 인터페이스를 추출해야 할 경우 문자만 쉽게 추가할 수 있습니다.I인터페이스명을 취득합니다.I인터페이스의 프레픽스는 개발자가 인터페이스에 적절한 이름을 선택하기 위해 머리를 짜내야 합니다.선택한 이름은 접두사뿐만 아니라 의도 차이를 강조해야 합니다.

추상화 사례: 다음을 정의하면 안 됩니다.ICar 있는 「」를 참조해 주세요.CarCar추상화이며 계약에 사용되는 것이어야 합니다.구현에는 다음과 같은 설명적이고 고유한 이름을 사용해야 합니다.SportsCar, SuvCar, HollowCar.

예: " " " 입니다.WpfeServerAutosuggestManager implements AutosuggestManager,FileBasedAutosuggestManager implements AutosuggestManager.

예: " " " 입니다.AutosuggestManager implements IAutosuggestManager.

이유 #4 적절한 이름을 선택하면 API 디자인 신화: 계약으로서의 인터페이스(Interface as Contract)에 대한 예방접종을 받을 수 있습니다.

되어 있는 사람을, 「클래스의 인터페이스」, 「클래스의 인터페이스」를 가지는 .Car implements ICar클래스 을 다른 .클래스의 인터페이스 부분을 다른 인터페이스 타입으로 복제해도 마법처럼 추상화되지 않습니다.인터페이스 부분이 중복된 경우에도 구체적인 구현이 가능합니다.추상화가 좋지 않은 경우 인터페이스 부품을 복제해도 개선되지 않습니다.추상화를 추출하는 것은 힘든 일이다.

메모: TS에서는 클래스를 조롱하거나 기능을 오버로드하기 위해 별도의 인터페이스가 필요하지 않습니다.클래스의 공용 멤버를 설명하는 별도의 인터페이스를 만드는 대신 TypeScript 유틸리티 유형을 사용할 수 있습니다.예.Required<T>는 타입의 합니다.T.

export class SecurityPrincipalStub implements Required<SecurityPrincipal> {
  public isFeatureEnabled(entitlement: Entitlement): boolean {
      return true;
  }
  public isWidgetEnabled(kind: string): boolean {
      return true;
  }

  public areAdminToolsEnabled(): boolean {
      return true;
  }
}

일부 공개 멤버를 제외한 유형을 작성하려면 생략과 제외 조합을 사용할 수 있습니다.

참조하는 링크에 대한 설명:

이것은 TypeScript용 코드 스타일에 관한 문서이며 프로젝트 구현 방법에 대한 스타일 가이드라인이 아닙니다.

를 I입니다.용합니니다다

않은 경우 가 수 있습니다.SomeThing와 ('인터페이스'의)SomeThingImpl(어느 쪽인가) '어느 쪽인가'

@stanislav-berkov가 OP의 질문에 대한 꽤 좋은 대답이라고 생각합니다.제 2센트만 공유하겠습니다.결국 공통의 이해에 도달하는 것은 귀사의 팀/부서/회사/무엇이든 간에 자신의 규칙/가이드라인을 정하는 것에 달려 있습니다.

가능한 한 바람직하게 표준 및/또는 규약을 따르는 것은 좋은 관행이며, 이해하기 쉽게 합니다.다른 한편으로, 저는 우리가 코드를 어떻게 쓸지 선택할 자유가 있다고 생각합니다.

감정적인 측면에서 생각해 보면 코드를 쓰는 방법이나 코딩 스타일은 우리의 성격과 경우에 따라서는 우리의 기분을 반영합니다.이것이 우리를 인간으로 유지시키는 것입니다. 단순히 규칙을 따르는 코딩 기계가 아닙니다.코딩은 단순한 산업화 과정이 아니라 공예가 될 수 있다고 생각합니다.

저는 개인적으로 -able 접미사를 붙여서 명사를 형용사로 만든다는 생각을 상당히 좋아합니다.매우 즉흥적으로 들리지만, 나는 그것이 너무 좋아!

interface Walletable {
  inPocket:boolean
  cash:number
}


export class Wallet implements Walletable {
  //...
}

}

타이프스크립트 문서에 제시된 지침은 타이프스크립트를 사용하는 사용자를 위한 것이 아니라 타이프스크립트 프로젝트에 참여하는 사용자를 위한 것입니다.페이지의 구걸에서 상세 내용을 읽으면 누가 그 가이드라인을 사용해야 하는지 명확하게 정의됩니다.다음은 가이드라인 링크입니다.타이프스크립트 가이드라인

결론적으로 개발자는 자신이 생각하는 대로 인터페이스 이름을 붙일 수 있습니다.

다른 응답과 마찬가지로 이 패턴을 시험하고 있지만 다음과 같이 구체적인 클래스를 인터페이스 유형으로 인스턴스화하는 함수를 내보냅니다.

export interface Engine {
  rpm: number;
}

class EngineImpl implements Engine {
  constructor() {
    this.rpm = 0;
  }
}

export const createEngine = (): Engine => new EngineImpl();

이 경우 구체적인 구현은 내보내지 않습니다.

는 꼭 싶어요.Props서픽스

interface FormProps {
 some: string;
}

const Form:VFC<FormProps> = (props) => {
  ...
}

인터페이스가 되는 유형은 구현 세부 사항입니다.API:s:s로 설정하다 때문에 .I.

다 요.prefix ... suffix 둘 다.

• ICar
• CarInterface

API에 예쁜 이름을 표시하고 구현에 세부사항을 숨겨야 합니다.그래서 제안합니다.

• Car.- API에서 공개됩니다.
• CarImpl이이는 컨슈머로부터 있습니다.- API의 실장입니다.

언급URL : https://stackoverflow.com/questions/31876947/confused-about-the-interface-and-class-coding-guidelines-for-typescript