I'm CaLendarW Blog

as operator 係用黎做 casting 的

static void Main()
{
    double x = 1234.7;
    int a;
    // Cast double to int.
    a = (int)x;
    System.Console.WriteLine(a);
}
// Output: 1234

如果用 boxing 黎轉 type 既話, 錯 type 的話就會 throw InvalidCastException, 但如果用 as operator 就唔會 throw InvalidCastException, 而 value 就會係 null

public static void Main()
{
    object time1 = DateTime.Now;
    DateTime? t = time1 as DateTime?;    // valid casting
    int? wrongCast = time1 as int?;    // wrongCast == null
}

null coalescing operator – ?? 係用黎決定參數是否 null 既算式, 自 C# 2.0 開始支援, 作為 null 既使用簡化.

// .net framework 1.1 既寫法
if (obj.Currency != null)
    cbxCurrency.SelectedItem = obj.Currency;
else
    cbxCurrency.SelectedItem = DefaultCurrency;

// .net framework 2.0 既寫法
cbxCurrency.SelectedItem = obj.Currency ?? DefaultCurrency;

長度上係短左, 識既人會易睇左. 另一方面, 通常既用法會同 Nullable 一齊用, 但自己平時無乜用開 Nullable, 所以對此無乜 comment (知道有呢樣野, 但唔知咩情況用先叫做適合, 所以都未用過.

// nullable int
int? i = null;
int result = i ?? 5;
// Output: result == 5

MsSQL 內既 Identity Generator, 雖然被發現當 Table 儲存超過一百萬行時, 由 SELECT @@Identity 或者 SELECT SCOPE_IDENTITY() 會存在 Return 值錯誤既問題, 但經過呢個幾月既開發都未出現問題.

係 MsSQL 入面, 新增 Record 時主要提取 Primary Key 既方法主要有 @@IDENTITY, SCOPE_IDENTY() 同 IDENT_CURRENT(‘table_name’) 三種:

@@IDENTITY
使用 @@IDENTITY 會 Return 當前 Session 任何 Table 最後生產的 Primary Key, 如果 Insert statement 運行後如果有任何 Trigger 中會 Insert 在其他 Table 的話, @@IDENTITY 就會變得不準確.

SCOPE_IDENTY()
使用 SCOPE_IDENTY() 會 Return 當前 Scope 內確實 Insert 左既 Primary Key, 就算有任何 Trigger 在背後運行都不會有任何影響, 係一個最好既選擇. 不過經由 MS Connect 入面既 Feedback 顯示, Table 被新增至一百萬行後, Return Value 有可以會籨 1 開始數起, 這問題由 MS 回應既答案中回答到已增加到它們的 Bug tracking database 中.

IDENT_CURRENT(‘table_name’)
而 IDENT_CURRENT(‘table_name’) 會 Return 指定 Table 最後生產出來的 Identity, 由於它不會理會任何 Scope 或者 Session, 當有多於一個 Scope 或者 Session 運行時便有機會出現不準確既問題.

因此, 在以上三個尋找 IDENTITY 既方法中, 並沒有一個能在任何環境下百分百準確既方法, 所以在 MsSQL 使用 Identity Generator 便會有潛在問題既可能性, 因此在 deploy 前應該對 Database 作詳細測試, 已確定當前既環境設定正確.

再者, Identity Generator 亦開始慢慢地被其他類型既方案取代, 例如 GUID, Hi/Lo or UUID 等等.

正如之前 CS != SE 文章內所講, Technology 其實永遠唔會有錯, 錯就只會錯在未能正確使用它們既人, 而軟件其中一個用途就係用來避免人們使用犯錯, 所以在程式篇寫時應該以不同既設定技巧及文檔來避免人們使用錯誤, 那軟件才容易正確地被使用!!

前幾日經 CodeProject 入面既 Email Subscription 介紹, 睇左個 Post 講呢個 Topic, 感覺幾好!!~~

簡單 d 講就似 Pure Math 同 Apply Math 既分別, Computer Science 主要係研究新科技, 但新科技往往都要經過人來善用, Software Engineering 係包括人既活動. 雖然 Engineering 既原則係想個個人跟住同一套次序, 所做既野都應該差唔多, 但因為個個人唔同, 每個人用唔同心態去做同一樣野都會有好大分別, 所以一組人用一種方法獲得成功, 未必能在另一組人用同一個方法成功, 所以只會用一些 “通常” 等等既字眼, Methodology 係咁, Architecture 係咁, 所以先會有 Design Pattern, Anti-Pattern 等等不同技巧既出現, 所以科技係要被正確使用才可以為公司帶來利益, 而何謂正確只能基於使用者對科技既認識, 經驗同思維上.

對我黎講, Computer Science 有些似由零變一既過程, 而 Software Engineering 就係將一變做二, 三, 四, 五等既進步, 而且 Software Engineering 注重既係每個方面都要求質素管理, 咁先有進步, 及可以容易地發現邊個 Process 有問題而提出改善, 但因為人既不同, 質素往往都存在在實行者既身上, 如果實行者跟得唔足, 質素未必一致, 跟得太跟, 效率未必做得好, 始終 agile 所講既 velocity 都要等到組員成熟先會提升到, 因此軟件既優劣在於實行既人對軟件質素認識同堅持.

而自己最低限度既堅持, 只在於 Coding Standard 既使用, 因為對外行人黎講, Naming Convertion 係最簡單可以由表面上睇到既野, 正所謂人靠衣裝, 如果 Source Code 給予人既外觀都不好既話, 使用程度只會慢慢減低, 跟住就唔會再得到重用, 慢慢形成 Anti-Pattern 中既 Lava Flow, 而且 Naming 本身亦係一個好重要既 Topic, 可以增加 Source Code 既可讀性, 因此自己對呢方面好注重. 另外, 自己雖然比較想用 OOD, 但自己亦唔會將所有野變成 OO, 以自己常用真實物件來代入設計軟件既態度上, 現實上有些東西係唔可以用 OO 係解決, 印象中好似係 Study Semantic Web 既過程入面, Rule Base 同某部份 Knowledge Base 既邏輯如果代成 Object 唔一定係好, 用 Routine Base 可能會較好.

Software Developer, 某程度上除左對 Computer Science 要有一定既認識, 亦都好應該對 Software Engineering 有所既認識, 因為自己係寫軟件, 如果質素做得不好, 科技用不得其所既話, 就可能會做成反效果!!

近期做緊 Application to Database 呢部份, 開始對 Analysis Patterns 一書中既 Knowledge Level 同 Operation Level 多左理解, 除此之外, 仲開始感受既點樣控制重覆!!

Duplication, 係 Program 入面係理應避免的, 正如見到重覆既 Code 就應該進行重構一樣, 但在 Database 層面上既管理又可能係另一種講法. 係 Knowledge Level 入面, 儲存既資料應該避免重覆, 因為所做既係最新既資訊, 以最實時既資訊去處理日常既運作, 雖然用既係最新既資訊, 但儲存落 Database 入面就可能要將所有有關既 Value Object 儲存埋, 因為往後既日子如果 Knowledge Level 有所改變, 亦唔應該影響到 Database 入面 Operation Level 完成品既歷史, 方面了解當時既情況, 等同於 Data Mining 一樣, 做既唔係避免重覆, 而係有必要地控制重覆, 呢個就係 Database Design 入面一個重要既地方!!