TypeScript structurally வகைப்பிரிக்கப்பட்டிருப்பதால், UserId மற்றும் OrderId இரண்டும் string ஆக இருக்கும் போது அவை பரிமாற்றக்கூடியவை — கம்பைலர் அவற்றைக் குழப்புவதிலிருந்து உங்களைத் தடுக்க முடியாது. ஒரு தனிப்பட்ட,幻影 "brand" ஐ இணைப்பதன் மூலம் வகைப்பிரிக்கலை உருவகப்படுத்துகின்றன, இதனால் ஒரே மாதிரியான வகைகள் வேறுபடுகின்றன.
// the brand is a property that exists only in the type system, never at runtime
type Brand<T, B> = T & { readonly __brand: B };
type UserId = Brand<string, "UserId">;
type OrderId = Brand<string, "OrderId">;
function getUser(id: UserId) { return id; }
const uid = "u1" as UserId;
const oid = "o1" as OrderId;
getUser(uid); // ✅
getUser(oid); // ❌ Error: OrderId is not assignable to UserId
getUser("u1"); // ❌ Error: plain string is not a UserId
__brand சொத்து ரানடைমில் ஒருபோதும் இல்லை (மதிப்பு வெறுமனே ஒரு சரம்), ஆனால் வகை முறையில் இது UserId மற்றும் OrderId ஐ சামஞ்சஸ்யமற்றதாக்குகிறது — கலப்பு பிழைகளின் முழு வகுப்பைத் தடுக்கிறது.
function toUserId(s: string): UserId {
if (!s.startsWith("u")) throw new Error("invalid UserId");
return s as UserId; // validation happens here, once
}
সীমানையில் ஒரு முறை சரிபார்க்கவும்; மீதமுள்ள குறியீடு ப்রான்ட்டெட் வகையை நம்புகிறது.
IDs (UserId vs OrderId), validated/sanitized strings (Email, SafeHtml), units (Meters vs Feet), PositiveNumber — இரண்டு மதிப்புகள் ஒரு primitive வகையைப் பகிர்ந்து கொள்ளும் எங்கெனும் ஆனால் குழப்புவதக்கூடாது.
ப்রான்ட்டெட் வகைகள் structural வகைப்பிரிக்கல் மிகவும் தாராளமாக இருக்கும் இடங்களில் nominal பாதுகாப்பைச் சேர்க்கின்றன.
அவை argument-order கலப்புகள் மற்றும் "unvalidated vs validated" குழப்பத்தை compile நேரத்தில் பிடிக்கின்றன, பூஜ்ய runtime செலவு இல்லாமல் — பெரிய, சரியான-முக்கியமான codebases-ல் domain மாடலிங்கிற்கான ஒரு சக்திशালி மாதிரி.