關於 c# interface好處 ，我們在網路上蒐集到這些相關的討論、資訊與評價

其實很多團隊裡面有些該被時代淘汰的開發/命名/排版規範，或是該規範有其適用的 context，現在產品開發可能已經不具備該 context 了。

但團隊中的一些老鳥，可能因為沒有去確認該規範所對應的 context ，或是不明究理的一脈傳承下來的限制（就跟猴子拿香蕉就被噴水，之後的猴子都不敢拿香蕉，一拿香蕉就會被其他猴子圍毆），也可能是因為「習慣」了不想改，導致團隊開發生產力低落，又得不到對應的好處。

一個明顯的例子，就是匈牙利命名法，在靜態型別語言 + IDE 輔助之下，已經不需要把型別掛在變數名稱或方法名稱上。

另一個則是禁用 C# 裡面的 var，其實工具也都支援一鍵轉換了，當你詢問團隊成員為什麼不能用時，他們的回答是：「我也不知道，就不能用。」這時就會知道這個團隊存在著這樣的根本問題。

當然，還有那種 Data Class 身上不能有方法，或是 interface 自己是個 folder/namespace 的情況。

很多人寫程式真的是都是用背的，沒去了解背後的脈絡，沒去了解限制/規範想要達到的目的，透過犧牲一些自由度以帶來更大的效益，卻一味的遵循著「#前人的教誨」而不知其所以然，其實是很浪費的。

--
當然啦，如果是在既有的產品中，無傷大雅的 name style，我的確傾向 #一致性 優先於 #正確性，但同樣的團隊成員新寫的產品，就應該思考一下，究竟怎樣才是最有生產力、最有效益的作法。

我的原廠sony f60閃光燈終於可以做到"離機可控出力引閃"，更有TTL和高速同步！使用的是神牛x1引閃器。
這個"終於"真的等得很久，也是為什麼Sony總在專業攝影上被嫌棄的其中一個最大垢病之一：閃燈系統一塌糊塗，從2013年sony 堆出fullframe stl A99 時，閃燈hotshoe 就從從前的Minolta腳改為mi(multi interface)腳，擁有mi腳的f60閃光燈亦同時堆出。這個mi hotshoe 雖然型形是與Nikon/canon 的standard hotsheo 一模一樣，可是mi的觸發點不只在中間的單點傳輸，而是在前方，這個設計的好處是sony 機利用mi hot shoe 除了可以駁閃燈外，更可以駁螢光幕、收音器等。
那壞處是什麼？就是沒有引閃器支援到啊！真不明白原廠是怎樣理解用家對閃光燈的需要，官方建議的引閃方法竟然還是光引，即是閃光燈的光引發另一枝閃燈，還一定要sony閃燈，光引的限制很大，雖然確實可做到"可控出力引閃", 但壞處也太多。
而最正路的利用引閃器作無線引閃這功能sony一直沒有推出過，N/C 廠也沒有（n廠有內置），而這重要的功能一直交給副廠做，phottix就是其中最主要的廠家，那麼繼續用phottix 那類引閃不就解決了嗎？很遺憾地，sony 這麼前衞的mi腳是不能用n/c standard hotshoe 那種引閃器引發，就是因為引發點不是在中間而是在前方！（曾有神人改線路改成前方引發，真的成功了，可是仍是沒有ttl), phottix 亦因為太少人用mi 頭而沒有出新的支援mi 産品。
那究竟有什麼解決方法？sony 60閃附件有一個精美的轉接頭，能將mi 頭轉回minolta 頭，這個就是唯一的解決辦法！轉回minolta 頭之後就可以用回phottix 舊有的Minolta引閃😭，thanks god, 一對引閃二手只用三百蚊就買回來了，這是我多年來的解決辦法。
但是，膠做的轉接腳非常"牙煙", 普通的phottix strato亦只能用m mode, 想在相機控制出力、ttl和高速同步，就得買上二千蚊的phottix oddin, 但由於Minolta 版的oddin 也太舊，加上要用轉駁頭，2000元的價錢真的沒有吸引力。
那是4年前的事，直到今年年頭，才陸續出現支援產品，首先是phottix odin 出第二代支援sony mi 頭（仍是很貴，平價的strato仍是沒有mi版 ），然後是sony 自家終於有引閃器，不過比odin 更貴，又支援不了其他牌子的閃燈，不了。最後，閃燈界新星來自大陸的"神牛"終於出了mi 專用的接收器😭，數百元就可以享受可控引閃的樂趣，是超感動的說，枝sony f60閃光燈突然就像技能解放一樣，不用想怎樣賣掉他了。

