속성과 메소드를 항상 확인하지 않고 자바 스크립트에서 오리 타이핑을 어떻게 사용합니까?


11

나는 자바 스크립트가 오리 타이핑을 사용한다는 것을 알고 처음에는 이것이 C #과 같은 강력한 유형의 언어에 비해 다형성을 쉽게 만들 것이라고 생각했습니다. 그러나 이제 인수를 취하는 내 함수에는 다음과 같은 것들이 있습니다.

if(myObj.hasSomeProperty())

또는

if(myObj.hasSomeMethod())

또는

if(isNumber(myParam))

기타

이것은 나에게 정말 추한 것입니다. 나는 C # 배경에서 왔으며 정의 된 인터페이스가 훨씬 더 좋습니다.

정적으로 유형이 지정된 언어에 효과적인 전략을 잘못 적용하려고하는지 궁금하고 Javascript에서이를 수행하는 더 좋은 방법이 있습니까?

나는 확인할 수는 없지만 자바 스크립트 런타임 오류를 추적하는 것은 실제로 오류가 코드에서 발생하는 곳에서 항상 발생하지 않기 때문에 악몽이 될 수 있습니다.


2
나는 당신이 역동적으로 유형이 지정된 언어의 본질을 혼란스럽게 할 것이라고 생각합니다. 컴파일 타임 대신 런타임에 많은 오류가 발생한다는 사고 방식에 익숙해 져야합니다. 모든 인수가 숫자를 입력하는 모든 함수의 숫자인지 확인해야한다고 생각한다면, 안전이 가장 중요한 목표 인 lib를 선적하면 가치가있을 수 있습니다. 규모에 관계없이 잘못된 유형이 전달되는 경우 함수가 실패하도록하는 것이 필수적이라는 것을 알게되었습니다. 대신보다 생산적인 테스트는 테스트 구성에 있습니다.

유형이 필요한 인터페이스 요구 사항을 준수하는지 확인하기 위해 이러한 검사를 수행하는 데 도움이 될 수있는 곳 (예 : 필요한 방법이 있는지 확인)이 가장 중심적이고 광범위하게 사용되는 기능 (예 : 불안정성 = 0 인 기능)에 있습니다. efferent / afferent coupling metric Martin이 제공합니다). 그것은 아주 작은 대상이어야합니다. 일반적으로 범위에서 분리 된 일회성 로컬 함수가 많이 있습니다. 이러한 포괄적 인 런타임 검사 세트가 필요하지 않을 수도 있습니다. 그것들은 많은 복잡성을 축적하지 않습니다.

유형 스크립트로 전환하십시오. 여전히 오리 유형이지만 컴파일 타임에 많은 오류를 감지하기 위해 정적 타이핑을 지원합니다.
코드 InChaos

