형제 요리가 뭐냐면
읽기 루브릭의 정의는 한 줄이야. 형제는 같은 원리를 상속한 요리고, 다른 요리권에서 오는 경우가 많다는 거지. 피파는 접시 위 요리마다 형제를 적을 수 있고, 형제 하나엔 필드가 5개 붙어. name_original, name_ko, cuisine, 같이 물려받은 principle(위에서 붙인 이름 그대로), 그리고 그 원리를 어떻게 물려받았는지 말하는 why_same이야.
루브릭은 원리가 받쳐 주는 한, 서로 다른 요리권에서 3개에서 5개를 달라고 해. 더 적어도 되고, 하나도 없어도 된대. 코드는 목록을 5개에서 잘라(dish.siblings[:5]). Sizzle이 새 요리를 끌어내는 곳이 바로 여기야. 아빠는 접시 하나를 찍고, 트리는 그 접시가 품은 요리들만큼 자라.
먹을 수 있는 다형성
설계 문서의 예시가 그 모양을 보여 줘. 뿌리 클래스는 기법 하나야. 향을 기름에 먼저 옮기고, 그 기름에서 익히는 거지. 인터페이스는 역할 묶음이야. 대개 향채, 기름, 그리고 그 기름에서 익는 무언가지. 형제마다 그 역할을 다른 재료로 채워.
| 형제 | 향채 | 기름 | 거기서 익는 것 |
|---|---|---|---|
| 감바스 알 아히요 (스페인) | 마늘, 고추 | 올리브유 | 새우 |
| 알리오 올리오 (이탈리아) | 마늘, 고추 | 올리브유 | 버무리는 파스타 |
| 버섯 아히요 (스페인) | 마늘 | 올리브유 | 버섯 |
| 파기름 볶음밥 (한국) | 파 | 식용유 | 밥 |
바오샹(爆香) 볶음 (중국) | 마늘, 생강, 파 | 아주 뜨거운 기름 | 웍에 들어갈 나머지 전부 |
| 파에야의 소프리토 | 양파, 마늘, 피망 | 올리브유 | 쌀이랑 육수 |
부엌은 달라도 원리는 하나야. 클래스를 쥔 요리사는 오늘 저녁 그 역할을 채울 재료만 있으면 불 앞에 설 수 있어. oo-quest 트랙 4가 "요리를 가로지르는 Polymorphism"에서 이 읽는 법을 가르쳐. 그리고 그 절 끝에 여기까지 들고 올 만한 경고를 남겨. 같은 구조적 역할은 맛보고 고칠 가설이지, 정체성이 아니라고. 그 표는 요리권을 맛의 축으로 읽어. Sizzle의 원리는 역할 인터페이스를 가진 기법이야. 저장할 수 있고, 냉장고 재료랑 맞춰 볼 수 있고, 사진에서 끌어낼 수 있는 단위로 쪼갠 거지. 그리고 Sizzle은 그 경고까지 필드 하나로 저장해.
코드가 형제마다 하는 일
integrate의 뒷부분이 목록을 돌아. 형제 하나마다 이렇게 해.
- 원어 이름도 한국어 이름도 없으면 건너뛰어.
- 이미 있는 요리나 변형을 원어 이름으로, 안 되면 한국어 이름으로 찾아. 다른 조회처럼 정규화한 이름으로 비교해.
- 부모를 골라. 형제가 댄 원리 이름이 이번 읽기에서 찾은 원리랑 맞으면 그거고, 아니면 그 요리에서 찾은 첫 번째 원리야. 이번 읽기가 그 요리의 원리를 하나도 못 찾았으면 부모는 없어.
- 맞는 게 없으면 새 요리를 제안해.
origin: "sibling"을 달고, 한국어 이름은 gloss로, 요리권도 넣고,why_same을 요약으로 써. - 요리가 이미 있었으면, 그게 원래 형제 제안이었을 때만 설명을 새로 고쳐. 그리고 이 접시의 바로 그 요리가 아니면 부모 간선을 더해.
놓치기 쉬운 결과가 3가지 있어. 형제 클래스엔 역할 바인딩이 없어. 그 요리가 역할을 어떻게 채우는지 접시로 보인 적이 없으니까, 페이지엔 왜 같은 집안인지만 남아. 3단계에서 원리를 맞출 땐 가벼운 키를 써. 띄어쓰기랑 대소문자만 통일하는 키야. 그래서 피파가 원리 이름을 살짝 다르게 써도, 형제는 허공에 뜨는 대신 요리의 첫 원리 밑으로 가. 다만 이 대체엔 기댈 원리가 있어야 해. 읽기가 그 요리의 원리를 하나도 못 찾았으면, 새 형제는 부모 없이 제안되고 Tree 페이지의 Not yet under a principle, 곧 아직 원리 아래에 없는 목록에서 기다려. 그리고 5단계 덕분에, 트리에 이미 있던 요리도 형제로 언급되면 새 부모를 얻을 수 있어. 원리 2개 제한은 읽기 한 번이 요리 하나에 대해 주장할 수 있는 양이야. 시간이 지나면서 요리가 물려받는 원리 수엔 상한이 없어.
만나기 전까진 추정
형제는 연결된 접시 없이 들어와. 그리고 Sizzle에서 증거는 저장하는 게 아니라 링크로 계산해. 그래서 갓 생긴 형제는 inferred로 읽혀. 웹에선 Pippa's inference, 곧 피파의 추정이라고 뜨고, 폰에선 반짝이 아이콘이야. 엔진 테스트가 바로 이걸 확인해. 감바스 한 접시를 읽고 나면 접시 위 요리는 encountered, 알리오 올리오는 inferred이고, 한국어 이름을 가진 형제도 트리에 있어.
이 상태가 바뀌는 데 고칠 행은 하나도 없어. 나중에 아빠가 알리오 올리오를 먹고 사진을 찍으면, 새 읽기가 그걸 접시 위 요리로 말해. _resolve_dish가 이름으로 기존 형제 클래스를 찾고, 새 접시를 거기 이어. 같은 행이 이제 Eaten, 곧 먹어 봄이 돼. 이건 웹이 encountered에 붙인 이름표인데, encountered가 뜻하는 건 이어진 접시가 하나 이상 있고 그중 집에서 만든 게 없다는 것뿐이야. 아빠가 시장에서 봤다고 적은 접시 하나만 이어져도 그 행은 똑같이 Eaten으로 떠. 이름표가 상태보다 더 많이 말하는 셈이지. 집에서 만든 접시면 Cooked, 곧 직접 요리가 되고. origin은 여전히 sibling이고 상태도 여전히 proposed야. 이어진 접시는 아빠가 그 요리를 만났다는 증거일 뿐이야. 채택은 따로고, 그건 아빠만 해.
배지는 장식이 아니야
Sizzle 불변식 5번은 증거 상태를 늘 보여 주라고 해. 도메인 모델 문서는 더 대놓고 말해. 추정한 형제가 맛본 요리처럼 보이는 일은 절대 없어야 한다고. 요리 50개 중 40개가 피파 짐작인 트리는, 그 40개가 어느 건지 보일 때만 쓸모가 있어. 배지가 없으면 트리는 아빠가 먹어 본 적도 없는 요리를 안다고 천천히 믿게 만들 거야.