感想-收拾殘局

要求自己一定要做個紀錄，其實還滿難堅持的
當然，能都把所經歷過的事情
詳細記錄下來，這樣是最好的，但事實卻不是那樣的稱心如意

今天，我想寫一些想法
寫程式也寫了一陣子了，不算長、也不算短的時間
常常會面臨到要去看別人程式
去維護"前人"寫的程式

好的程式，你一眼就可以很一目暸然
詳細的註解、功能清楚的劃分、物件導向的設計
以及最重要的一點[每段程式碼都是簡短的!]
今天，若是將幾百行程式碼放在你的面前
你要怎麼看?

正常來說，你必須從頭看到尾
所以會演變到你若要更動其中的程式
情況好，只要更動一小部份就好
但是萬一整個邏輯更動
就會發生[牽一髮而動全身]的窘境
聽到我這樣說，曾碰過這樣情形的人
應該已經會心一笑了!!
接下來你就會發現，你不是在維護程式
而是在重寫程式。。。

現在我寫程式都是掌握幾個要點
1.用物件的觀念來思考架構，但不急著動手去Coding，
詳細考慮過後，才會著手進行。
2.程式碼區段不超過30行以上，若是過長的程式區段
，會想辦法再抽離出來。
3.註解盡量詳細，若是Method的參數已經很明瞭
，就不需要註解。
4.要設想未來可能所發生的問題，
你無法實際掌握可能發生的情況，但你可以設法去猜測。
5.要愛用Namespace，程式碼中也多用region。
6.….等

會有這樣的想法，是因為今天我正在重寫
某位仁兄的程式碼，他的一個Method區段
就快300多行。。
他的程式碼是長這樣的

//Step1

....程式碼

//Step2

....程式碼

//Step3

....程式碼

//Step4

....程式碼

//Step5

....程式碼

//Step6

....程式碼

//Step7

....程式碼

看到這，是否已經可以體會我心中想說的?

Class 設計

這個網誌，也空了一段時間
因為之前為了準備考試，再加上工作的忙碌
回到家就幾乎不想再碰電腦(懶的打字 ^^")

只是，這樣並不是很好的習慣
有些事情真的要當下記錄下來。。。
看著之前所寫的紀錄，雖然有很多地方有誤
但這些紀錄讓我明瞭，曾經做了哪些事情
至少再走過同一段路時，可以提醒自己曾經做了哪些抉擇。
廢話少說。。紀錄一點心得

-----分隔線------
最近在撰寫程式的時候，開始漸漸使用Interface來設計物件

假設，我今天要設計Message Class(有許多類型)
遇到的一個小問題是:
今天若有多個不同種類的Message Class，
當然Member也一定會有所不同，我如何確保這些Message
維持在同一個規範下?

我想到的解決方法如下:
1.建立一個抽象類別當作是Message的基底類別。
你可以選擇實作成員，或是建立抽象成員
當繼承這個抽象類別時，也須遵守實作抽象成員。
例如:
建立抽象類別(MsgBase)，
Message1繼承這個抽象類別並實作抽象成員

握

   1:      public abstract class MsgBase

   2:      {

   3:          public abstract string Name

   4:          {

   5:              get;

   6:              set;

   7:          }

   8:   

   9:          public string GetMessage()

  10:          {

  11:              return "My Message!";        

  12:          }

  13:      }

   1:      public class Message1:MsgBase

   2:      {

   3:          private string NameField;

   4:          public override string Name

   5:          {

   6:              get

   7:              {

   8:                  return NameField;

   9:              }

  10:              set

  11:              {

  12:                  NameField=value;

  13:              }

  14:          }

  15:      }

Message1這個Class則有(Name、GetMessage)這兩個成員，
藉由繼承的概念來規範。

2.利用Interface來規範。
當繼承Interface時，必須要實作Interface的成員
這樣也同樣可以規範出這個Class的框架。
而Interface的好處，則可以藉由操作Interface
來達到目的。

例如:
今天我得到一個Object，我不確定他是哪種Class
但我知道這個Object繼承了我所得知的Interface
可以藉由操作Interface的方式，同樣也可以達到效果。

   1:  ISerialize mySerialize=o as ISerialize

   2:  mySerialize.Serialize();

我亂寫到這，其實學習設計物件
經驗還不足，不過慢慢懂得一點點

介面導向設計(interface-oriented design)

前陣子，在最常逛的Blog裡
看到這篇文章
小朱的技術空間 - 邁向架構師的暖身運動(1)：介面導向設計
剛看標題，我以為是我看錯了
介面導向設計??  不是物件導向設計嗎??

後來，看完整篇文章
我有點被打醒。。。
對阿~沒錯
介面導向設計。。。

我相信應該有人跟我有同樣的疑惑
在設計一個物件時，有需要或必要再設計Interface嗎?

對我這個新手來說，一開始接觸Interface時
我充滿了許多的疑惑?這是用來幹麻的??
Interface只是定義了成員的原型，又沒辦法直接在Interface上實作
對物件來說，這有其必要性嗎?

就在Coding的一小段時間裡，我漸漸了解了Interface
在一個複雜的物件中，Interface就有其存在的必要性
甚至在最近看的WCF中，也使用到Interface的特性

文章中提到，關於資料庫的CRUD (Create/Retrive/Update/Delete)
這是一個很基本的實例。
是的，每一個資料庫會使用到的基本功能會是這些
當你設計了關於Oracel資料庫的物件
那SQL Server呢?是不是也需要重新設計相同的功能(CRUD)
使用Interface可以實際的規範出這些原則
讓相似的功能，有了統一的規範

又因為C#在物件繼承中，可以繼承多個Interface
這就讓物件上的設計，藉由繼承多個Interface來完成功能實現
意思是你可能藉由繼承Interface而設計出複雜物件的架構
當然你還是需要去實作。。。

簡單寫到這，或許以後可以再補述。。。