[iOS Programming] 什麼是 Key-Value Coding？

剛剛收到班上同學的來信，說他在網路上看到一個名詞，叫 Key-Value Coding。問我什麼是 Key-Value Coding。由於這個主題比較冷僻，用到的機會也不能算多。在只有 48 小時得把所有 iOS SDK 教完的壓力下，這個主題被我捨棄了。沒想到同學們還是很用功啊！看來我不講是不行的了（所以說，出來混，一定要還的...）。

先做個定義吧：「Key-Value Coding 就是一種可以用『字串』，來存取物件內某個『屬性欄位』的技巧」。

假設你有一個類別叫做「People」，裡面有兩個屬性欄位「name」與「addr」定義如下：

＠interface People : NSObject

{
NSString *name;
NSString *addr;
}
@property NSString *name;
@property NSString *addr;

@end

然後你用 People 宣告了一個名為 robert 的物件，並指定初值給它。如下所示：
People *robert = [[People alloc] init];
robert.name = @"Robert";
robert.addr = @"台北市忠孝東路 1 號";

若你要存取「name」與「addr」屬性，你得這麼寫：
NSLog(@"%@", robert.name); // 印出 robert 物件 name 屬性內容 --> "Robert"
NSLog(@"%@", robert.addr); // 印出 robert 物件 addr 屬性內容 --> "台北市忠孝東路..."

使用 Key-Value Coding，你可以這麼存取屬性值：
NSLog(@"%@", [robert valueForKey:@"name"]); // 存取到 robert 內的 name 欄位。

你有沒有注意到，欄位名稱「name」被字串化了！也就是說，只要你把 "name" 改為 "addr"，抓到的欄位值就是 robert.addr 的了。

這有什麼好處呢？舉例來說，你製作了一個資料庫 App，有個下拉式清單，列出所有可以讓使用者選擇的欄位名稱。如「姓名」、「住址」...。使用者只要選擇了一個欄位，如：住址，就可以印出當前物件內，住址那一欄。如果你先把「姓名」與對應的欄位名稱「name」、以及「住址」與對應的欄位名稱「addr」…以「鍵值對（Key-Value Pair）」的方式存放好：

Key Value
------------
姓名 name
住址 addr
...

在 Objective-C 內，鍵值對是用 NSDictionary 類別存放的：
NSArray *keys = [[NSArray alloc] initWithObjects: @"姓名", @"住址", …nil];
NSArray *values = [[NSArray alloc] initWithObjects: @"name", @"addr", … nil];
NSDictionary *dic = [[NSDictionary alloc] initWithObjecs:values forKeys:keys];

則 Key 可以拿去當下拉式功能表要顯示的內容。當使用者選擇了其中一項，如：「姓名」，我就可以拿回到「鍵值對」的物件，查到它對應的值是「"name"」。接著，我就可以用所謂的「Key-Value Coding」這招，抓出當前物件姓名欄位的值：
NSLog(@"%@", [robert valueForKey: theValue]); // theValue 代表由「鍵值對」中查到的值「"name"」。

若使用者選擇的是「住址」，則 theValue 會被填入「"addr"」，上述程式碼不用改一個字，照常抓出 robert 物件內住址欄位的值。

您看出「Key-Value Coding」的價值了嗎？萬一 People 類別內有上百個欄位，我要印出特定欄位的值，都是用下列這一道就解決了：
NSLog(@"%@", [robert valueForKey:@"name"]);

不用 Key-Value Coding、把物件的屬性欄位「字串化」的話，想存取特定欄位，你一定得寫一堆 if ~ else：
if (選中的欄位 == 「姓名」)
fieldToBePrinted = robert.name;
else if (選中的欄位 == 「住址」)
fieldToBePrinted = robert.addr;
else
…

這樣，大家知道 Objective-C 內的 Key-Value Coding 是什麼意思了嗎？