|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-08-31
这块最先在Avalon框架中提出
下面有文档 http://www.jieesoft.com/midwinter/chinsesdocs/articles/avalonchinese.html |
| 返回顶楼 | |
|
发表时间：2004-09-02
Trustno1 写道 PS:物理学从来不揭示这个世界的本质。物理学所揭示的只不过是这个世界上某些现象所呈现出来的数据关系而已。量子力学就是最典型的例证。量子力学从来没有揭示过微观世界的本质，他不知道他们观测到的到底是十么。量子力学只是说，他观测到的数据是十么，这些数据之间有十么关系。所以那些波动说，粒子 说其实统统的都是胡说八道。微观世界到底是十么，没有人知道。以爱因斯坦从来不相信这套，因为他是一个确定论者，更加是一个本质论者。 从我的观点看，物理学所能解决的是How的问题，why的问题只能由上帝来回答。 事实上并不仅限于物理学，人类所研究的任何一个学科都只是揭示这个世界上某些领域的某些层次中的某些现象所呈现出来的数据关系而已。每一项科学理论都必然是从现实世界中一系列具体现象所呈现的数据关系归纳演绎出来的，那么我们是不是可以说科学研究揭示的只是现象，而不是本质？ “微观世界到底是什么，没有人知道”，这句话很有趣，由此可以推导出并不仅仅是微观世界，无论是宏观世界还是什么观世界都没有人知道是什么，即使你看见的东西你实际上也不知道是什么，因为你所“看见”的影像只是你的视觉神经对物体反射光产生的脉冲信号而已，你所了解的仅仅是物体所呈现出来的光属性，你凭什么说你了解这个世界？仅仅是因为别人看到的东西与你相同？ 为了避免无谓的争执，先学习一下科学本质。 引用 科學的本質 魏明通 教授 國立台灣師範大學化學系 趙金祁對科學的本質及其成分，在其著作《自然科學原理在科學教育上的意義》有詳盡的介紹： 一、事物發生中，時空物質的侷限性 人類知識固然誰時代的進步而突飛猛進，一日千里，但人類對時空物質，這類實質的了解，到今日仍有限。甚至包括生命現象在內，都無從窺其全貌。因此科學家必須承認，知識的程度僅及於經驗證據所涉範圍之內，強力摒棄不知為知的意念。科學家對於臆測、假說、假設、模型、假說真理、思維真理等界限分明，即表明白對各別問題程度的不同，不容混淆。 同時，在求真過程中，科學家始終權宜運用逐步逼近的法則，以求由近及遠，由小至大，漸進了解，趨近自然的終極真理。\r 二、自然律的一致性 科學家一致承認，大自然間的千變萬化，必定由一個一致的、有序的，和統一的自然律所支配，即所謂的再現性。因此在相同的情境下必產生相同的現象。此種由自然律支配自然現象的特性，正是科學家與迷信的重要區別關鍵所在。科學知識由反覆出現中，獲得實驗數據，以量化證據說服大眾；迷信卻只屬於少數人的感受，既無再現性的可能，更無法提供證據取信於人。 三、因果關係性 本質上，科學家認定現有事物，必在功能上與過去事物相互關聯，即在特定因素上，有某種程度的因果關係。因此，科學家除描述與說明現有事物外，亦能憑藉對事物所以形成各種因素之了解，預測可能發生的新事物。 四、事物的可理解性 科學家堅信宇宙的一切事物，可由人的知覺感受、意識運作、設備器材、與剖析能力，加以理解。進一步，還可經由科學方法，獲致預測一切未知事物的寶貴知識。科學家深信過去的科學既能提供人類解決生存問題的條件，將來勢必亦能帶給人類無比力量，求取自身在物質世界中的生存機會。\r 五、生存環境的長遠價值觀 科學是人類文化的一部分，基本上應在人生理想與社會規範的要求上，求取發展與成長。不過，科學之進步，往往衍生人類生存環境的改變，造成環境污染與資源貧瘠等問題。因此，科學家既認定宇宙是有秩序而和諧的，自當維護人類與物質間，個人與自然間，個人與他人間的有秩序特徵與和諧關係。也就是說，科學工作應以維護生存環境的完美為重，力避任意破壞生存條件而招致人類的噩運。\ 六、探究事物的傳統性 科學研究的問題與工作，具傳統性。自古以來師徒間研究題目及成果的相應承襲上，時常見到。科學研究的方法，譬如，歸納與演譯、直觀與分析、假設與求證等，都行之有年，歷久彌堅，代代相傳。 七、知識本體的不完整性 人類不斷創立各種理論，以描述、說明與預測自然界所發生的各個現象。不過，因為科學只能在自然間，擷取片斷的資料，呈現自然真理。因此，到目前已建立的理論中，不僅甚多假設性或臨時性的理論，而且彼此間，還存在不少無法彌補的空隙，暫時由假設、形成模型等加以墊補，以保未來的求證，修改模型，取捨假設，進而推出更為完整新理論。因此，科學家只能經由不完整知識的過程，不斷發掘問題，解決問題，以達更趨完整的目標。 八、事物表象的存疑性 根據科學典範咸由某種立足點出發的道理，盛行一時的任何一個典範，必有其範圍與極限。超出典範的界限，必引起爭論，導致新典範的產生。因此不能斷定，科學發展的主導因素是，無窮的質疑與不斷的探討。科學家在存疑的基礎上，推動科學的發展。準此，科學家所崇尚的大膽假設、小心求證，以獲得新知，所必要的前提，即在於存疑與適當提出問題上。 九、認識事物的客觀性 客觀是指存在於心意之外，具有實在與實證的理性意義。這就是說，科學的所以成為科學，係因其具有獨立嚴謹的客觀性，與個人的情緒、愛好、希望、價值、需求等無關。 十、理論上的節儉性 大多數科學家都深信，自然界的基本原理、原則必定極為簡單，認定大自然中各式各樣的個別現象，可由簡單的敘述或數學公式，加以貫穿、詮釋與說明。卜帕 (K.R.Popper)從反面指出，容易為科學接受的簡單原理、原則，必屬可適應更多經驗實證的學說。當然，這樣簡單的原理、原則，可能遭遇反證機會增加，因此，原理、原則的節儉程度直接與反證次數成正比，越節儉的，必涵蓋越形龐雜的範圍，而在科學界的邏輯推理標準上，佔最強勢的地位。 |
| 返回顶楼 | |
|
发表时间：2004-09-02
基本没有太大的问题。只是标准太多了一些，
我看只要留下 自然律的一致,因果关系,事物的可理解 三个修饰。 再加上一个定义:科学是一种说话方式，就足够了。 从新整理一下就是:科学是一种说话方式，这种说话方式满足自然规律一致性(主体无关性),满足因果律性(或者概率)，事物的可理解(事物指称性)。 |
| 返回顶楼 | |
|
发表时间：2004-09-07
看不懂没关系，正好证明你是一个不错的面向对象设计专家，这篇文章不会谈论如何使用设计对象原则、框架或者设计模式之类你所熟悉的东西。我要说的东西如果不是在对立面，也会是在另外一条岔道上。
先说一说终极目标吧 典型软件开发过程生命周期模型： 需求分析、设计（概要设计和详细设计）、编码实现、测试 终极软件开发过程生命周期模型： 需求分析、需求形式化、运行测试 同意，如果需求可以形式化，那么我们也许并不需要面向接口编程。因为需求是明确的，我们只要实现它就可以了。所以，准确抽象问题比面向接口编程更重要。面向接口只是一种编程哲学，并非科学，因为它并没有严格的数学理论支持，甚至没有一个有利的统计数字支持，所以我们可以相信它，也可以不信它。 age0 写道 如果终极系统拥有相当于优秀开发工程师的智慧和知识的话，需求形式化的工作也应该可以一并省略。
这个我想一百年之后再讨论也来得及的。 
|
| 返回顶楼 | |
|
发表时间：2004-09-07
age0 写道 我要说的东西很杂，很多，也很乱，目前还无法成体系。
gigix你不如先说一说你所关心的业务逻辑问题，业务逻辑确实比较复杂，要把业务逻辑分解成有限的对象不是一件轻而易举的事。 这样吧，你来提业务逻辑需求，我来写代码。 我上面写的代码很重要，没有这些代码的支持是无法实现业务逻辑自动化处理的。 工作流+powerbuilder？你要做好打败微软和IBM的准备。 |
| 返回顶楼 | |
|
发表时间：2004-09-09
age0的这种思想，在软件上已有什么发展吗！？
|
| 返回顶楼 | |
|
发表时间：2004-10-18
楼主看没看过<重构>
那本书呀, 这个原则如何应用那上面谈得很清楚了, 如果把设计模式乱用, 那所有的模式都没有什么用, 只能增加复杂度 |
| 返回顶楼 | |
|
发表时间：2004-10-18
dearmite 写道 楼主看没看过<重构>
那本书呀, 这个原则如何应用那上面谈得很清楚了, 如果把设计模式乱用, 那所有的模式都没有什么用, 只能增加复杂度 重构确实不错，但从上帝的观点来看，这依然是舍本逐末的做法。 想想吧，如果上帝也和我们一样热衷于重构的话，我们所处的这个matrix一天不知道要reload多少次。 |
| 返回顶楼 | |
|
发表时间：2004-10-30
楼主太可爱了，长篇连载可不利于大家讨论啊，说得太散乐，
其实开头几篇还有感觉，后面觉得不知道你把方向盘扳向哪里乐，blush。 所以只谈谈开开头几篇得感想。 首先，楼主把需求简单化乐，当然，当讨论问题得时候，还是先用简单例子来说明得好，不然光需求就把大家搞晕乐。 楼主提供得例子太过理想化乐，那么简单，我怎么实现都可以，而你却需要在后台先实现一个引擎来支持你的代码，这里的复杂度你不考虑当然会好说话乐，我还说，最好是程序员用脑袋想想，然后电脑就自动编码完成最好乐，可惜这样的系统我们是等不到用乐。 我的观点是这样的，无论是什么方法论，其根本目的是解决问题自然不必说， 我认为所有的方法论都是可以解决所有问题的， 但是，关键是如何解决以及解决问题的效率。 楼主有没有想过，面向对象是通过什么来解决问题，并且提高解决问题的效率的？ 而你提供的例子，又是如何解决问题的，是不是能在非常复杂的条件下高效率完成需求？ 在理想的简单情况下，也许你的方法非常漂亮（呵呵，其实我认为并不漂亮，因为你完全不考虑引擎的实现，要实现你所需要的引擎，我不知道你应该怎么去做，我想是不可能象你写上面那个例子的需求那样的乐）， 但是一旦问题复杂化，你所得到的东西将是极难维护的（当然，如果你又采用其它方法来把你复杂后的代码重新封装就另当别论，不过，到时候你会采用什么方法去重构呢？）， 简单地说，用户要实现如下功能， 还是接你上面地例子，现在用户说，诶，我们已经有一个现成的资料库乐，以后那些资料不用我们输入乐，你们从目标库检索出来记录，然后让我们选一下好乐，为了增加复杂度，我们假设目标数据库是个海量数据库，姑且就按每年100万的增长率来好乐，并且用户需要的资料要从10张表关联获取，还要过滤用户对每条资料的权限，没有权限的资料是不能让用户看到的，我忘了你上面列举乐几个字段，我假设少点吧，就a、b、c需要过滤权限好乐。 然后用户说了，（其实这个我们自己随便想也能想到），最好是做成上下2个表， 下面是检索出来等待选择的记录，上面是原来录入的表格， 然后从下面选择记录来完成录入操作。 当然乐，我们这个是B/S的系统，要不然用户也不需要我们重新做乐。 就以上这样简单的需求（注意，真的还是比较简单的需求）来说，不知道楼主如何来完成，注意，效率不止是编码的效率还有维护、测试等等，基本上这样的需求完全完成所需要的成本最小化是我认为的高效率。 |
| 返回顶楼 | |
|
发表时间：2004-10-30
接着谈
楼主有没有想过依赖倒置的目的， 我想你要批驳它就应该批它的本质，而不是在边边角角挑刺， 因为基本上所有东西都是有依赖环境的（还包括我这个时候在这里说这句话，^_^），因此，如果你通过给依赖倒置换个环境来批驳，基本上我认为等于没说， 比如，我基本上认为依赖倒置是设计级的东西，无论如何，再怎么样，也是有需求先，才好设计，不可能没有需求就搞这么多事情，注意，我这里说的需求包括有时候为了将来考虑而假设的需求，就是说，无论怎么样你要提供过目标或者其它什么的任何东西来说明你需要实现什么，然后我们才来谈设计。 而看楼主你的例子，基本上我的理解是这样的，你想通过描述需求，然后由一个引擎解析并实现或者说执行你的需求脚本来完成系统的建设， 不知道这样理解对不对，反正看你的例子是这样，你唯一不考虑你的解析引擎的复杂度。 好乐回来说正题，我认为依赖倒置的目的是解耦，如果你出于其它目的使用这个原则，我觉得都没有必要好说的乐，当然，如果你遵循这个原则却发现结果并没有达到解耦的目的，那我觉得是因为没有理解并正确使用这个原则。 |
| 返回顶楼 | |
