Visual Studio 2010 and .NET Framework 4.0 CTP download link

正式地來說，應該download here, 可惜該網頁的 download mamanger.

 

應急地，只好直接以 http 下載了。
下載後，需要帳號及密碼，請看 Q7

Windows 7 的 UAC

Windows Vista 的 UAC，一直是我所喜愛的功能，雖然它會不斷的跳出對話框來打斷我。但為了防毒，心干情願矣。
但看來很多人仍習慣 XP以前的超大權限，一點也不怕病毒。(我在氣勢上就輸了)

Windows 7 的UAC則多增加了設定。有四個層級可設定彈跳視窗

1. 永達詢問。詢問時等待使用者的回應，此時其他程式的視窗全部不見了。此相當於 Vista 的預設值。
2. 當程式或使用者修改設定時，但不會停止其他程式的運作。也就是說仍然可以操作其他的程式。
3. 使用者修改設定時，不會受到中斷。但程式要修改Windows 設定時，才會中斷並詢問使用者。此為 Windows 7 的預設值。
4. 永不詢問。此相當於XP以前的設定。

個人喜好的問題，還是1，也就是最嚴格的設定。
3 則是微軟最大的讓步了呢。此當作預設值果然是符合行銷的手法。

如果您選4，那就代表您真的很有勇氣了。

 

LINQ to SQL 在 SQL server 2005 與 2000 執行效能大不同

使用一模一樣的資料庫，一個 run 在 SQL Server 2005, 一個則是 SQL Server 2000。
開發時使用 Linq to SQL連線到 2000 的資料庫。
執行時分別連線到  2000 及 2005.

發現執行的結果是一樣的，但使用 profiler 看到的 sql script 卻完全不同。
由於目前測試的是客戶的專案，不能放到這裡來公佈。

只能說，SQL Server 2000 趕快放棄吧。

OOAD(14): OOAD Project Life Cycle

1. Feature List
2. Use Case Diagrams
3. Break Up the Problem
4. Requirements
5. Domain Analysis
6. Preliminary Design
7. Imlementation
8. Delivery

OOAD(13): 程式開發方式

所有的程式寫作的開發方式，其實都是下面三個的混合

Use case driven development

一次針對一個 Use case 下一個 scenario 進行開發。再逐步完成該Use case 下所有的scenario。完成該Use case 下所有的scenario後才對下一個 Use case 開發

Feature driven development

一次對針一個系統行為的特色來開發。

Test driven development

針點系統的一個功能寫出 test cases。寫程式的目的就是通過所有的 test cases

OOAD(12): 三種不使用繼承的好方法

如果不透過繼承，又希望從別的類別得到好處。可使用

1. Delegation (委派)
2. Composition
3. Aggreation

Delegation (委派)

一台轎車，如果想要可以欣賞音樂的能力，不是透過繼承(畢竟車子不是音響)，而是在車子內加裝汽車音響。
因此，轎車內需要放音樂的能力時，只需要打開汽車音響即可。
class 轎車
{
  private 汽車音響 a汽車音響 = new 汽車音響();
  public void 欣賞音樂()
  {
    a汽車音響.打開();
  }
}

或者，隨時找到一台音響再打開

class 轎車
{ 
  public void 欣賞音樂()
  {

    汽車音響 a汽車音響 = new 汽車音響(); //隨時想有就可以有？這大概是軟體世界才有的能力
    a汽車音響.打開();
  }
}

Composition

一個士兵，需要有攻擊的能力，但士兵畢竟不是武器，因此士兵需要有武器。到目前為止就像委派。
但是，武器有許多種，如飛彈、槍、劍，每一種的攻擊方式都不同。

注意到 weapon 是可替換的，只要有實作 IWeapon 的武器就可以。換句話說，一整族IWeapon的武器都可以替換。
另外，weapon 是天生就存在於 Soldier 內的。一旦 Soldier 被 destoryed, weapon 就不存在了。

class Soldier
{
    private IWeapon weapon = new Sword();
    public void Attack()
    {
      weapon.Attack();
    }
  }

  interface IWeapon
  {
    void Attack();
  }

  class Sword : IWeapon
  {
    public void Attack() { }
  }

Aggregation

aggregation 與 Composition 類似，但結構更鬆散，更容易 resuse。上述的例子，weapon 只能生存在 Soldier 的生命週期內，並不合理。如果改成下面的例子，就是 aggregation 了。注意到 weapon 是由建構子傳進去的。當soldier1 被destoryed 後，sword 並不隨之消減。也就是說，可以被 soldier2 再拿去用。

class Soldier
  {
    private IWeapon weapon;
    public Soldier(IWeapon weapon)
    {
      this.weapon = weapon;
    }
    public void Attack()
    {
      weapon.Attack();
    }
  }

  interface IWeapon
  {
    void Attack();
  }

  class Sword : IWeapon
  {
    public void Attack() { }
  }

class Program
  {
    static void Main(string[] args)
    {
      Sword sword = new Sword();
      Soldier soldier1 = new Soldier(sword);
      soldier1.Attack();
    }
  }

在日常生活上，Aggreation 遠較 Composition 多見，這同時也反應到軟體工程上。畢竟物件導向工程是模擬真實的世界。

OOAD(11):Liskov Substitution Principle(LSP)

LSP (替換原則) 是談何謂「良好的繼承」。

• 子類別應該可以使用其基礎類別替代，而不會發生的誤。如果會發生錯誤，就代表使用繼承失敗。
• Liskov代換原則是繼承之所以能重複使用的基石，只有當衍生類別可以替換掉基礎類別，且軟體的功能不受影響時，其類別才算真正的被重複使用，而衍生類別也才能夠在基礎類別的基礎上增加新的行為。
• Liskov代換原則要求凡是基礎類別使用的地方，衍生類別一定適用，故衍生類別必須包含全部基礎類別的介面
• 針對違反LSP設計時可行的重構(Refactoring)方式
  • 當類別A錯誤的繼承類別B時，可建構一個新的抽象類別C，作為2個具體類別A,B的父類別
  • 當類別A錯誤的繼承類別B時，可重構為類別B委派(Delegate)類別A

 

from http://irw.ncut.edu.tw/peterju/se.html