發信人: gentboy (老流氓，老水車，老男人就是快樂的一家), 信區: Java
標 題: 填坑：oo的前世今生及后世
發信站: 水木社區 (Fri Apr 18 13:27:06 2008), 站內
摘要：需求一直在擴展，邏輯復雜度以更高的速度增加，而人的邏輯處理能力沒有任何變?
。oo解決了一個stage的問題，但是類似于軟件危機的問題肯定還會出現，期待新的邏輯或
者工具來解決這個問題。
N多年前，軟件危機的出現基于三個事實，一個是需求迅速增長，功能要求越來越多；再者軟件的復雜度并不是與軟件的體積成正比的，復雜度的增長速度要遠大于代碼的行數的增長速度。
還有一個沒有被強調的原因就是，人的能力是有限的，對于復雜的軟件，沒有任何一個人能掌握所有的邏輯，即使他了解所有的邏輯，也不可能同時考慮到這些邏輯。因此，人們在編寫軟件時，只能在有限的視野內工作，這種情況本身就決定了軟件中的缺陷難以避免。
oo被認為是解決軟件危機一個比較好的方法，主要原因就是oo將整個軟件中的大量邏輯和數據封裝起來，從而使得程序員不必關注所有的細節，而只關注與自己負責的部分有關的細節。這大大減輕了程序員的負擔，從而也使軟件規模得到了較大的擴大。
但是，需求仍在繼續增長，而且邏輯的復雜度又以更快的速度增長。用oo編程的程序員們漸漸感覺到即使大量的邏輯被封裝了，剩下的要處理的邏輯仍然足夠復雜。
而且，oo也是一把雙刃劍，如果封裝的方法不當，同樣會給別人的開發造成麻煩。而且不同的程序員往往對同一個應用有著不同的理解。這使得協作中的沖突很常見。
因此大量的針對具體應用的framework出現了，比如orm, ejb, struts等等，這些framework從某種程度上定義了某種具體應用的范式，把應用中有共性的部分拿出來，而讓程序員做那些有特性的東西。這又讓程序員少考慮了不少東西。
到目前為止，framework的確起了不小的作用，也出現了很多超大型的framework，能讓程序員寫很少的代碼就能完成原來可能要18個人干半年才能完成的任務。
但是，framework也有其本身的缺陷，一個是framework往往本身就足夠復雜，難以學習已經是一些大型的framework的通病。另外framework本身也有質量問題，過分依賴或者不正確的使用framework的后果同樣是致命的。
framework替你做的事情越多，程序員往往就越難以使用它，但是如果他做的東西少，程序員就會喊自己做了很多重復勞動。因此這兩者之間要有一個平衡。從這個角度來講，spring做的比jboss要好。
展望將來，需求的規模還會繼續增長，而邏輯的復雜度仍然會以相對于需求的復雜度的指數形式增長。但是人的腦子跟幾十年前沒什么區別，還是同時能處理那么多邏輯。尖銳問題肯定會出現。
但是解決問題的方法呢？單單靠語言特性恐怕已經難以再做什么。人們應當再次反思程序這個概念本身，提出新的解決方案?；蛟S人們會開發出更為實用的framework以定義業務邏輯，更為智能化的集成開發/協作環境工具來擴展我們的大腦，或者其它...
--
晶晶姑娘是個好姑娘
※ 修改:·gentboy 于 Apr 18 13:28:32 2008 修改本文·[FROM: 210.13.85.*]
※ 來源:·水木社區 newsmth.net·[FROM: 210.13.85.*]