前面有一篇文字談到了：《[全程建模]軟體工程請勿維名詞論》（今天乙個在深圳的弟兄提出了乙個關於原則使用的問題，貼在這裡，總結一句話就是：
實際開發的**中，請考慮你的投入和產出，有很多原則是需要變通使用的，或者說靈活使用的。
樓陽照 21:26:08
哈哈樓陽照 21:26:12
出來~~!!
樓陽照 21:26:30
滿大水了~~~
樓陽照 21:27:11
再潛,小心被水沖走~
青潤 21:31:32
??青潤 21:31:35
怎麼了?
樓陽照 21:31:54
哈哈~終於出來了
青潤 21:31:59
正在解除安裝東西
青潤 21:32:05
你怎麼了,今天這麼高興.
樓陽照 21:32:11
你看過敏捷開發的吧?
青潤 21:32:11
看過.樓陽照 21:32:24
沒有很開心啊~
樓陽照 21:33:00
那個,依賴倒置原則是不是要把介面設計的很好才行?
青潤 21:33:38
那是oo設計原則,不是什麼敏捷.
樓陽照 21:33:58
敏捷裡也有..
青潤 21:34:08
肯定會用到,但是這不是敏捷獨有的.
青潤 21:34:13
這是oo設計原則之一.
樓陽照 21:34:20
恩,樓陽照 21:34:59
知道這個.我是想知道要是介面沒設計好,用依賴倒置是不是會很麻煩?
樓陽照 21:35:10
我用的時候有這種感覺
青潤 21:35:22
我很久沒用了,我看一下我以前的培訓ppt,再給你解釋.
樓陽照 21:35:30
增加介面很繁瑣
樓陽照 21:35:35
好青潤 21:37:56
樓陽照 21:38:23
恩樓陽照 21:38:28
這是原則
青潤 21:38:33
你是打算如何做?
樓陽照 21:38:56
我找到的一點資料
樓陽照 21:38:58
首先要問的是： 依賴真的要倒置嗎？ 客戶真的是上帝嗎？
如果只有乙個**商， 有很多客戶， 誰是上帝呢？
顯然， **商是上帝， 他制定產品標準。
如果有很多**商， 只有乙個客戶， 誰是上帝呢？
顯然， 客戶是上帝， 他主導產品標準。
如果有很多**商， 有很多客戶， 誰又是上帝呢？
顯然，行業協會是上帝， 他制訂產品標準。
如果只有乙個實現者， 有多個使用者， 誰擁有介面呢？
顯然， 是實現者。
如果只有乙個使用者， 有多個實現者， 誰擁有介面呢？
顯然， 是使用者， 他主導介面定義。
如果有多個實現者， 有多個使用者， 誰擁有介面呢？
顯然， 是第三方。
如果只有乙個**商， 只有乙個客戶， 誰是上帝呢？
如果把**商和客戶作為乙個系統看待， 標準應該向系統的核心傾斜。
如果只有乙個實現者， 乙個使用者， 誰主導介面定義呢？
向核心傾斜。看誰是系統的核心。
青潤 21:39:23
呵呵.樓陽照 21:39:32
我在用的時候.發現用依賴倒置.要增加乙個空的虛函式介面
青潤 21:39:34
其實這些原則的使用都是需要靈活考慮的.
青潤 21:39:43
是的.樓陽照 21:40:04
如果沒處理好,除錯的時候哪出錯都不知道
青潤 21:40:30
恩?樓陽照 21:40:44
所以我覺得,要是沒有多個使用者的話.還不如不用
樓陽照 21:41:00
直接new出來好點..
青潤 21:41:01
如果你確定今後就乙個使用者,不會擴充,那就不需要用.
青潤 21:41:12
沒有必要什麼都是原則,要看如何才能更快捷的解決問題.
樓陽照 21:41:28
所以問題就在這.
樓陽照 21:41:43
沒人知道以後會不會擴充套件
樓陽照 21:41:57
也不知道要不要增加介面
青潤 21:42:33
沒有人知道的話,那目前就按照實現效率和效能最快的方式來做實現.
青潤 21:42:52
增加一層介面定義,必然會帶來效率上的影響和開發上的除錯複雜度.
樓陽照 21:43:09
如果全用這個,會很繁瑣.如果不用,以後要重新加回去就要重構
青潤 21:43:30
以後的事情,目前無法定義.
青潤 21:43:45
說不定人家不重構,直接建議領導扔掉你的**重來呢.
樓陽照 21:43:50
你的意思是,等重構的時候來做這個抽象 ?
青潤 21:44:01
到時候再作一次封裝,也是可以的.
樓陽照 21:44:19
恩,那我就明白了
樓陽照 21:44:50
這些方法只是一種理念而已,沒必要非得這麼幹
青潤 21:45:09
當然不是非要如此幹,幹活的時候要根據情況考慮,需要變通的做事.
樓陽照 21:45:21
了解樓陽照 21:45:40
公司有人到死胡同了..
樓陽照 21:45:44
嘿嘿:)
青潤 21:45:41
我們要做的是解決問題,……（此處省略一些話，有些話寫出來太了，青潤自己自動遮蔽）
青潤 21:46:05
原則之上,需要靈活使用.這才是最好的解決方式.
樓陽照 21:46:18
恩樓陽照 21:46:20
了角樓陽照 21:46:21
解青潤 21:46:21
呵呵.樓陽照 21:47:14
今天可以安穩睡了..
青潤 21:47:19
呵呵.樓陽照 21:47:33
昨天翻了整個google
樓陽照 21:48:03
很少有人說這個原則
青潤 21:48:45
唯模式論,唯原則論,為概念論，有其好處,但是,不能過於死板.否則,就是自尋死路.
青潤 21:48:57
畢竟我們不是搞研究,我們是做軟體成品的人.
樓陽照 21:49:17
同意~樓陽照 21:49:52
好處很多.壞處也有,看自己怎麼用
青潤 21:50:18
呵呵.樓陽照 21:50:24
在遊戲公司呆了一年,學了c++
樓陽照 21:50:26
呵呵樓陽照 21:50:56
還沒學會用c oo
青潤 21:51:23
恩.樓陽照 21:51:48
不打攪了:)
青潤 21:52:02
早點休息吧.我還在裝乙個東西.
樓陽照 21:52:29
謝謝白老大~哈哈~~我夠客氣吧:)
樓陽照 21:52:39
恩青潤 21:53:18
呵呵.
再談開發人員和測試人員的比例
人 們經常還是喜歡糾纏在一些具體的數字上，特別是西方人更是喜歡用資料說明問題，因為那樣客觀 具體，但同時也往往將人引入歧途，容易形上學，因為每個公司 公司的每個產品 產品的各個專案或各個階段都不同，沒法用一刀切的辦法。在軟體企業，面對測試經理，常常被問的問題是 你們公司的開發人員和測試人員的比例多少...
技術討論 關於低耦合開發的討論
技術討論 關於低耦合開發的討論 丁丁 15 15 50 求知誰體會過低耦合帶來的好處我怎麼覺得現在接觸到的專案都是遷一發 動全身呢 青潤 15 17 03 你是全新專案，還是歷史專案改造？丁丁 15 17 19 新的繼承抽象和介面的方式完全體現不出多麼易於修改 丁丁 15 18 38 只要有變更涉及...
工作兩年 再談開發人員的「職業規劃」
這兩天空虛，感覺肚子裡有苦水，吐啊吐的，居然越發的難受。跟老大聊，老大指出一些缺點，然後感覺 大概是自己技藝不精，學習乏力 導致了對自己的失望與懈怠。跟身邊人聊，家長里短 雲濃風黑，然後感覺 大概是生活瑣事過多，應接不暇 導致了自己的不滿與憤怒。猛的一瞬間意識到，原來是因為工作迷失了方向 工作滿兩年...