建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 崔皓
成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供炎陵網(wǎng)站建設(shè)、炎陵做網(wǎng)站、炎陵網(wǎng)站設(shè)計(jì)、炎陵網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、炎陵企業(yè)網(wǎng)站模板建站服務(wù)，十多年炎陵做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
策劃 | 云昭
1、開篇
不懂原始類型的程序員，往往由于急于求成，上手很快，最后卻發(fā)現(xiàn)被各種Bug耽誤進(jìn)度。本文以經(jīng)典的郵箱類型、貨幣類型、密碼類型為例，利用好類型系統(tǒng)能夠很好地改進(jìn)編碼方式，同時為技術(shù)人找回“打穩(wěn)地基”的快樂。
2、字符串類型變身成為郵箱類型
筆者已經(jīng)厭倦了使用原始類型，并試圖通過使用原始類型，來為一個領(lǐng)域進(jìn)行建模。
字符串值（String）類型不僅僅用來保存用戶的電子郵件地址或國籍信息，還可以有更豐富的用途。我需要一個EmailAddress的類型，并定義它不能為空，同時希望有單一的入口來創(chuàng)建該類型的對象。在返回一個值之前，需要被驗(yàn)證和規(guī)范化。
同時，也希望該數(shù)據(jù)類型有一些方法，如.Domain()或.NonAliasValue()，在輸入foo+bar@gmail.com時，會分別調(diào)用這兩個方法并返回gmail.com和foo@gmail.com。
在類型設(shè)計(jì)中應(yīng)該考慮這種有用的功能，該功能的引入有助于防止錯誤的發(fā)生，并提高了類型的可維護(hù)性。
3、設(shè)計(jì)良好、功能實(shí)用的類型
例如，一個EmailAddress可以提供兩個方法來檢查是否相等。
lEquals方法用來判斷兩個（規(guī)范化）的電子郵件地址是否相同，如果相同將返回true。
lEqualsInPrinciple
該方法對于foo@gmail.com和foo+bar@gmail.com的輸入會判斷相同，因此也會返回true。（這里假設(shè)兩個郵箱都是同一個人注冊的，因此相同需要判斷兩個郵箱“相等”）
特定類型的方法在不同的使用場景下都會發(fā)揮不同的作用。如果用戶jane@gmail.com注冊，但又用Jane@gmail.com登錄，那么用戶的登錄不應(yīng)該失?。▋H僅存在首字母大小寫的區(qū)別）。同樣的，如果戶用使用電子郵件地址（foo@gmail.com）和另一個注冊賬戶（foo+svc@gmail.com）聯(lián)系客戶支持，相同就需要對這兩個郵箱進(jìn)行有效匹配。這些都是典型應(yīng)用場景，如果沒有散落在代碼庫中的業(yè)務(wù)邏輯，僅憑一個簡單的字符串是無法滿足的。
注意：根據(jù)Office RFC描述，電子郵件地址中@符號之前的部分可以區(qū)分大小寫，但所有主要的電子郵件主機(jī)都將其視為不區(qū)分大小寫，因此，域名類型也考慮這方面的問題。
4、好的類型可以防止Bug
順著上面郵箱類型的例子，如果我們想走得更遠(yuǎn)，假如希望一個電子郵件地址可以被驗(yàn)證或未被驗(yàn)證。通常的做法是，通過向個人的收件箱發(fā)送一個獨(dú)特的代碼來驗(yàn)證電子郵件地址。這些 "商業(yè) "上的互動也可以通過類型系統(tǒng)來表達(dá)。例如，創(chuàng)建一個叫做VerifiedEmailAddress的第二個類型。該類型可以繼承自EmailAddress。并且確保代碼中只有一個地方可以產(chǎn)生VerifiedEmailAddress的實(shí)例，即負(fù)責(zé)驗(yàn)證用戶地址的服務(wù)。如此這般，應(yīng)用程序的其他部分可以依靠這個新類型來防止Bug。
任何發(fā)送電子郵件的功能都可以依靠該類來驗(yàn)證的電子郵件地址的安全性。想象一下，如果電子郵件地址是通過簡單的字符串來表達(dá)的，會是怎樣的情況。
因此，要找到相關(guān)的用戶賬戶，檢查一些模糊的標(biāo)志，如HasVerifiedEmail或IsActive，確保這些標(biāo)志設(shè)置是正確的，而不會在默認(rèn)構(gòu)造函數(shù)中被錯誤地初始化為真。有太多的錯誤空間由于使用了原始字符串，導(dǎo)致有些檢查不到位的情況，這種使用原始類型的表達(dá)方式被認(rèn)為是懶惰和缺乏想象力的編程。
5、富類型免受錯誤的侵?jǐn)_
另一個很好的例子是貨幣！我已經(jīng)數(shù)不清有多少應(yīng)用程序使用十進(jìn)制來表達(dá)貨幣值。也已經(jīng)數(shù)不清有多少應(yīng)用程序使用十進(jìn)制類型表達(dá)貨幣值。為什么呢？
這種類型有很多問題，甚至很難理解。每個與錢打交道的領(lǐng)域都應(yīng)該有專門的貨幣類型。貨幣類型應(yīng)該包括貨幣和運(yùn)算符重載（或其他安全功能），以防止出現(xiàn)100美元與20英鎊相乘這樣的愚蠢錯誤。此外，并非每種貨幣在小數(shù)點(diǎn)后都只有兩位數(shù)。有些貨幣，如巴林或科威特第納爾有三位。如果你在致力處理投資或銀行貸款，那么你最好確保你呈現(xiàn)的Unidad de Fomento有4個小數(shù)點(diǎn)。這些問題已經(jīng)很重要了，足以保證有一個專門的Moneytype，但這還遠(yuǎn)遠(yuǎn)不夠。
除非在系統(tǒng)內(nèi)部完成所有功能，否則就不得不與第三方系統(tǒng)打交道。例如，大多數(shù)支付網(wǎng)關(guān)都是以整數(shù)值來請求和響應(yīng)資金。由于整數(shù)值不能涵蓋類似浮點(diǎn)數(shù)（雙數(shù)類型）的四舍五入運(yùn)算，因此比浮點(diǎn)數(shù)更受歡迎。唯一需要注意的是，數(shù)值必須以小單位（如美分、便士、迪拉姆、格羅茲、科佩克等）傳輸，這意味著如果你的程序處理小數(shù)點(diǎn)數(shù)值，在與外部API對話時，你將不得不不斷地來回轉(zhuǎn)換它們。如前所述，并不是每種貨幣都使用兩個小數(shù)點(diǎn)，所以不是每次都是簡單的乘/除以100。事情很快就會變得很困難，如果這些業(yè)務(wù)規(guī)則被封裝成一個簡潔的單一類型，事情就會被大大簡化。
var x = Money.FromMinorUnit(100, "GBP")：￡1
var y = Money.FromUnit(100.50, "GBP")：￡1.50
Console.WriteLine(x.AsUnit())：1.5
Console.WriteLine(x.AsMinorUnit())：150
如果這還不夠復(fù)雜的話，各國也有不同的貨幣格式來表示貨幣。在英國，"一萬英鎊和五十便士 "將被表示為10,000.50，但在德國，"一萬歐元和五十美分 "將被顯示為10.000,50。試想一下，如果這些規(guī)則沒有放到統(tǒng)一的貨幣類型中，那么在整個代碼庫中會有多少與貨幣相關(guān)的代碼被分割開來。
此外，一個專門的貨幣類型可以包括許多功能，這將使貨幣價值的工作變得輕而易舉。
var gbp = Currency.Parse("GBP");
var loc = Locale.Parse("Europe/London");
var money = Money.FromMinorUnit(1000050, gbp);
money.Format(loc) // ==> ￡10,000.50
money.FormatVerbose(loc) // ==> GBP 10,000.50
money.FormatShort(loc) // ==> ￡10k當(dāng)然，建立這樣一個Money類型在開始的時候會有點(diǎn)費(fèi)勁，但是一旦它被實(shí)現(xiàn)并經(jīng)過測試，那么代碼庫的其他部分就可以帶來更大的安全性，并防止大多數(shù)的Bug的產(chǎn)生，否則這些Bug會隨著時間的推移而慢慢出現(xiàn)。即使像Money.FromUnit(decimal v, Currency c)或Money.FromMinorUnit(int v, Currency c)這樣的小功能看起來并不多，但它使參與連續(xù)開發(fā)的程序員能夠意識到，用戶輸入或外部API收到的值是否包含在其中，這樣可以在一開始就防止Bug的產(chǎn)生。
6、聰明的類型設(shè)計(jì)減少副作用
富類型的偉大之處在于，可以以任何的方式來塑造它們。這里展示另外一個例子，富類型如何將團(tuán)隊(duì)從巨大的操作開銷中拯救出來，甚至防止安全漏洞。
相信很多系統(tǒng)中的代碼庫都有一個類似于字符串secretKey或字符串password的東西，它作為函數(shù)的參數(shù)。那么在什么情況下有可能出錯呢？
如下（偽）代碼：
try
{
var userLogin = new UserLogin
{
Username = username
Password=password
}
var success = _loginService.TryAuthenticate(userLogin);
if(success)
RedirectToHomeScreen(userLogin)。
ReturnUnauthorized()。
}
catch (Exception ex)
{
Logger.LogError(ex, "User login failed for {login}", userLogin);
}
這里出現(xiàn)的問題是，如果在認(rèn)證過程中拋出一個異常，那么這個應(yīng)用程序?qū)⒂脩舻拿魑拿艽a寫入日志。當(dāng)然，這段代碼一開始就不應(yīng)該存在，這種情況會隨著時間的推移而發(fā)生。大多數(shù)這樣的錯誤都是隨著時間的推移而逐步發(fā)生的。
最初，UserLogin類可以有一組不同的屬性，在最初的代碼審查中，這段代碼可能沒有問題。幾年后，有人可能修改了UserLogin類以包括明文密碼。這個功能甚至不會出現(xiàn)在代碼提交的差異中，因此會逃過代碼審查。于是就引入了安全漏洞。然而，如果引入一個富類型（專有類型），就可以避免類似錯誤的發(fā)生。
在C#中（以這個語言為例），當(dāng)一個對象被寫入日志時，ToString()方法會被自動調(diào)用。有了這些知識，我們就可以設(shè)計(jì)一個這樣的密碼類型。
public readonly record struct Password()
{
public override string ToString()
{
return "****"。
}
public string Cleartext()
{
return _cleartext。
}
}
雖然是一個微小的變化，但在系統(tǒng)的任何地方都不可能意外地輸出一個明文密碼。這不是很好嗎？
當(dāng)然，在實(shí)際的認(rèn)證過程中，你可能仍然需要明文值，那么就需要通過非常明確的命名方法Cleartext()來實(shí)現(xiàn)的，所以對這個操作的敏感性沒有任何含糊，它自動引導(dǎo)開發(fā)者有意和謹(jǐn)慎地使用這個方法。
處理用戶的PII（如國家保險號、稅號等）也是同樣的原則。使用專門的類型對這些信息進(jìn)行建模。覆蓋默認(rèn)函數(shù)，如.ToString()。ToString()的默認(rèn)函數(shù)，并通過相應(yīng)的命名函數(shù)暴露敏感數(shù)據(jù)。你永遠(yuǎn)不會把PII泄露到日志和其他地方，以后可能需要一個巨大的操作來再次刷掉它。
小伎倆發(fā)揮了大作用！
7、形成習(xí)慣
每當(dāng)開發(fā)者處理那些有特殊規(guī)則、行為或敏感數(shù)據(jù)的時候，不妨考慮如何能通過創(chuàng)建一個顯式類型來幫助自己。
讓我們再舉一個密碼類型的例子，可以走得更遠(yuǎn)!
密碼在被存儲到數(shù)據(jù)庫之前會進(jìn)行散列計(jì)算，但這個哈希值不是一個簡單的字符串。在某些時候，我們將不得不在登錄過程中把以前存儲的哈希值與新計(jì)算的哈希值進(jìn)行比較。但并不是每個開發(fā)人員都是安全專家，比較兩個哈希字符串可能會使代碼受到攻擊。
檢查兩個密碼哈希值是否相等的推薦方法是以非優(yōu)化的方式進(jìn)行。
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization) ]
private static bool ByteArraysEqual(byte[] a, byte[] b)
{
if(a == null &&b == null)
{
return true;
}
if(a == null || b == null || a.Length != b.Length)
{
return false;
}
var areSame = true;
for (var i = 0; i < a.Length; i++)
{
areSame &= （a[i] == b[i]）。
}
return areSame。
}
注：代碼示例取自原始ASP.NET Core資源庫
因此，將這一特殊功能編碼為一個專門的類型才是合理的。
public readonly record struct PasswordHash
{
public override bool Equals(PasswordHash other)
{
return ByteArraysEqual(this.Bytes(), other.Bytes())。
}
}
如果一個PasswordHasher只返回PasswordHash類型的值，即使是對業(yè)務(wù)不太了解的開發(fā)者也會使用一種安全的形式來檢查相等。
在建立領(lǐng)域模型方面要考慮周全! 當(dāng)然，編程中的一切都沒有明確的對錯之分，人們的個人使用情況總是有更多的細(xì)微差別，這些不是在一篇文章中所能表達(dá)的，但筆者建議是，考慮如何使類型系統(tǒng)對開發(fā)者的幫助很大?，F(xiàn)在許多現(xiàn)代編程語言都有非常豐富的類型系統(tǒng)，我們可能忽視了它們沒有利用好這些類型改進(jìn)編碼方式。
網(wǎng)頁名稱：有了Bug，先看看“Type”
分享URL：http://www.5511xx.com/article/dpdhies.html