2
오리 타이핑의 가장 큰 문제는 바로 그 힘이 약점에서 비롯된 것입니다. 자바 스크립트 객체 지향해야합니까하려는 경우, 당신은 단지 런타임 오류와 함께 살고 있고, 단위 테스트 당신이 :-(를 작성 후 곧 찾을 희망
로스 패터슨

@RossPatterson OPs 문제는 오리 입력이 아닌 동적 입력에 관한 것입니다. TypeScript와 Go는 모두 오리 형식이지만 OP 문제는 피하십시오. 오리 타이핑의 문제점은 다른 것입니다. 즉 오리 테스트를 통과했지만 기대하는 계약을 이행하지 못하는 멤버를 가질 수 있다는 것입니다.
코드 InChaos

답변:


11

속성과 메소드를 항상 확인하지 않고 자바 스크립트에서 오리 타이핑을 어떻게 사용합니까?

단순성 : 속성과 메서드를 항상 확인하지는 마십시오.

루비에서는 여러분이 부르는 것을 "치킨 타이핑"이라고합니다. 동적으로 오리 형식의 언어에서는 호출자가 적절한 객체를 전달한다고 믿기 만하면됩니다. 계약의 측면을 존중하는 것은 발신자의 직업입니다.

나는 자바 스크립트가 오리 타이핑을 사용한다는 것을 알고 처음에는 이것이 C #과 같은 강력한 유형의 언어에 비해 다형성을 쉽게 만들 것이라고 생각했습니다.

여기에 여러 직교 축 입력을 혼동하고 있습니다. 입력의 직교 축에는 네 가지가 있습니다.

  • When : 동적 타이핑 (런타임까지 타입을 알 수없고 확인) vs. 정적 타이핑 (런타임 전에 타입을 알고 확인 함)
  • 내용 : 오리 타이핑 (유형은 동작 에 기반 함 ), 구조 타이핑 (유형은 구조 기반 ) 및 공칭 타이핑 (유형은 이름 기반 )
  • 당신은 그들을 볼 수 있습니까? 명시 적 타이핑 (유형에 주석을 달아야 함) vs. 암시 적 타이핑 (유형이 유추 됨)
  • 강력한 타이핑 vs. 약한 타이핑 –이 제목에 눈에 띄는 제목이나 괄호 안의 설명을주지 않았다는 사실을 알았을 것입니다. 위의 7 가지 용어와는 달리,이 두 용어는 모두 보편적으로 받아 들여지는 정확한 정의를 가지고 있기 때문입니다. 서로 모순되는 약 12 ​​개의 반 넓게 사용되는 모호한 정의가 있습니다. 이상적으로는 모두 이러한 용어를 방지해야하며,이 경우에 있어야 사용할 정확하게 먼저 정의

C #을 언급 했으므로 대부분 정적으로 유형이 지정되지만 type을 통한 동적 유형 지정을 지원하지만 dynamic대부분 명목상 유형이 지정되지만 익명 유형은 구조적 유형 지정을 사용하며 구문 유형 (LINQ 쿼리 이해 구문과 같은)은 둘 중 하나라고 주장 할 수 있습니다. 유형이 지정되거나 구조적으로 유형이 지정된 경우 대부분 명시 적으로 유형이 지정되지만 일반 유형 인수 및 로컬 변수에 대한 암시 적 입력을 지원합니다 (로컬 변수 케이스는 대부분의 다른 언어에 비해 다소 이상하지만 유형을 그대로 둘 수는 없으므로 대신 명시적인 의사 유형을 제공하십시오.var즉, 암시 적 유형을 원하면 명시 적으로 말해야합니다. C #을 강력하게 입력했는지 또는 약하게 입력했는지 여부는 사용하는 두 용어의 정의에 따라 다르지만 특히 안전하지 않은 배열 공분산으로 인해 C #에 많은 런타임 유형 오류가있을 수 있습니다.

나는 확인할 수는 없지만 자바 스크립트 런타임 오류를 추적하는 것은 실제로 오류가 코드에서 발생하는 곳에서 항상 발생하지 않기 때문에 악몽이 될 수 있습니다.

디버깅은 배우기 쉬운 기술이 아닙니다. 그러나 Saff Squeeze 는 디버깅을 위해 테스트 및 리팩토링을 사용하는 Kent Beck이 설명하는 기술입니다.

적중률 낮음, 적중률 낮음 :

회귀 테스트 및 사프 스퀴즈

켄트 벡, 쓰리 리버스 인스티튜트

개요 : 결함을 효과적으로 격리하려면 시스템 수준 테스트로 시작하여 결함을 보여주는 가장 작은 테스트가 될 때까지 점진적으로 인라인하고 정리하십시오.


그 히트 em 하이 히트 em 로우 링크는 "페이지를 더 이상 사용할 수 없습니다"라는 인간 지향 메시지로 http 500을 얻습니다.
joshp

threeriversinstitute.org 도메인이 삭제 된 것 같습니다.
Bart van Ingen Schenau

아 젠장 그리고 WayBack Machine 에도 보관되지 않습니다 .
Jörg W Mittag

발신자는 계약 측면을 어떻게 존중해야합니까? 매개 변수가 무엇인지 (코드로) 전달할 방법이없는 것 같습니다. 모든 함수는 함수 fname (objParam, objParam, ...) 형식입니다. 이것은 자바 스크립트와 같은 언어가 사용법을 알리기 위해 외부 문서에 전적으로 의존한다는 것을 의미합니까?
Legion

@Legion : 문서화, 좋은 이름 지정, 상식, 동작 사양으로 테스트하고 소스 코드를 읽고 이름을 지정합니다. 이것은 실제로 C # 또는 Java와 같은 약한 유형 시스템과 크게 다르지 IComparer<T>.Compare(T, T)않습니다. 그리고 유형의 어디에서 java.util.Collections.binarySearch(java.util.List<T>)그것은 ...
Jörg W Mittag

1

나는 확인할 수는 없지만 자바 스크립트 런타임 오류를 추적하는 것은 실제로 오류가 코드에서 발생하는 곳에서 항상 발생하지 않기 때문에 악몽이 될 수 있습니다.

실제로 일반적인 관행은 확인하지 않는 것입니다. 그리고 그렇습니다. 실제 문제와 다른 곳에서보고되는 자바 스크립트 오류가 발생한다는 것을 의미합니다. 그러나 실제로, 나는 이것이 큰 문제라고 생각하지 않습니다.

자바 스크립트로 작업 할 때, 나는 내가 쓰고있는 것을 끊임없이 테스트하고 있습니다. 대부분의 코드에는 편집기를 저장할 때마다 자동으로 실행되는 단위 테스트가 있습니다. 예기치 않은 일이 발생하면 거의 즉시 알게됩니다. 거의 항상 실수 한 부분이 있기 때문에 실수했을 가능성이 매우 작은 코드 영역이 있습니다.

런타임 오류가 발생하면 적어도 스택 추적이 있고 브라우저 내 오류의 경우 스택 추적의 모든 수준으로 이동하여 변수를 검사 할 수 있습니다. 일반적으로 잘못된 값의 출처를 쉽게 추적하여 원래 문제로 추적 할 수 있습니다.

주로 정적으로 유형이 지정된 언어로 작성했을 때 나와 같은 경우 테스트하기 전에 더 큰 코드 블록을 작성했으며 원래 값을 추적하는 연습이 없었습니다. 자바 스크립트와 같은 언어로 프로그래밍하는 것은 다릅니다. 다른 기술을 사용해야합니다. C #과 같은 다른 언어로 개발 한 기술이 아니기 때문에 그런 프로그래밍이 더 어려워 보입니다.

그것을 말하면서, 명시 적 유형에 대해 말할 것이 많이 있다고 생각합니다. 문서화 및 오류 잡기에 좋습니다. 앞으로는 정적 유형 검사를 자바 스크립트에 추가하는 Flow 및 Typescript와 같은 것들의 채택이 증가 할 것이라고 생각합니다.


0

나는 당신이 옳은 일을하고 있다고 생각합니다. 당신의 눈을 즐겁게 해줄 스타일을 찾으면됩니다. 다음은 몇 가지 아이디어입니다.

  • 대신을 if(myObj.hasSomeProperty())사용할 수 있습니다 if( myobj.prop !== undefined ). BTW는 엄격하지 않은 모드에서만 작동하고 엄격 모드에서는 사용해야 if( typeof myobj.prop !== 'undefined' )합니다.

  • 형식 검사 중 일부를 오프로드하여 유효성 검사기를 분리 할 수 ​​있습니다. 인터페이스가 완성되면 (예 : if( is_valid( myobject ))is_valid시작하는 경우) 유효성 검사를 건너 뛸 수 있다는 이점이 있습니다 if( !DEBUG ) return true;.

  • 때로는 입력을 표준 형식으로 복제하는 것이 합리적입니다.이 경우 다양한 유효성 검사 대상을 복제 기능 / 개체로 수집 할 수 있습니다. exmaple의 경우에 생성자 편리하게 중앙 장소에서 모든 다양한 검증을 실행할 수 있습니다.my_data = Data( myobj, otherstuff )Data

  • (성능에 따라) 유형 유효성 검사를보다 우아한 것으로 간소화하는 라이브러리를 사용할 수 있습니다. 이 경로를 장기적으로 사용하지 않더라도 자신의 스타일로 부드럽게 이동하는 것이 편할 수 있습니다. 일부 예에는 xtype.js , type-check , validator.js 등이 포함됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.