-
카테고리
-
세부 분야
프로그래밍 언어
-
해결 여부
미해결
[#다시질문] Person과 Product 관계
21.08.05 01:44 작성 조회수 96
0
답변을 작성해보세요.
0
이재승
지식공유자2021.08.05
안녕하세요
> 구체적(?)으로 변하기 때문에 속성값이 없는 쪽이 더 많은 값을 할당 받을 수 있다고 생각해도 될까요?
네 맞습니다
그리고 전체적으로 이해하신 내용이 맞습니다
프린이
질문자2021.08.08
안녕하세요, 글 읽어주시고 답변 남겨주셔서 진심으로 감사드립니다.
아마도, 남겨주신 답변 처럼 이해하고 있는 듯 합니다.
그래도 조금은 제가 제대로 이해하고 있는지 걱정?이 들어,
다시한번 답변에, "=>" 이후의 내용으로 정리해봤는데, 제대로 이해했을까요,
혹여 저와 같은 고민/물음이 있는 분들을 생각하고 염두해 작성한 글이라,
조금은 자세하고 길어지게 됐습니다.
완벽하지는 않지만, 어느정도는 이해하고 있다고 확인 받게 된다면,
이전보다 조금은 다르게 타입스크립트를 생각하며, 공부 할 수 있을 것 같습니다.
감사합니다:]
> 구체적(?)으로 변하기 때문에 속성값이 없는 쪽이 더 많은 값을 할당 받을 수 있다고 생각해도 될까요
: 구체적(?)으로 변하기 때문에
=> 저는 "구체적"이라는 단어가 내포한 의미는 (인터페이스든, 커스텀 type든 이것이 보유한/이것에 정의된) 프로퍼티가 많아지는 것, 혹은 프로퍼티가 많이 정의된 "상태" 라고 이해하고 있는데요,
구체적이라는 건, 프로퍼티의 갯수가 많아져 프로퍼티로 빽빽히? 차 있는 이미지로 그려집니다.
갯수적인 조건도 있겠지만,
프로퍼티가 갖는 타입이 "string"같은 단일 타입 집합, "string|number"같은 복합 타입집합, 타입집합이 다른 타입을 포함할 수 있는지에 대한 고민도 있을 것이라 생각합니다.
아무튼, 속성의 갯수의 문제든, 속성이 가진 타입간의 관계든,
우선, 구체적으로 변한 타입들은 속성의 갯수가 많은데, 이를 호환하려면,(프로퍼티의 갯수든, 프로퍼티가 갖는 타입들간의 관계든 )
(호환하려는) 그 상대 타입도 최소한 이런 구체적인 조건들을 충족해야 하는 것으로 이해했습니다.(타입스크립트는 구조타이핑 때문에 이렇다고 이해했습니다.)
그래서 상대 타입은 조금 부담?스러울 것 같습니다.,,
왜냐하면 호환하고 싶은 타입이 너무 구체적이고, 타입집합 관점에서 (너무) 촘촘?하다면,
갯수적인 문제나, 타입집합을 포함할 집합인지 체크하는 등, 이를 만족할 타입은 찾기 어렵거나, 아예 없을 수도 있기 때문이죠
이런 이유로, 구체적인 타입에 호환되는 경우가 적기 때문에(찾기 어렵기 때문에),
: 속성값이 없는 쪽이
=> 상대적으로 속성의 갯수가 적은 타입일 경우,
호환하려는 타입은 자신이 (호환하기 위해) 가져야 할 속성의 수가 적기 때문에,
즉, 조건이 쉽고, 허들이 낮기 때문에
속성값이 없는 쪽이 더
: 더 많은 값을 할당 받을 수 있다
=> (구체적인 곳(속성이 많이 정의된 타입)보다는)
상대적으로 더 많은 값(타입, 프로퍼티가 있는 인터페이스 혹은 커스텀 type)을 할당 받을 수 있다,
라고 이해했습니다.
이재승
지식공유자2021.08.08
말씀하신대로
속성 갯수가 많아질 수록 => 값의 집합이 작아진다 => 할당 받기 어려워진다
라고 이해하시면 될 것 같아요
개별 속성의 타입은 각 속성 별로 위에 말씀하신 내용을 똑같이 적용하게 됩니다
속성의 타입이 또 다시 interface 로 정의된 타입일 수도 있으니까요 (함수 타입을 수도 있고, number 일 수도 있겠죠)
만약 속성의 타입이 any 라면 무엇이든 받을 수 있으니 값의 집합이 (다른 타입에 비해) 커진다고 생각할 수 있습니다
답변 1