――――――――――――――――――――――
没有一定的权威（专制）性，怎么领导这么多的技术叼棍！
――――――――――――――――――――――
没有一定的权威（专制）性，怎么领导这么多的技术叼棍！
你好。
我做了2年的开发了。不过，从2000年开始，就开始研究（或者说学习）java。
我喜欢哲学，喜欢中国古典文学，喜欢史学，虽然自己研究的不是很深，但就如我喜欢java一样，喜欢他们。
(我认为我们中国的文化，实在太深奥了------关于这个我还要写文章,我真不理解为什么,国家不搞我们自己的文化,虽然有些问题,但我们能够选择性的学习)
另外，我觉得编程几年不重要。
为什么这么说？
有句话叫有志不在年高！
这句里也可套用。
搞了很多年，如果搞得不深入，还不如一个入行不是很久，但研究深的。
不知道你同意否？
很感谢你!你让我感觉到写文章写对了.
windjp ：
我觉得一个搞软件的，如果不懂些数学，那是不太完整的。
第一，就软件开发和解决数学问题这两个事情的本身来说，他们是有很多共性的。
比如解决问题的能力，和解决问题的思路。
第二，离开了数学，做设计是要出问题的。
我们都明白，程序是从数学里出来的。
很多问题，如果没搞过数学,很难想象这个问题怎么解决。
数学在程学设计里有着极其重要的地位。
但，程序设计不是纯粹数学。
对象间的关系，一般不需要特别复杂的数学知识----------也许，我没接触到那个领域。
在设计时，重要的是把事物的关系理清。
设计的目的是什么？是为了实现。
什么扩展性 伸缩性等问题，都不是主要的！实现才是主要！
那些都是附带出来的问题。
那么我认为，设计的时候，不能只做设计，
也要考虑一下这个设计方案的可实现性以及其复杂性-----为编码者考虑。
一个好的设计方案，其前提是容易实现的同时，又能满足其他要求，比如压力和可扩展。
当然，有时候，可能会有冲突。那么可以根据重要性，在这些冲突之间找到一个平衡点。
所以，如果不懂数学，也不懂开发，这样的设计者设计出来的方案，我认为很可怕的（如果不是很简单的业务）。
我觉得我还是个菜鸟。
我的话仅仅是一家之言。
如果没有banq的言论，我的那篇文章很难写出来。
如果没我的文章，你的评论说不定也不会那么快出来。
所以，我感谢banq,同时也感谢你。
你提的问题很好，我本身把数学基础作为软设开发者的本能了或者说必备能力，所以在写的时候，没有再拿出来。
我觉得不太像!
banq的做法可能太过.
如果能开出一个非技术论坛
那就好了.
把非技术性问题都扔过去-------而不删除.
这个建议以前有人提出过,我今天再提一下.
> ry就够了,我想从XML构建对象总比从数据库强吧．一开机，把
> ML文件倒进内存，一关机把内存到出到XML文件.如果Flash内?> 足够快，足够便宜，我看内存都不需要了，CPU直接操作文件?> JAVA等高级语言也不需要了，大家只要懂XML,XPATH, XSLT,
> XQUery就够了．大家想一想，刚开始Java多慢那，现在大家都
> 盟俣刃阅懿皇俏侍猓焖倏⒆钪匾绾慰焖俚南煊
> 户的需求才是最重要．什么时候中国出一XML领域的大拿，才?> 在编程史上留下中国人的名字，要不整天看洋人名字多烦啊．
> 业慕崧郏涸诨鞯陌镏拢XML统治下一个时代的编程，程序
> 北涑烧嬲睦读欤蠹腋峡旄男邪桑旰螅岩韵胂螅
> ．欢迎拍砖.
>
>
>
呵呵，n年之后，共产主义到来了，我们不用这般辛苦地工作了，天天泡在网上发贴回贴多好！
“一山不容二虎”的说法恐怕有问题：你不用数据库吗？你的数据库不需要优化？你不需要分析那些Entities的存储特性？难道你在Cache中执行SQL？你的MDA工具能够生成正确的Index？
但是，如果是海量的数据应用，或者是基于OLAP（例如决策分析）的应用，恐怕系统设计再合理也没有用。
数据库是不必用的，数据库当然更不需要优化，字段长度都是256，很少访问数据库，这些优化对于J2EE系统来说只是隔靴饶痒。
O/R mapping组件已经帮助我们实现一些优化和使用存储特性。
你的这些问题就象在问操作系统不重要一样。我想我们关注的角度是不一样的。
这不是无聊问题，而是涉及你是否真的在使用OO思考、设计和编程。
正是"一山不容二虎"，你重视数据库，你的J2EE系统就无法完全OO，你只有忽视数据库，你才有可能完全迈向OO。
――――――――――――――――
好像体现的不是很明显啊！～
至于7*24小时集群任何系统的神话，好象很容易的被911之类的事件或是供电系统的灾难故障来轻易的打破，到那时谁来声明对遇难的对象们的状态信息来负责呢？偶猜也只有做到mid-ware和rdbms后端共同作到高冗余也就得了，可以学习学习garbage collector 的做法规定个亚当夏娃什么的，以尽可能短的时间来完成对象状态到后端rdbms的高速存储，没必要谁来取代谁，银行家们的webservice贷款计算程序和main frame不也是共同存活的很好么，没见到有谁实现了grid就扔掉了超大型主机啊，在现实社会这个大的容器限制的范围内，新的技术的发展似乎并不是什么革命，而更多的时候是与过去的技术的互补与融合。
新来并初发贴，胡说的文字比较多，请banq老师海涵，偶正准备借阅您的那本著作来学习，不知道到时候有没有空能得到您在网络那端的指点;-)
基于自己的这个想法，于是带着被认为菜到极点也认了的一种心态，来此求教banq老师，到底全oo的好处何在？这方面偶确实是无知的，甚至不知道组合型的catalyst在ooa/d理论中的位置，但偶总觉的全oo有点靠不住,比如象好的erp实施一样最好先做什么bpm，但从程序员的角度来看，谁来完成将企业瞬息万变的市场需求梳理成好的对象结构呢？这里是将来咨询公司可介入的地方么？。但处于技术基础的薄弱，却不知道这种担忧究竟来自于那里。希望得到您的回复
抛开技术论点而言文章写的很有文采哦！哥们学院派出生？学文还是学理啊！俺正写论文了！有你这么好的文采就好了哦！◎哥们给我支两招撒！
>到底全oo的好处何在?
这个问题类似设计模式有什么好处，这可能还是对人而言的，对于只掌握过程思维的初学者来说，走向全OO是一个飞跃；对于一个真正全OO的系统，最大的衡量标准是否松耦合？所以不能为了OO而OO，关键是为解耦。
另外根据我的个人经验，从OO分析开始到OO实现，整个分析实现过程比较自然，否则发生 对象和数据库的阻抗问题:mismatch，由于只关注系统两端：数据表和界面；结果使得J2EE系统的中间部分变得混乱而无序，反而丧失了多层结构易于维护和扩展的优势。
这种重数据库和界面的思维编程习惯最初是反应在EJB上，很多人抨击EJB中的实体Bean不是好东西，其实是他的坏思维导致，后来他选择了彻底的O/R Mapping，比如Hibernate，到最后发现Hibernate性能还是很低，为什么呢？难道是这些技术错了吗？是他使用错了，这个观点我已经重申了N多年了。
现在，要彻底改变这些问题，不是靠什么更好的技术，而是要更新思维，变成纯OO，或全OO思维，改变从以前注重系统两端到注重系统的中间部分，从中间件建模开始，将最大力气花在模型建立和中间DTO优化以及性能缓存、Pool等使用决定上。
另外，组合型的目录在OO中是以组合模式来实现，不知回答正确否？
全OO的系统由于实现松耦合，使得系统更善于应付企业变化的需求，经常修改不会影响其他功能，全OO实现了应需而变，为什么IBM敢说出这种话？他敢于放弃PC和笔记本事业，那是因为他找到并且已经完全掌握应需而变的法宝和解决之道。
我虽然不敢和IBM那些大牛相比，但是我也看到并自己实现了一些，应需而变的理想境界真是可以看得见的，我们不能再怀疑全OO了。