doskey ls=dir
public static class StringHelper
{
public static bool IsCapitalized (this string s)
{
if (string.IsNullOrEmpty(s)) return false;
return char.IsUpper(s[0]);
}
}
IsCapitalized就是string type的extension method，我們可以這樣使用它：Console.WriteLine("Test".IsCapitalized());
其實這段呼叫在編譯時候會被修改成去呼叫static method，背後的細節被compiler隱藏起來。Console.WriteLine(StringHelper.IsCapitalized("Test"));
總結一下，extension method背後會做以下轉換：arg0.Method(arg1, arg2, ...); // Extension method call StaticClass.Method(arg0, arg1, arg2, ...); // Static method callInterface也可以被extended，範例如下：
public static T First(this IEnumerable sequence) { foreach (T element in sequence) return element; throw new InvalidOperationException("No elements!"); } ... Console.WriteLine("Test".First()); // Output: T
Python這類的動態語言大多提供Run-time時動態修改一個object的方法，這樣的好處是你可以動態的修改某個object，為這個Obejct加入一些新的method。
Ruby要為object加入新method非常簡單：
dog = Object.new
def dog.sit
print "I'm sitting.\n"
end
dog.sit
Ruby很簡單就能為dog加入一個sit的method。
Python實做起來稍微麻煩一些，主要原因是因為Python的函式有分成bound和unbound。
>>> def foo(): ... print "foo" ... >>> class A: ... def bar( self ): ... print "bar" ... >>> a = A() >>> foo <function foo at 0x00A98D70> >>> a.bar <bound method A.bar of <__main__.A instance at 0x00A9BC88>> >>>
bound method必須被bound到一個instance，在呼叫method時instance才會被當成參數傳入。
由於函式預設都是Unbound，如果直接加入method到object中，Python會丟出exception
>>> def barFighters( self ): ... print "barFighters" ... >>> a.barFighters = barFighters >>> a.barFighters() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: barFighters() takes exactly 1 argument (0 given)
其實只需要手動把method bound到instance上就可以解決這個問題。
這邊我們使用type module中的MethodType來把method bound到instance上。
>>> import types >>> a.barFighters = types.MethodType( barFighters, a ) >>> a.barFighters <bound method ?.barFighters of <__main__.A instance at 0x00A9BC88>> >>> a.barFighters() barFighters
可以看到method被bound後就可以在Python中被正確的呼叫，這就是Python動態在object加入method的方法。
Law of Demeter又叫做Least Knowledge，這其實是一個軟體設計的守則，簡單來說就是要簡單化Object之間的互動，讓多個Object不要互相相依。使得系統太過於複雜，造成未來維護成本較高。
Law of Demeter訂出了四條守則，限制一個Object內的函式只能呼叫以下這些函式：
不屬於以上這四種的函式都禁止呼叫。舉例來說，以下這個取得溫度的例子就違反Law of Demeter：
public float getTemp() {
return weatherStation.getThermometer().getTemperature();
}
以上的例子呼叫的getTemperature()函式是從getThermometer()中所取得，根據Law of Demeter的定義你不能使用某個透過其他函式回傳的物件中的函式。
public float getTemp() {
Thermometer thermometer = weatherStation.getThermometer();
return thermometer.getTemperature();
}
這個例子也同樣違反Law of Demeter，因為thermometer是透過其他Object的函式所取得。
public float getTemp() {
return weatherStation.getTemperature();
}
正解是在weatherStation中加入一個getTemperature()函式用來取得溫度。這樣就有符合Law of Demeter，因為weatherStation是此Object中包含的物件(HAS-A的關係)。
Law of Demeter可以減少Object之間的相依程度，可以減少軟體維護的成本。不過有優點就有缺點，使用此守則會產生出一些包裝用的函式，使用不當會導致開發速度增加，甚至會提昇軟體複雜度。
以下是一個過度包裝的例子，改成這樣雖然沒有違反Law of Demeter，但是沒有什麼意義。
public House {
WeatherStation station;
public float getTemp() {
Thermometer thermometer = weatherStation.getThermometer();
return getTempHelper(thermometer);
}
public float getTempHelper(Thermometer thermometer) {
return thermometer.getTemperature();
}
}
其實所有守則都不是強制的，守則是要對整體設計有益時才遵守。其實就和Design Pattern一樣，當你有需要時才使用。否則盲目的套用一堆OOP守則以及Design Pattern只會導致系統變得複雜，不容易理解。
Pluggable Object是最近在Kent Beck寫得TDD by example中所看到的Design Pattern。其實就是用多型來處理重複的判斷條件。Kent Beck在書中以圖片編輯器為例，在圖片上按下滑鼠左鍵並移動滑鼠表示拖曳圖片移動。而在空白的地方按下左鍵移動滑鼠會出現方框，讓你一次選取多張圖片。這個流程如果寫成程式碼會長得像這樣：
Figure selected;
public void mouseDown() {
selected= findFigure();
if (selected != null)
select(selected);
}
public void mouseMove() {
if (selected != null)
move(selected);
else
moveSelectionRectangle();
}
public void mouseUp() {
if (selected == null)
selectAll();
}
你會發現有許多重複的判斷條件，該怎麼避免呢？這時候就可以用Pluggable Object。
首先先定義一個Interface叫做SelectionMode，這個Interface會有兩個函式分別是mouseMove()以及mouseUp()，並且建立兩個class(SingleSelection, MultipleSelection)實做此Interface，分別處理單一選取圖片以及多重選取圖片。如此一來整個程式碼可以被改寫如下：
SelectionMode mode;
public void mouseDown() {
selected = findFigure();
if (selected != null)
mode = SingleSelection(selected);
else
mode = MultipleSelection();
}
public void mouseMove() {
mode.mouseMove();
}
public void mouseUp() {
mode.mouseUp();
}
程式碼變得乾淨整潔許多，這就是Pluggable Object。
工作狂不是英雄，真正的英雄已經回家了作者認為工作狂代表工作效率差，他們習慣用蠻力解決所有問題，而不去思考好的方法幫助自己提昇工作效率。這點也是我這幾年開始工作後的體會，同樣都是寫程式，高手會試著找尋好的方法來提昇自己的效率，像是使用快速鍵、好用的vim外掛，甚至是自己寫一些工具來改善工作效率。而一般人就如同作者寫得，習慣使用蠻力來解決所有問題，而不是動腦想更好的方法。
大家都知道goto對程式碼是有害的，會造成程式碼難以被看懂。不過goto並不完全沒有用，有些情況使用goto會讓程式碼看起來比較清楚。
由於C的語法沒有例外處理，在處理錯誤時有很多種寫法，我個人覺得使用goto的這個寫法的可讀性比較好。這也是目前我唯一想到適合使用goto地方，你可以在Linux kernel的程式碼中時常看到這種用法：
void foo()
{
if (!doA())
goto exit;
if (!doB())
goto error;
if (!doC())
goto error;
/* everything has succeeded */
return;
error:
/* error recovering */
exit:
return;
}
另一個常用的範例是用來release resource，以下程式碼當檢查vector中的資料是錯誤時，會使用goto跳到release resource的程式碼。
double sum_vector(double *vector1, double *vector2, int *error) {
double sum = 0;
*error = 1;
if(!checkVectorValid(vector1)) goto invalidVector;
if(!checkVectorValid(vector2)) goto invalidVector;
/* sum of vectors */
*error = 0;
invalidVector:
free(vector1);
free(vector2);
return 0;
}
fileReader.DiscardBufferedData(); fileReader.BaseStream.Seek(0, SeekOrigin.Begin); fileReader.BaseStream.Position = 0;
int? x = null; int y = x ?? 5; // y is 5first ?? second語法被執行的步驟如下：
int? a = null, b = 1, c = 2; Console.WriteLine (a ?? b ?? c); // 1善用?? operator可以讓我們的程式碼變得更簡潔，以下是一個範例程式用來計算使用者的年紀，這個例子沒有使用?? operator。
DateTime birth;
DateTime? death;
public TimeSpan Age
{
get
{
if (death == null)
{
return DateTime.Now - birth;
}
else
{
return death.Value - birth;
}
}
}
使用?? operator我們可以把上面的範例改寫成好懂又精簡的版本。
DateTime birth;
DateTime? death;
public TimeSpan Age
{
get
{
DateTime lastAlive = death ?? DateTime.Now;
return lastAlive – birth;
}
}