想起來之前的時候,看到think in java 裏邊寫的關於類和它的成員類,可以雙向維護一個功能.
當時只是想着看上去確實是這樣,書上說這是一個比較好的功能,我並沒有看到那種特別好.
最近在做C#的一些項目,看着用框架的話,從前端接收的數據回被自動填裝到action方法寫明的類參數中,和類的成員變量名及類型相匹配.大概是把字符串轉換成相應的類型並根據參數名匹配. 這個類一般只是一個接收參數的模型,裏邊有一系列成員和前端對應,除了get set 沒有別的方法. 這裏,如果需要去掉傳遞過來的參數的空格,trim()一下.這個操作可以在處理action的裏邊進行,也可以直接寫進模型類裏,直接模型類.trim()把所有需要去空格的參數都去一下.
去首位空的功能就很好地被關聯到了模型類上,在action中調用這個模型類的方法就可以,看上去比較簡潔好理解.這大概就是雙向維護的意思:這個功能可以放在使用類的地方寫,也可以封裝到類裏邊到時直接調用.而且很容易找相應的處理,以後如果有變化的話也容易更改.
另一種情況,遇到的,是在使用類的方法中需要對臨時類進行一系列處理,處理比較多,使用頻次也比較多,於是在方法外單獨寫一個私有方法來處理,很多方法都可以用這個功能.如果這個功能和被使用的類相關性很強的話,比如傳遞的參數大多都和該類相關,可以直接把這個方法寫進被使用的類中.這樣就不用傳一些和類相關的參數,直接傳其它輔助參數就可以.調用起來也比較清晰.
之前被告訴 那些編程思想的書,不適合初學者.現在看來可能還真是這種情況.一般都是在編程中思考遇到問題,總結的一些問題該怎麼處理,如果沒有碰到過只能聽個過場的樣子.不過居然能讓人還存有印象,應該也算是寫的比較好了.
實際代碼裏我沒有把"另一種情況"寫進類裏,直接在action裏寫了相應的功能.於是每個類似的action都粘貼複製一段代碼.牽扯的東西有些多,有點改不動了,只是想到可以這樣.
開發一天到晚在做功能,並不在乎性能,在乎快速實現,老闆等着驗收.如果短時間內沒完成,基本上短時間內就被砍掉了.快節奏的變化裏,沒有時間去想編程的事.不是很容易遇到相關的討論.
有些編碼裏還在講究着這些,看一些前輩寫的代碼,做的功能.或許沒有考慮這些事,只是被教會的習慣和規範.用最小的數據類型傳遞過網絡,批量字符串拼接用輔助類而不是加號,相同的功能維護到一個方法中.其中有些講究並不是不去做,是在有限的時間內做不到.想包裝包方法就比較考驗人.對功能的分類.
大概編碼有實現功能和功能分類,把合適的代碼放到相關的筐子裏,程序就容易拓展維護.再加上有些習慣是對計算量的講究,對運轉性能的講究,讓代碼看上去比較舒適.
寫代碼有一些顧慮,除了怎麼實現功能,還有怎麼把功能放到合適的位置方便拓展,怎麼佔用較小的計算和緩存資源來確保程序的健壯性.功能 分類 和精化.後兩者不怎麼影響開發,是一些有趣的思考的積累.另外加上業務功能的實現方式,也就是業務運轉框架在軟件中的組成實現方式.讓編程顯得既有困難,又有很廣闊的探索空間.
很期望有更多機會去探索這個空間,可以讓自己變得更強大,不依賴裝備的情況下擁有更高的輸出.