利用partial快乐驱动开发
生活随笔
收集整理的這篇文章主要介紹了
利用partial快乐驱动开发
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
高效率地開發,不僅僅需要技術,還需要的是一些現實的技巧,相對.NET Framework 1.1中的C#來說,語言中提供的partial關鍵字,可以說是一個偉大的創舉,在真實的業務開發中,很多時間會遇到各類不同的函數歸類整理的問題,盡管在VS.NET IDE中有偉大的IDE標志#regoin...#endregion可以很好地進行分類,但它仍然不是一個理想的模式,很多時候,在只有內部業務處理的情況下,我們更加樂意在一個類里完成所有的功能,而并不想通過創建一系列的命名空間中包括一堆public函數來實現.
這個現實情況也許從純情的對象化思想來看并不完美,但實際上有很多因素讓人郁悶,比較說,比較好的代碼輔助工具CodeRush,它的顏色大量渲染造成了IDE速度地變慢,在一個有上萬行代碼的文件中,打開的速度是非常令人郁悶的.有人也許會說,怎么會有上萬行代碼,難道不能把它們給處理一下嗎?分割成多個文件.這個想法好,但要是在古代沒有partial class的時期,這就會產生大量的問題:新創建的文件類命名為什么?是否合理?代碼分割后,很多地方的代碼要修改為"類名.方法"的形式,能保證對源代碼的修改是安全可靠的嗎?創建一個這樣一個在系統意義上來說沒有單獨存在價值的類是否有必要?
有一些人樂意把其中的可重用函數提煉出來,形成一個新的類,作為一個單獨類的使用,這是無可厚非的,但是,如果要是遇到一堆邏輯是屬于此類的方法,但是因為客觀條件造成的方法太多而造成必須提煉時,應該怎么辦?
不清楚古代的人是怎么處理的,但現代一些的方法,通過partial類不妨是一個很好的方案,大凡類似于業務單據一中的IDE接口一類的,在一個part中,然后此單據不同的邏輯業務就在不同的邏輯中,這樣的好處主要在于效率,不要指望類設計者一開始就考慮好代碼量并且能夠給你設計足夠的類來實現,就現實開發來說,沒有哪個公司有足夠強力的設計者能細致到函數級別地提供設計結構給你,所以最中間的洽入點就是,設計者通過分析師給出來的要求設計出系統結構,并規劃好大致的類及主要的公共調用函數之后,內部的黑盒開發應該是由開發者即程序員自己來決定函數的取舍.
就以前我從事過的項目經驗來說,把類這一步化成了命名空間,分派命名空間及規定的必定實現公共類后,其它的任程序員在命名空間中發揮--無論你怎么發揮,只要不影響我的公共調用就OK.不幸地是,盡管這類的方法是很有效率的,但造成了一個非常巨大的問題就是,命名空間太,using來using去,怎么看也不漂亮,由于命名空間被占用了,更高層次的分割就必須通過命名空間的堆積來完成,這種堆積有時還有一些副作用,比如你在IDE中,查看命名空間時,經常會發現程序員們自己創造的一些古怪的私有空間名稱,本來自由給出了無可厚非,但是,這樣一來,始終覺得心里不舒服,因為如果能夠看見,就容易勾引人的好奇心.
通過partial雖然不能解決"你能夠看見"問題,但是它畢竟挪出了命名空間的地盤,可以使你更好地組織類與命名空間,如果沒有partial,就會僅僅因為"看起來不順眼"的而導致不得不放任一個命名空間給程序員.
partial還有一個更有趣的強大功能就是可以打造白盒式的測試驅動開發,在古老的開發中,一般測試驅動開發有兩種形式,第一種是創造一個測試項目,對項目進行黑盒式處理,這樣的控制很不精細,盡管微軟的開發中提供了變通的私有函數的測試辦法,但是個人認為那看起來"太扭曲",要黑就黑,搞得模模糊糊扭扭捏捏地干嘛.第二種是白盒測試,就是在類內部通過#if..#endif預處理來對測試代碼進行控制,這種好處是無須太多麻煩就可以直觀地對指定成員編寫測試代碼,可以說是一個很精細化地控制,但是同時有一個巨大的問題就是,它這樣的方法,有諸多不良因素,比如首先要在項目內引用測試專用的程序集,同時也造成了代碼的凌亂,盡管#region...#endregion可以解決一部分問題,但仍然不夠爽,理由同前,代碼太多,IDE就太變慢了,不利于有效率地開發.
partial可以部分解決這個問題,說是部分解決是因為無法解決引用程序集的問題,這是必須的,引用程序集的問題只能通過配置比如nant,msbuilt之類的來解決.partial可以解決的問題就是,可以針對每一個片斷類創造一個Test用例類,并用預定義指令進行修飾,在類的結構列表中,命名上有一個小技巧就是不要再命名成"test_methodname"的形式,而應該用"methodname_test"的形式,這樣一來,許多事情就好辦了,在類的瀏覽列表中,由于按字母排序,很輕易就可以看出,哪一些函數有了測試用例,哪一些函數沒有,非常方便.
這個現實情況也許從純情的對象化思想來看并不完美,但實際上有很多因素讓人郁悶,比較說,比較好的代碼輔助工具CodeRush,它的顏色大量渲染造成了IDE速度地變慢,在一個有上萬行代碼的文件中,打開的速度是非常令人郁悶的.有人也許會說,怎么會有上萬行代碼,難道不能把它們給處理一下嗎?分割成多個文件.這個想法好,但要是在古代沒有partial class的時期,這就會產生大量的問題:新創建的文件類命名為什么?是否合理?代碼分割后,很多地方的代碼要修改為"類名.方法"的形式,能保證對源代碼的修改是安全可靠的嗎?創建一個這樣一個在系統意義上來說沒有單獨存在價值的類是否有必要?
有一些人樂意把其中的可重用函數提煉出來,形成一個新的類,作為一個單獨類的使用,這是無可厚非的,但是,如果要是遇到一堆邏輯是屬于此類的方法,但是因為客觀條件造成的方法太多而造成必須提煉時,應該怎么辦?
不清楚古代的人是怎么處理的,但現代一些的方法,通過partial類不妨是一個很好的方案,大凡類似于業務單據一中的IDE接口一類的,在一個part中,然后此單據不同的邏輯業務就在不同的邏輯中,這樣的好處主要在于效率,不要指望類設計者一開始就考慮好代碼量并且能夠給你設計足夠的類來實現,就現實開發來說,沒有哪個公司有足夠強力的設計者能細致到函數級別地提供設計結構給你,所以最中間的洽入點就是,設計者通過分析師給出來的要求設計出系統結構,并規劃好大致的類及主要的公共調用函數之后,內部的黑盒開發應該是由開發者即程序員自己來決定函數的取舍.
就以前我從事過的項目經驗來說,把類這一步化成了命名空間,分派命名空間及規定的必定實現公共類后,其它的任程序員在命名空間中發揮--無論你怎么發揮,只要不影響我的公共調用就OK.不幸地是,盡管這類的方法是很有效率的,但造成了一個非常巨大的問題就是,命名空間太,using來using去,怎么看也不漂亮,由于命名空間被占用了,更高層次的分割就必須通過命名空間的堆積來完成,這種堆積有時還有一些副作用,比如你在IDE中,查看命名空間時,經常會發現程序員們自己創造的一些古怪的私有空間名稱,本來自由給出了無可厚非,但是,這樣一來,始終覺得心里不舒服,因為如果能夠看見,就容易勾引人的好奇心.
通過partial雖然不能解決"你能夠看見"問題,但是它畢竟挪出了命名空間的地盤,可以使你更好地組織類與命名空間,如果沒有partial,就會僅僅因為"看起來不順眼"的而導致不得不放任一個命名空間給程序員.
partial還有一個更有趣的強大功能就是可以打造白盒式的測試驅動開發,在古老的開發中,一般測試驅動開發有兩種形式,第一種是創造一個測試項目,對項目進行黑盒式處理,這樣的控制很不精細,盡管微軟的開發中提供了變通的私有函數的測試辦法,但是個人認為那看起來"太扭曲",要黑就黑,搞得模模糊糊扭扭捏捏地干嘛.第二種是白盒測試,就是在類內部通過#if..#endif預處理來對測試代碼進行控制,這種好處是無須太多麻煩就可以直觀地對指定成員編寫測試代碼,可以說是一個很精細化地控制,但是同時有一個巨大的問題就是,它這樣的方法,有諸多不良因素,比如首先要在項目內引用測試專用的程序集,同時也造成了代碼的凌亂,盡管#region...#endregion可以解決一部分問題,但仍然不夠爽,理由同前,代碼太多,IDE就太變慢了,不利于有效率地開發.
partial可以部分解決這個問題,說是部分解決是因為無法解決引用程序集的問題,這是必須的,引用程序集的問題只能通過配置比如nant,msbuilt之類的來解決.partial可以解決的問題就是,可以針對每一個片斷類創造一個Test用例類,并用預定義指令進行修飾,在類的結構列表中,命名上有一個小技巧就是不要再命名成"test_methodname"的形式,而應該用"methodname_test"的形式,這樣一來,許多事情就好辦了,在類的瀏覽列表中,由于按字母排序,很輕易就可以看出,哪一些函數有了測試用例,哪一些函數沒有,非常方便.
轉載于:https://www.cnblogs.com/William_Fire/archive/2007/08/31/876538.html
總結
以上是生活随笔為你收集整理的利用partial快乐驱动开发的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: C++--深入分析MFC文档视图结构(项
- 下一篇: Get busy living or g