我们要做ERP拉，以后可能没时间来了，主要是要用EBS，内容太多了，用的oracle的东西也太多，我oracle还不是很熟悉，所以现在要狂补。
用面向对象的思路作程序有一段时间，也自学写OOA，确实觉得项目有时候做的似是而非，用面向对象的思路+模式的时候发现有时候为了实现一些功能，考虑以后扩展性，结果弄得一层层的封装，弄得一堆类，自己开始可能还觉得很过瘾，不过别人看得时候就觉得非常恐惧，项目中的其他人员就觉得不愿意接受你的程序，时间长了在程序不断修改过程中，自己也渐渐迷失了，有时候发现有些东西的都不是自己的想象了，我想请教哈这究竟是我们自己做程序出现的问题，技术不过关，还是面向对象中确实会出现的情况。
feathersnake 的问题非常有意思。
我个人感觉当你发现“有些东西的都不是自己的想象了”，这属于过分设计，或者说过分追求封装和模式了。
"结果弄得一层层的封装，弄得一堆类"，这个问题分两方面看：
面向对象的系统因为是执行分派、细化原则，所以会有很多类，这是一件好事，如果别人无法理解，是他们的问题，你可画一些UML类图或顺序图帮助他们理解。
在这种情况下，最好在一级目录下是接口类，这样，接口多一些，要比类多一些更好，说明你已经对系统抽象到一定程序，如果接口少，而普通类很多，我认为OO还没到位，面向接口编程不是一步到位的，如果你的系统做到了面向接口编程，每层封装之间交互都是通过各自的接口进行，那么说明你的系统OO已经到位了。不别在乎别人怎么看。
不要为了模式而模式，重整你的系统，如果发现类关系如果用模式表达更合适，就重整到模式，因为模式的好处还有助于别人理解。
当然，面向接口编程规模大到一定程度，可以使用一些框架来管理你的结构，如PicoContainer和Spring都是不错的选择。这样，更有助于别人理解了。我们以前帖子讨论了，PicoContainer和Spring这样的框架其实替代了一些模式，如Singleton模式等，所以，从设计来讲，这些都是一脉相承的，从模式到框架，都是为了更好地实现封装、细化和抽象，实现面向接口编程OO系统的最高目标。
谢谢banq的指点
其实还有很多迷茫的东西，我确实经常被称为过分设计。
不过现在我仍然觉得我不能好好的做到设计。
泛泛的学习了UML，也泛泛的学习了设计模式。最近也开始理解对接口编程。这些我都觉得还不错，现在都还没有学习透彻，不能运用一心。
但是框架这个东西，也不知道是不是误解，什么框架都还是利于某种平台上，模式更多的是一种方法和处理问题的思想的总结，而框架仿佛是依赖某种平台的实现，如果平台跨了，框架何从谈起，学习框架不属于一种浪费时间，将自己绑与某种平台上的赌博么，特别是java，框架满天飞，我们解决具体问题的时候他们究竟能带来多大的作用呢！
不过可能还是我自己没有理解吧，请教各位大虾
建议你再自己独立的想想吧，整天琢磨。这些你曾经作过的项目整天在你脑子里转，就行。
我就曾经设计了个接口，那是睡觉时想起来的，我马上就把它用程序写出来了，重用效果，超出我的想象，我也不只这是什么模式。
呵呵，feathersnake ，框架什么时候变成依赖平台的了，java能跨平台，java做的框架怎么不能
面向对象的编程和设计经过这么多年的考验，已经被证明是一种非常好的设计方法，面向数据库的编程如果真的比oo要好，那pb,foxpro之类的东西还要大行其道呢，不过确实像楼主提的，好多程序虽然用的是面向对象的语言，实际还都是面向数据库的那一套东西，（包括现在在单位维护的电信boss系统），把面向对象的系统得有点都埋没了~
为什么出现面向对象的设计？其实很简单，为了软件能够复用。oo的出现使软件复用由结构提升到了 类 的层次。有了复用，就有了良好的可维护性。这对大型系统来说是非常重要的。如果你面向数据库的思想，一个动作写一个类，类里边些数据库的操作，哪里来的复用？到时候维护起来也会很困难……
不过话说回来，就算是面向数据库的思想又怎么样……软件一样跑，维护是麻烦了点，不过更容易理解，跟客户关系好，修改的话还能多要点工作日，挣钱更容易~~
所以说吗……软件的关键所在不是oo,也不是db,是关系……
听到大家的讨论，觉得很精彩。从我最近的一次项目来看，应用面向对象的分析之后，很容易建立面向对象的模型，很自然的开发出面向对象的系统。整个项目也不再是以数据库表为中心，而是以操作(method)为中心，也就是要根据用例设计出接口(interface)。
听到大家的讨论，觉得很精彩。从我最近的一次项目来看，应用面向对象的分析之后，很容易建立面向对象的模型，很自然的开发出面向对象的系统。整个项目也不再是以数据库表为中心，而是以操作(method)为中心，也就是要根据用例设计出接口(interface)。围绕着接口再运用设计模式，降低程序之间的耦合性。
>当数据，从前向后传时我使用的Struts的form，当从后向前时，我喜欢，
>用“微元素”--引自banq，呵呵。我认为，Domain Model要恰当的使用，
>如果全用，非常彻底的用我没发现这样能够能提高实际的效率，若是，你不嫌麻烦，你可以使用
赞同这种开发方式。也许是我还没遇到过比较复杂一点的项目吧。我认为用微元素，可以让编码看起来更清晰，明确。在很多时候迭代也很方便。老是用Iterator很不舒服。
yexie ，偶说的平台就是指java 或者应该说J2EE吧
OOA，别一开始就什么模式，模式的，那是不管用的，他是你看问题的视角！我在上篇贴子中说过，分析就是归类，归类通常大家都用三种方法，其实方法N多，归类后在实现的过程当中在去考虑问题的正确性，最后的最后才是模式！一开始就考虑着怎么用模式，你的程序一定会很乱，古人有云：天下分久必合，合久必分，我想程序乱到一定程度后，你的下一个项目就会好起来！
“当然，理论上，Domain Model确实很完美，但是，实际中确实谎言。可能我还不会用，用不好。估计，用习惯了可能感觉很自在。不过，那样让我的程序员，会感觉很累。并且把经历都放在学框架，找银弹上了，还不如，仔细设计好，我认为，一个系统的成功，不是在那些domain model,而是其他一些类的设计，不如那些业务对象，动作类的设计。”
请问业务对象如何之来？是基于需求然后设计出所谓的业务数据表，再用OOD的方式将其封装？
我觉得这种方式固然很稳定，这种过程已经沉淀了几年了... 但是再构建系统的时候，是不能忽略域模型的，因为这样会造成一个误区。Banq之前已经提过“Object-Relational Impedance Mismatch”。
因为在初次考虑的时候可能表是OK的，但是要知道需求是变化的。系统重构也是难免的。这时候这种表设计方式就会遇到考验。因为在数据表和对象之间存在着一种抵抗力。这也是ORM和OOA日渐流行的驱动因素之一。我不批评面向数据表，但是他确实应该改变了！
请问业务对象如何之来？是基于需求然后设计出所谓的业务数据表，再用OOD的方式将其封装？
答：是基于需求设计出类，而不是设计出所谓的业务数据表。数据表只是我持久化的一种手段。我的面向表编程不是你们所理解的那种面向表设计，表只是我考虑问题的一个方面。
Object-Relational Impedance Mismatch
这东西谁还不能理解呢，关键是怎么做，考虑到现行的一些技术特点，我并没有
那么做，我见过banq作的一些所谓域模型，但个人感觉并不好。所以没那么办。